From list-mgr@ISI.EDU Wed Jan 4 22:15:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 3 Jan 1995 20:15:20 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 3 Jan 1995 20:14:41 -0800 Received: from tkyux.phys.s.u-tokyo.ac.jp by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 3 Jan 1995 20:14:39 -0800 Received: from localhost by tkyux.phys.s.u-tokyo.ac.jp (8.6.8.1/TISN-1.3MD/1.1) id NAA06108; Wed, 4 Jan 1995 13:15:24 +0900 From: "H.L.Ngai" Message-Id: <199501040415.NAA06108@tkyux.phys.s.u-tokyo.ac.jp> To: mbone Subject: wb for solaris 2.3 Date: Wed, 04 Jan 95 13:15:23 +0900 X-Mts: smtp Hi, It is written in the README file in sun-wb-1.59.tar that --- There is a bug in Solaris-2.3 that prevents wb from working in unicast mode. --- I am runnig Solaris 2.3 on SS5, is there exists any alternative to make wb work in unicast mode ? Thanks in advance. --- Julian Ngai julian@tkyux.phys.s.u-tokyo.ac.jp From list-mgr@ISI.EDU Wed Jan 4 22:05:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 3 Jan 1995 20:05:16 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 3 Jan 1995 20:04:40 -0800 Received: from tkyux.phys.s.u-tokyo.ac.jp by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 3 Jan 1995 20:04:37 -0800 Received: from localhost by tkyux.phys.s.u-tokyo.ac.jp (8.6.8.1/TISN-1.3MD/1.1) id NAA06063; Wed, 4 Jan 1995 13:05:18 +0900 From: "H.L.Ngai" Message-Id: <199501040405.NAA06063@tkyux.phys.s.u-tokyo.ac.jp> To: mbone Subject: ivs vs nv Date: Wed, 04 Jan 95 13:05:16 +0900 X-Mts: smtp Hi, Which one (ivs or nv) do people prefer in unicast/multicast video conference ? Recently, I have tried to send video using both ivs and nv in unicast. It seemed that ivs is more easy to use especially in unicat because audio control is also included in its control panel . But, I also noticed that most multicast video conferences are broadcast in nv rather than ivs, is there any reason for this ? I would like to hear some comments from the others. Thanks in advance! --- Julian Ngai julian@tkyux.phys.s.u-tokyo.ac.jp From list-mgr@ISI.EDU Tue Jan 3 15:53:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 3 Jan 1995 23:54:17 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 3 Jan 1995 23:53:22 -0800 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 3 Jan 1995 23:53:21 -0800 Received: from icsid.ICSI.Berkeley.EDU (whd@icsid.ICSI.Berkeley.EDU [128.32.201.59]) by icsia.ICSI.Berkeley.EDU (8.6.8/HUB+V8$Revision: 1.22 $) with ESMTP id XAA26271; Tue, 3 Jan 1995 23:53:20 -0800 From: whd@ICSI.Berkeley.EDU (Wieland Holfelder) Received: (whd@localhost) by icsid.ICSI.Berkeley.EDU (8.6.8/1.8) id XAA03002; Tue, 3 Jan 1995 23:53:17 -0800 Message-Id: <199501040753.XAA03002@icsid.ICSI.Berkeley.EDU> Subject: Re: wb for solaris 2.3 To: julian@tkyux.phys.s.u-tokyo.ac.jp (H.L.Ngai) Date: Tue, 3 Jan 1995 23:53:17 -0800 (PST) Cc: mbone (Multicast Backbone) In-Reply-To: <199501040415.NAA06108@tkyux.phys.s.u-tokyo.ac.jp> from "H.L.Ngai" at Jan 4, 95 01:15:23 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 947 H.L.Ngai writes: > To: mbone@ISI.EDU > Subject: wb for solaris 2.3 > Date: Wed, 04 Jan 95 13:15:23 +0900 > X-Mts: smtp > > Hi, > > It is written in the README file in sun-wb-1.59.tar that > --- > There is a bug in Solaris-2.3 that prevents wb from working in unicast > mode. > --- > > I am runnig Solaris 2.3 on SS5, is there exists any alternative to > make wb work in unicast mode ? Take a look at ftp://playground.sun.com/pub/solaris2/unicast-vat-workaround.tar and if you just replace wb for vat it should work. -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder International Computer Science Institute Email: whd@icsi.berkeley.edu 1947 Center Street Suite 600 Fax : +1-510-642-6865 Berkeley, CA 94704-1198 Phone: +1-510-642-4274 Ext. 302 URL: http://www.icsi.berkeley.edu/~whd ------------------------------------------------------------------------------- From list-mgr@ISI.EDU Wed Jan 4 12:00:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 4 Jan 1995 04:03:50 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 4 Jan 1995 04:03:23 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 4 Jan 1995 04:03:21 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 4 Jan 1995 04:03:11 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 4 Jan 1995 12:02:24 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: "H.L.Ngai" Cc: mbone Subject: Re: ivs vs nv In-Reply-To: Your message of "Wed, 04 Jan 95 13:05:16 +0900." <199501040405.NAA06063@tkyux.phys.s.u-tokyo.ac.jp> Date: Wed, 04 Jan 95 12:00:25 +0000 Message-Id: <3564.789220825@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk > Which one (ivs or nv) do people prefer in unicast/multicast video >conference ? Actually I prefer vic in H.261 mode. H.261 makes better use of available bandwidth than nv, and vic's H.261 is more robust to loss that IVS's, and more efficient in CPU utilisation. However, vic doesn't have the automatic rate control built into IVS, which prevents novice users from blowing the network away (at least until they turn rate control off!). Mark From list-mgr@ISI.EDU Wed Jan 4 04:01:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 4 Jan 1995 06:04:32 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 4 Jan 1995 06:03:07 -0800 Received: from lobster.wellfleet.com by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 4 Jan 1995 06:03:04 -0800 Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA20618; Wed, 4 Jan 95 08:53:02 EST Received: from longhorn.wellfleet by wellfleet (4.1/SMI-4.1) id AA26872; Wed, 4 Jan 95 08:54:19 EST From: jgalgay@wellfleet.com (John Galgay) Message-Id: <9501041354.AA26872@wellfleet> Subject: HP-UX multicasting kernel To: mbone Date: Wed, 4 Jan 1995 09:01:27 -0500 (EST) Cc: jgalgay@wellfleet.com (John Galgay) X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 685 Hello, I want to run the wb, vat, etc... applications on an HP 9000/735 workstation, but it does not currently have a multicasting kernel, of which wb properly informs me. HP customer support tells me that they will not have ip multi- casting support until they next release of OS code (10.0 I believe they said). Since all the applications have been ported to HP-UX, I have to believe that the necessary kernel modifications to allow the HP to be a multicast host are available somewhere. If you are aware of where the necessary kernel modifications are located, please let me know. Thanks alot, John Galgay, Bay Networks, Inc. jgalgay@baynetworks.com jgalgay@wellfleet.com From list-mgr@ISI.EDU Wed Jan 4 06:36:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 4 Jan 1995 14:37:58 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 4 Jan 1995 14:34:24 -0800 Received: from ece.nps.navy.mil by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 4 Jan 1995 14:34:23 -0800 Received: from aditya.ece.nps.navy.mil by ece.nps.navy.mil (4.1/SMI-4.1) id AA12715; Wed, 4 Jan 95 14:36:14 PST Date: Wed, 4 Jan 95 14:36:14 PST From: shukla@ece.nps.navy.mil (Shridhar Shukla 656-2764) Message-Id: <9501042236.AA12715@ece.nps.navy.mil> To: idmr@cs.ucl.ac.uk, mbone Subject: Tech Report about Tree Construction Cc: shukla@ece.nps.navy.mil, klinker@itd.nrl.navy.mil The following technical report is available for anonymous ftp from ftp.nps.navy.mil as /pub/ece/shukla/nps-mltcst-asym-linksv1.ps. Comments/criticism are welcome. ---- Shridhar B. Shukla Internet: shukla@ece.nps.navy.mil EC/Sh, Elec & Comp Eng Home: (408) 372-6203 Naval Postgraduate School Work: (408) 656-2764 Monterey CA 93943-5004 Fax: (408) 656-2760 Title: Mutlicast Tree Construction in Network Topologies with Asymmetric Link Loads Key words: multicast tree construction, distribution centers, resource reservation, asymmetric link loads, multiparty interactions Abstract: This paper addresses the problem of constructing multicast trees with reservation of resources. The main features of the approach described here are that it tolerates asymmetric traffic loads on network links and algorithmically locates data distribution centers for every multiparticipant interaction. A fast and scalable algorithm for locating distribution centers based on the network load and a priori knowledge of participants' locations and resource requirements is given. To explicitly handle cases of disjoint send and receive paths between two nodes, a protocol to build separate send-trees and receive-trees around the centers located in the above manner is given. Simulation results on various topologies are presented showing that, with the above center location mechanism, center-specific trees yield lower tree cost than source-specific trees for many concurrent senders without increasing the average path length significantly. The use of distribution centers, a priori information, and sensitivity to load asymmetry permit effective combination of center-specific and source-specific trees for an interaction and eliminate the need for symmetry checks during resource reservation. From list-mgr@ISI.EDU Wed Jan 4 16:40:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 00:41:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 00:40:54 -0800 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 00:40:53 -0800 Received: from icsid.ICSI.Berkeley.EDU (whd@icsid.ICSI.Berkeley.EDU [128.32.201.59]) by icsia.ICSI.Berkeley.EDU (8.6.8/HUB+V8$Revision: 1.22 $) with ESMTP id AAA13335 for ; Thu, 5 Jan 1995 00:40:48 -0800 From: whd@ICSI.Berkeley.EDU (Wieland Holfelder) Received: (whd@localhost) by icsid.ICSI.Berkeley.EDU (8.6.8/1.8) id AAA09742 for mbone@isi.edu; Thu, 5 Jan 1995 00:40:45 -0800 Message-Id: <199501050840.AAA09742@icsid.ICSI.Berkeley.EDU> Subject: vat audio coding To: mbone (Multicast Backbone) Date: Thu, 5 Jan 1995 00:40:44 -0800 (PST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 748 Can somebody tell me how the dvi (adpcm), gsm and lpc coding in vat exactly works? I would need to know the sampling rate and the actual data format of these codings. The vat man page only gives the sampling rate for pcm coding and the data format for pcm is obvious but i couldn't find any hints for the other ones. Thanks, -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder International Computer Science Institute Email: whd@icsi.berkeley.edu 1947 Center Street Suite 600 Fax : +1-510-642-6865 Berkeley, CA 94704-1198 Phone: +1-510-642-4274 Ext. 302 URL: http://www.icsi.berkeley.edu/~whd ------------------------------------------------------------------------------- From list-mgr@ISI.EDU Thu Jan 5 02:08:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 02:08:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 02:08:27 -0800 Received: from frmop11.cnusc.fr by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 02:08:25 -0800 Received: from FRMOP22.BITNET by FRMOP11.CNUSC.FR (IBM VM SMTP V2R2) with BSMTP id 0076; Thu, 05 Jan 95 11:07:57 EST Message-Id: <"95-01-05-11:08:19.02*BOYER"@FRMOP22.CNUSC.FR> Date: Thu, 05 Jan 95 11:08 From: "Eric BOYER" To: mbone Subject: unsubscribe Please unsubscribe BOYER@FRMOP22.CNUSC.FR Eric.boyer@cnusc.fr Thank you From list-mgr@ISI.EDU Thu Jan 5 20:24:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 10:32:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 10:27:48 -0800 Received: from ruin.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 10:27:45 -0800 Received: by ruin.informatik.uni-Bremen.de (8.6.9/20.9.94cl) id TAA00369 Thu, 5 Jan 1995 19:24:38 +0100 Date: Thu, 5 Jan 1995 19:24:38 +0100 From: Carsten Bormann Message-Id: <199501051824.TAA00369@ruin.informatik.uni-Bremen.de> To: whd@ICSI.Berkeley.EDU Cc: mbone In-Reply-To: <199501050840.AAA09742@icsid.ICSI.Berkeley.EDU> (whd@ICSI.Berkeley.EDU) Subject: Re: vat audio coding The current version of our GSM RPE/LTP implementation can be found at: ftp://ftp.cs.tu-berlin.de/pub/local/kbs/tubmik/gsm/gsm-1.0.6.tar.gz From the README file: GSM 06.10 compresses frames of 160 13-bit samples (8 kHz sampling rate, i.e. a frame rate of 50 Hz) into 260 bits; for compatibility with typical UNIX applications, our implementation turns frames of 160 16-bit linear samples into 33-byte frames (1650 Bytes/s). Gruesse, Carsten From list-mgr@ISI.EDU Fri Jan 6 22:13:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 20:12:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 20:12:23 -0800 Received: from tkyux.phys.s.u-tokyo.ac.jp by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 20:12:20 -0800 Received: from localhost by tkyux.phys.s.u-tokyo.ac.jp (8.6.8.1/TISN-1.3MD/1.1) id NAA19632; Fri, 6 Jan 1995 13:13:05 +0900 From: "H.L.Ngai" Message-Id: <199501060413.NAA19632@tkyux.phys.s.u-tokyo.ac.jp> To: mbone Subject: vat for Solaris2.3 Date: Fri, 06 Jan 95 13:13:03 +0900 X-Mts: smtp Hi, In order to implement unicast vat session on Solaris2.3 (not for other verion, don't be misleaded if you are not running Solaris2.3), I tried ftp://playground.sun.com/pub/solaris2/unicast-vat-workaround.tar and it worked. However, it fails to work after a few trial of the program. It works again after reboot the machine and work for some time and fails again. Is there anyone of you have the same experience ? Any solution for this problem ? Thanks in advance! --- Julian Ngai julian@tkyux.phys.s.u-tokyo.ac.jp From list-mgr@ISI.EDU Fri Jan 6 23:43:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 21:44:17 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 21:43:07 -0800 Received: from tkyux.phys.s.u-tokyo.ac.jp by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 5 Jan 1995 21:43:05 -0800 Received: from localhost by tkyux.phys.s.u-tokyo.ac.jp (8.6.8.1/TISN-1.3MD/1.1) id OAA20748; Fri, 6 Jan 1995 14:43:48 +0900 From: "H.L.Ngai" Message-Id: <199501060543.OAA20748@tkyux.phys.s.u-tokyo.ac.jp> To: mbone Cc: julian@tkyux.phys.s.u-tokyo.ac.jp Subject: mbone inside campus Date: Fri, 06 Jan 95 14:43:47 +0900 X-Mts: smtp Hi, Is it possible to broadcast a lecture within campus using mbone ? What is neccessary for the implementation ? If anyone have the experience, I would be grateful if you could give me some hints. Thanks in advance! --- Julian Ngai julian@tkyux.phys.s.u-tokyo.ac.jp From list-mgr@ISI.EDU Fri Jan 6 09:05:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 6 Jan 1995 10:01:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 6 Jan 1995 10:00:54 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 6 Jan 1995 10:00:52 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 6 Jan 1995 10:00:46 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 6 Jan 1995 09:05:59 +0000 To: "H.L.Ngai" Cc: mbone Subject: Re: mbone inside campus In-Reply-To: Your message of "Fri, 06 Jan 95 14:43:47 +0900." <199501060543.OAA20748@tkyux.phys.s.u-tokyo.ac.jp> Date: Fri, 06 Jan 95 09:05:53 +0000 Message-Id: <931.789383153@cs.ucl.ac.uk> From: Jon Crowcroft > Is it possible to broadcast a lecture within campus using mbone ? > What is neccessary for the implementation ? > If anyone have the experience, I would be grateful if you could give >me some hints. Thanks in advance! Julian we do it frequenetly - but you are using the 'local' part of the mbone ((i.e. make sure you use a local TTL to keep the traffic onsite) you need multicast capable sender + receivers, plus if your campus net is routed (rather than bridged as some are) you need multicast capable routers or mbone tunnels between LANs.... jon From list-mgr@ISI.EDU Fri Jan 6 05:00:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 6 Jan 1995 12:59:01 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 6 Jan 1995 12:58:36 -0800 Received: from ece.nps.navy.mil by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 6 Jan 1995 12:58:33 -0800 Received: from aditya.ece.nps.navy.mil by ece.nps.navy.mil (4.1/SMI-4.1) id AA01372; Fri, 6 Jan 95 13:00:37 PST Date: Fri, 6 Jan 95 13:00:37 PST From: shukla@ece.nps.navy.mil (Shridhar Shukla 656-2764) Message-Id: <9501062100.AA01372@ece.nps.navy.mil> To: idmr@cs.ucl.ac.uk, mbone Subject: Repost: Tree Construction Tech Report Cc: shukla@ece.nps.navy.mil, klinker@itd.nrl.navy.mil This is a repeat announcement about the following technical report, available for anonymous ftp from ftp.nps.navy.mil as /pub/ece/shukla/nps-mltcst-asym-linksv1.ps.Z. The compressed file is a little more than 87Kbytes. Print driver problems made the previous one over 7Mbytes. The inconvenience caused is regretted. Comments/criticism will be greatly appreciated. ---- Shridhar B. Shukla Internet: shukla@ece.nps.navy.mil EC/Sh, Elec & Comp Eng Home: (408) 372-6203 Naval Postgraduate School Work: (408) 656-2764 Monterey CA 93943-5121 Fax: (408) 656-2760 Title: Mutlicast Tree Construction in Network Topologies with Asymmetric Link Loads Key words: multicast tree construction, distribution centers, resource reservation, asymmetric link loads, multiparty interactions Abstract: This paper addresses the problem of constructing multicast trees with reservation of resources. The main features of the approach described here are that it tolerates asymmetric traffic loads on network links and algorithmically locates data distribution centers for every multiparticipant interaction. A fast and scalable algorithm for locating distribution centers based on the network load and a priori knowledge of participants' locations and resource requirements is given. To explicitly handle cases of disjoint send and receive paths between two nodes, a protocol to build separate send-trees and receive-trees around the centers located in the above manner is given. Simulation results on various topologies are presented showing that, with the above center location mechanism, center-specific trees yield lower tree cost than source-specific trees for many concurrent senders with only a modest increase in the average path length. The use of distribution centers, a priori information, and sensitivity to load asymmetry permit effective combination of center-specific and source-specific trees for an interaction and eliminate the need for symmetry checks during resource reservation. From list-mgr@ISI.EDU Mon Jan 9 04:19:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 6 Jan 1995 16:02:29 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 6 Jan 1995 16:01:37 -0800 Received: from power.net (touchstone.power.net) by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 6 Jan 1995 16:01:35 -0800 Received: by power.net (Smail3.1.28.1 #11) id m0rRQZ5-000syJC; Mon, 9 Jan 95 12:19 PST Date: Mon, 9 Jan 1995 12:19:43 -0800 (PST) From: Elias Levy To: mbone Subject: multicast gated Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've heard that there is development into a multicast gated using MOSPF and PIN. Does anyone know the status of this or where can one find more info about it? elias@power.net (Elias Levy) PowerNet, Inc. From list-mgr@ISI.EDU Mon Jan 9 06:22:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 08:24:00 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 08:23:02 -0800 Received: from duke.cs.duke.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 08:22:59 -0800 Received: from macbeth.cs.duke.edu by duke.cs.duke.edu (5.65/3.10G/4.1.3) id AA11836; Mon, 9 Jan 95 11:22:53 -0500 Received: from localhost by macbeth.cs.duke.edu (5.65/3.10L/4.1.3) id AA22101; Mon, 9 Jan 95 11:22:51 -0500 Message-Id: <9501091622.AA22101@macbeth.cs.duke.edu> To: Elias Levy Cc: mbone Subject: Re: multicast gated In-Reply-To: Your message of "Mon, 09 Jan 1995 12:19:43 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <22098.789668570.1@macbeth.cs.duke.edu> Date: Mon, 09 Jan 1995 11:22:50 -0500 From: Thomas Pusateri In message you wr ite: >I've heard that there is development into a multicast gated using MOSPF >and PIN. Does anyone know the status of this or where can one find more >info about it? > >elias@power.net (Elias Levy) >PowerNet, Inc. This is true. A version of dense mode PIM is nearly finished and a mrouted 3.3 compatible DVMRP is in progress. MOSPF will be later in '95. Currently only a custom kernel is supported although there are plans to support a 3.3 kernel. More news will be posted when it is released. Tom From list-mgr@ISI.EDU Mon Jan 9 01:30:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 09:32:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 09:31:26 -0800 Received: from hp.com by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 09:31:23 -0800 Received: from hpindbu.cup.hp.com by hp.com with SMTP (1.37.109.14/15.5+ECS 3.3) id AA259162681; Mon, 9 Jan 1995 09:31:21 -0800 Received: by hpindbu.cup.hp.com (1.36.108.7/15.5+IOS 3.20+cup+OM) id AA03087; Mon, 9 Jan 1995 09:30:56 -0800 From: Kwang-Wei Yao Message-Id: <9501091730.AA03087@hpindbu.cup.hp.com> Subject: Re: multicast gated To: elias@power.net (Elias Levy) Date: Mon, 9 Jan 95 9:30:55 PST Cc: mbone In-Reply-To: ; from "Elias Levy" at Jan 9, 95 12:19 (noon) Mailer: Elm [revision: 66.25] > > I've heard that there is development into a multicast gated using MOSPF > and PIN. Does anyone know the status of this or where can one find more > info about it? > > elias@power.net (Elias Levy) > PowerNet, Inc. > > > The code to support PIM-DM is complete or close to completion. I don't think there is any work done to MOSPF. - Kwang Wei Yao Hewlett Packard From list-mgr@ISI.EDU Mon Jan 9 09:17:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 11:17:50 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 11:17:13 -0800 Received: from oit.gatech.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 11:17:08 -0800 Received: (from ccoprmm@localhost) by oit.gatech.edu (8.6.9/8.6.9) id OAA12154 for mbone@isi.edu; Mon, 9 Jan 1995 14:17:05 -0500 From: Michael.Mealling@oit.gatech.edu (Michael Mealling) Message-Id: <199501091917.OAA12154@oit.gatech.edu> Subject: PIM: sparse vs dense for my campus? To: mbone Date: Mon, 9 Jan 1995 14:17:05 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 691 I just rebooted all of our routers with 10.2(2) and I need to know which of my routers should be run in dense and which in sparse? Our border router will have tunnels to other universities so I think that it should be in sparse but I'm not sure about my other internal routers. Should I even worry about it? The next question concerns an RP. Do I need one? If so should it be our border router? Thanks for any suggestions. A pointer to more info would great! -MM -- ------------------------------------------------------------------------------
Michael Mealling
michael.mealling@oit.gatech.edu
From list-mgr@ISI.EDU Mon Jan 9 09:55:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 11:56:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 11:55:47 -0800 Received: from cobra.gsfc.nasa.gov (cobra-f.gsfc.nasa.gov) by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 11:55:43 -0800 Received: by cobra.gsfc.nasa.gov; (5.65/1.1.8.2/22Jul94-0925AM) id AA03442; Mon, 9 Jan 1995 14:55:32 -0500 From: Gary Veum Message-Id: <9501091955.AA03442@cobra.gsfc.nasa.gov> Subject: Anyone have mrouted3.3 for OSF? To: MBONE Date: Mon, 9 Jan 1995 14:55:32 -0500 (EST) X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 365 hi, I've seen mrouted3.3 for Suns, but does anyone have it for OSF? In particular, I'm running V3.0a. The one I have for OSF is mrouted 2. Thanks. -gary ------------------------------------------------------------------------------- Gary Veum veum@cobra.gsfc.nasa.gov (301)286-1073 RMS/NASA Goddard Space Flight Center, Code 520.9, Greenbelt MD 20771 From list-mgr@ISI.EDU Mon Jan 9 05:41:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 13:44:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 13:41:47 -0800 Received: from power.net (touchstone.power.net) by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 13:41:45 -0800 Received: by power.net (Smail3.1.28.1 #11) id m0rRRqP-000syFC; Mon, 9 Jan 95 13:41 PST Date: Mon, 9 Jan 1995 13:41:41 -0800 (PST) From: Elias Levy To: Thomas Pusateri Cc: mbone Subject: Re: multicast gated In-Reply-To: <9501091622.AA22101@macbeth.cs.duke.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 9 Jan 1995, Thomas Pusateri wrote: > This is true. A version of dense mode PIM is nearly finished and a > mrouted 3.3 compatible DVMRP is in progress. MOSPF will be later in '95. > Currently only a custom kernel is supported although there are plans to > support a 3.3 kernel. > > More news will be posted when it is released. > > Tom > Well the reason I was asking is because I was informed that it would be more reasonable to wait for multicast gated than to try to port mrouted to linux. So I would like to know a) if there is any time table as to when such a gated would be released and if linux will be supported or how difficult it would be to port and b) has anyone tried to port mrouted to linux. elias@power.net (Elias Levy) PowerNet, Inc. From list-mgr@ISI.EDU Mon Jan 9 11:58:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 14:01:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 13:58:39 -0800 Received: from duke.cs.duke.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 13:58:36 -0800 Received: from macbeth.cs.duke.edu by duke.cs.duke.edu (5.65/3.10G/4.1.3) id AA03351; Mon, 9 Jan 95 16:58:25 -0500 Received: from localhost by macbeth.cs.duke.edu (5.65/3.10L/4.1.3) id AA23329; Mon, 9 Jan 95 16:58:23 -0500 Message-Id: <9501092158.AA23329@macbeth.cs.duke.edu> To: Elias Levy Cc: Thomas Pusateri , mbone Subject: Multicast Linux (was Re: multicast gated) In-Reply-To: Your message of "Mon, 09 Jan 1995 13:41:41 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <23326.789688702.1@macbeth.cs.duke.edu> Date: Mon, 09 Jan 1995 16:58:22 -0500 From: Thomas Pusateri In message you w rite: >On Mon, 9 Jan 1995, Thomas Pusateri wrote: > >Well the reason I was asking is because I was informed that it would be more >reasonable to wait for multicast gated than to try to port mrouted to linux. >So I would like to know a) if there is any time table as to when such a gated >would be released and if linux will be supported or how difficult it >would be to port and b) has anyone tried to port mrouted to >linux. > Most of the work lies in the kernel not the mrouted daemon. I believe someone has ported the 3.3 release to Linux though. Even with the initial gated release, some kernel work would be required (The multicast kernel that will be distributed with gated is BSD 4.4 Lite based). I would check on the Linux mailing lists to see who is doing the port and if they need any assistance. Tom From list-mgr@ISI.EDU Tue Jan 10 19:29:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 15:31:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 15:29:32 -0800 Received: from brolga.cc.uq.oz.au by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 15:29:28 -0800 Received: from cc.uq.oz.au by brolga.cc.uq.oz.au id <05616-0@brolga.cc.uq.oz.au>; Tue, 10 Jan 1995 09:29:14 +1000 To: mbone Subject: What is IMS trying to achieve? Date: Tue, 10 Jan 1995 09:29:14 +1000 From: George Michaelson Sender: G.Michaelson@cc.uq.oz.au Message-Id: <"brolga.cc.uq:056180:950109232919"@cc.uq.oz.au> I think its a nice idea, but I can't see that US house/senate is the wave of the future. Maybe a PBS form classical music station would be nicer than pork barrel and rhetoric #101. Anyone else a bit freaked by this social development? Could the ttl maybe wind back to US-states only? Imminent death of the mbone predicted, news at 11 GMT or is that PST or did I mean EDT... -George From list-mgr@ISI.EDU Tue Jan 10 10:09:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 22:12:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 22:10:15 -0800 Received: from lohi.dat.tele.fi (datanet.tele.fi) by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 22:10:09 -0800 Message-Id: <199501100610.AA25381@venera.isi.edu> Received: from lohi.dat.tele.fi by lohi.dat.tele.fi id <21669-0@lohi.dat.tele.fi>; Tue, 10 Jan 1995 08:09:23 +0200 To: pusateri@cs.duke.edu Cc: elias@power.net, pusateri, mbone In-Reply-To: <9501092158.AA23329@macbeth.cs.duke.edu> (pusateri@cs.duke.edu) Subject: Re: Multicast Linux (was Re: multicast gated) Date: Tue, 10 Jan 1995 08:09:23 +0200 From: Juha Heinanen Sender: Juha.Heinanen@lohi.dat.tele.fi Most of the work lies in the kernel not the mrouted daemon. I believe someone has ported the 3.3 release to Linux though. Even with the initial gated release, some kernel work would be required (The multicast kernel that will be distributed with gated is BSD 4.4 Lite based). i don't knwo about mrouted ports for linux, but gated (even quite new versions) have been available for linux for some time already. -- juha From list-mgr@ISI.EDU Mon Jan 9 14:22:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 22:25:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 22:23:05 -0800 Received: from power.net (touchstone.power.net) by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 9 Jan 1995 22:23:03 -0800 Received: by power.net (Smail3.1.28.1 #11) id m0rRZyh-000syDC; Mon, 9 Jan 95 22:22 PST Date: Mon, 9 Jan 1995 22:22:46 -0800 (PST) From: Elias Levy To: Juha Heinanen Cc: pusateri@cs.duke.edu, pusateri, mbone Subject: Re: Multicast Linux (was Re: multicast gated) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Jan 1995, Juha Heinanen wrote: > i don't knwo about mrouted ports for linux, but gated (even quite new > versions) have been available for linux for some time already. > > -- juha > Hmm its true that gated has been available for linux for a long time but thats not the multicast gated. (At least as far as I know if I'am wrong please point it out.) elias@power.net (Elias Levy) PowerNet, Inc. From list-mgr@ISI.EDU Tue Jan 10 10:01:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 02:05:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 02:04:39 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 02:04:37 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 02:04:36 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 10 Jan 1995 10:01:55 +0000 To: shukla@ece.nps.navy.mil (Shridhar Shukla 656-2764) Cc: idmr@cs.ucl.ac.uk, mbone, klinker@itd.nrl.navy.mil Subject: Re: Repost: Tree Construction Tech Report In-Reply-To: Your message of "Fri, 06 Jan 95 13:00:37 PST." <9501062100.AA01372@ece.nps.navy.mil> Date: Tue, 10 Jan 95 10:01:47 +0000 Message-Id: <1213.789732107@cs.ucl.ac.uk> From: Jon Crowcroft >This is a repeat announcement about the following technical report, >available for anonymous ftp from ftp.nps.navy.mil as >/pub/ece/shukla/nps-mltcst-asym-linksv1.ps.Z. >The compressed file is a little more than 87Kbytes. Print driver >problems made the previous one over 7Mbytes. >Comments/criticism will be greatly appreciated. Shridhar B. Shukla nice paper - small version ftp'ed and printed fine... 2 complementary pieces of work i recommend you look at 1. matthew doar's thesis on multicast from cambridge university computer lab (or the infocom paper 2 yrs ago by doar & leslie ) 2. paper by james kadirire on minimising packet copies in multicast routing - in ACM CCR july 1994 regards jon From list-mgr@ISI.EDU Tue Jan 10 04:29:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 06:31:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 06:29:42 -0800 Received: from trystero.radio.com by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 06:29:39 -0800 Received: (carl@localhost) by trystero.radio.com (8.6.9/940816.06ccg) id JAA11420; Tue, 10 Jan 1995 09:29:24 -0500 From: Carl Malamud Message-Id: <199501101429.JAA11420@trystero.radio.com> Subject: Re: What is IMS trying to achieve? To: G.Michaelson@cc.uq.oz.au (George Michaelson) Date: Tue, 10 Jan 1995 09:29:24 -0500 (EST) Cc: mbone In-Reply-To: <"brolga.cc.uq:056180:950109232919"@cc.uq.oz.au> from "George Michaelson" at Jan 10, 95 09:29:14 am Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1864 George - We're perfectly willing to scale all the way back to Alternet or U.S. if that is the consensus. So far, you're the first to weigh in on either side and I'd welcome additional comments. What we're trying to achieve can be accomplished with a ttl as low as 16: recording everything they do on a hard drive. We have about 10 Gbytes allocated, which holds ~1000 hours of audio. What we're trying to do is couple the audio from House and Senate with the Congressional Record (the "transcript" of the proceedings as edited), plus use a variety of other tools (e.g., possibly speaker recognition) to make an audio-on-demand server. The idea is that you probably don't want to listen to everything, but there might be one or two speeches that make sense. Once we're able to extend our network from the hub room of the U.S. Capitol Building into the office buildings, we can also add relevant hearings. Again, a low ttl is fine with us. You notice we're only sending at 16 kbps GSM and notice also that the Senate and House are typically in session when it is night in Asia and Australia. Our theory was to try it at a 127 ttl for a while and then scale back the ttl during periods of heavy mbone usage (e.g., the various cheap stunts, plus conferences, IETF week, NASA launches, etc....). I'm a bit puzzled about the horror when "real" stuff is put on the net. Seems to me that a 16 kbps stream is the same whether its another demo or if its the U.S. House. I happen to think these tools are real and that using them for real applications is a useful "social development." You've heard Marshall McLuhan's famous quote on the "medium is the message"? I think its important we move to the point where the medium *isn't* the message. The Internet has far more potential than simply using it for talking about how to engineer the Internet. Carl From list-mgr@ISI.EDU Tue Jan 10 14:55:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 06:57:55 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 06:56:17 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 06:55:48 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id OAA04864; Tue, 10 Jan 1995 14:55:19 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id OAA26863; Tue, 10 Jan 1995 14:55:16 GMT Date: Tue, 10 Jan 1995 14:55:16 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Carl Malamud Cc: George Michaelson , mbone Subject: Re: What is IMS trying to achieve? In-Reply-To: <199501101429.JAA11420@trystero.radio.com> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Jan 1995, Carl Malamud wrote: > We're perfectly willing to scale all the way back to Alternet or U.S. > if that is the consensus. So far, you're the first to weigh in on either > side and I'd welcome additional comments. I think George's point was that he could not see the relevance of this to a world-wide audience. After all if every MBONE connected country in the world started sending the sessions from their upper and lower houses of government the MBONE would be swamped, even at 16kpbs per channel. Perhaps it would be better if your restricted your ttl to stay within the US except on those occasions when something of global interest is being discussed. Also the IMS:RT-FM channel seems to fly in the face of the agreed policy of restricting "music radio" channels to Radio Free Vat. Graeme From list-mgr@ISI.EDU Tue Jan 10 05:54:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 07:58:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 07:55:47 -0800 Received: from trystero.radio.com by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 07:55:41 -0800 Received: (carl@localhost) by trystero.radio.com (8.6.9/940816.06ccg) id KAA12262; Tue, 10 Jan 1995 10:54:55 -0500 From: Carl Malamud Message-Id: <199501101554.KAA12262@trystero.radio.com> Subject: Re: What is IMS trying to achieve? To: Graeme.Wood@ucs.ed.ac.uk Date: Tue, 10 Jan 1995 10:54:54 -0500 (EST) Cc: mbone In-Reply-To: from "Graeme Wood" at Jan 10, 95 02:55:16 pm Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 704 > After all if every MBONE connected country in > the world started sending the sessions from their upper and lower houses > of government the MBONE would be swamped, Heh. I don't see a lot of others trying to hook up their national parliments. I think if we did, however, it would be great for both the Internet and the MBONE. What better way to get the Internet visible to the people that are making the rules we're going to have to live by? > Also the IMS:RT-FM channel seems to fly in the face of > the agreed policy of restricting "music radio" channels to Radio Free > Vat. Sorry, I can't live with a policy of allowing copyright violations. We have to grow up and get beyond that stage. From list-mgr@ISI.EDU Tue Jan 10 16:04:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 08:06:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 08:04:53 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 08:04:49 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id QAA05668; Tue, 10 Jan 1995 16:04:45 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id QAA27050; Tue, 10 Jan 1995 16:04:44 GMT Date: Tue, 10 Jan 1995 16:04:44 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Carl Malamud Cc: mbone Subject: Re: What is IMS trying to achieve? In-Reply-To: <199501101554.KAA12262@trystero.radio.com> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Jan 1995, Carl Malamud wrote: > > After all if every MBONE connected country in > > the world started sending the sessions from their upper and lower houses > > of government the MBONE would be swamped, > > Heh. I don't see a lot of others trying to hook up their national > parliments. I think if we did, however, it would be great for both > the Internet and the MBONE. What better way to get the Internet > visible to the people that are making the rules we're going to > have to live by? You are still missing the point I think but I don't want to sound too draconian in my comments so I won't labour it. > > Also the IMS:RT-FM channel seems to fly in the face of > > the agreed policy of restricting "music radio" channels to Radio Free > > Vat. > > Sorry, I can't live with a policy of allowing copyright violations. > We have to grow up and get beyond that stage. This was not the point I was making. I don't care about the status of the music being broadcast. I was making the point that we had agreed not to create lots of music stations but to limit it to Radio Free Vat if that is what you wanted to do. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Tue Jan 10 17:15:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 09:39:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 09:24:28 -0800 Received: from mailhost.lut.ac.uk (bgate.lut.ac.uk) by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 09:24:13 -0800 Received: by suna.lut.ac.uk (4.1/SMI-4.1) id AA23055; Tue, 10 Jan 95 17:23:01 GMT Date: Tue, 10 Jan 1995 17:15:13 +0000 (GMT) From: "Jon P. Knight" Subject: Re: What is IMS trying to achieve? To: Carl Malamud Cc: Graeme.Wood@ucs.edinburgh.ac.uk, mbone In-Reply-To: <199501101554.KAA12262@trystero.radio.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Jan 1995, Carl Malamud wrote: > Heh. I don't see a lot of others trying to hook up their national > parliments. I think if we did, however, it would be great for both > the Internet and the MBONE. What better way to get the Internet > visible to the people that are making the rules we're going to > have to live by? Heh, I don't think it would be a great use of precious bandwidth. We already get Parliment on TV and Radio and the MPs still manage to lie through their teeth, pass unpopular laws and get involved in hideous scandals. How would wasting MBONE bandwidth on palimentary (or US Senate or House or Russian Parliment or EC Parliment) sessions change things exactly? I'd go along with the others in suggesting that the US Senate and House politicking isn't terribly interesting on this side of the pond most of the time. Maybe just worldwide multicasts of important, world shattering sessions or ones that have been requested by users? RTFM is cool radio station (it certainly impressed the sixth formers who visited one of the workstation labs last week) but I think its got to be EITHER Radio Free Vat OR RTFM. Too many people have had their virtual wrists slapped for running non-RFV radio stations in the past. If RTFM is legal and RFV isn't, then I guess we go with RTFM? Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Research Student in High Performance Networking and Distributed Systems in the Department of _Computer_Studies_ at Loughborough University. * It's not how big your share is, its how much you share that's important * From list-mgr@ISI.EDU Tue Jan 10 18:41:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 10:56:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 10:42:45 -0800 Received: from v6.ph.gla.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 10:42:13 -0800 Date: Tue, 10 Jan 1995 18:41:18 GMT From: FLAVELL@v2.ph.gla.ac.uk To: mbone Cc: FLAVELL@v2.ph.gla.ac.uk Message-Id: <950110184118.23c00109@v2.ph.gla.ac.uk> Subject: Re: What is IMS trying to achieve? >> Heh. I don't see a lot of others trying to hook up their national >> parliments. I think if we did, however, it would be great for both >> the Internet and the MBONE. What better way to get the Internet >> visible to the people that are making the rules we're going to ^^^^^^^^^^^^^^^^^^^^^^^^ >> have to live by? ^^^^^^^^^^^^^^^ Which "we" would that be, then? I think you've shown your hand ;-) >Heh, I don't think it would be a great use of precious bandwidth. (trimmed for brevity) I agree with that. Each community of interest needs to get a reasonable crack at the available bandwidth, to try the Mbone out in interesting and novel ways, or to use it for things that can't be achieved by other existing means. At the present state of things on international links, what _is_ the purpose of carrying hour after hour of routine material, be it recorded music of whatever nature, or politicowaffle (in all but the most exceptional cases). >RTFM is cool radio station (it certainly impressed the sixth formers who >visited one of the workstation labs last week) ... Quite apart from the question whether that's legal (copyright etc.), surely it would be much more effective, as things are just now, for the more trivial demonstrations to be originated country by country, so as not to strain the international routers and links. As one Prof. said to me, "how is this more effective than shortwave radio, then?". Even in parts of the Mbone where pruning is enforced, there only has to be one consumer at the other end of the link and the traffic flows, with the same consequences for the international links as if the whole country were receiving that session. >Every time that I briefly turned on the IMS channels, they were unusable That was my impression too, but I saw other uk consumers of them most times. As UK connectivity is very good, I'd predict that none of them was getting good results, but that means not only was the traffic flowing, but it was flowing uselessly. (Not meant as a flame, b.t.w, just an observation. Maybe they were actively diagnosing the problem). I guess I'm in no position to lay down the law here. I'm no Mbone expert, merely a user who has had some very successful results from it at the times we needed it, and I hope others get good results from it too, at the times when they want to make use of it. I am just very concerned that by letting things get switched on more or less continuously that don't make very effective use of it, the Mbone will become unusable for anything else, at any rate on an international scope. It's been the custom to carefully negotiate the slots for Mbone events of wide scope: then suddenly four new channels appear, that are apparently meant to operate more or less continuously, at ttl 127, without (AFAIK) any detailed discussion before the event, and also contrary to the collective view that VAT should be the only "radio" channel (my own views on that are not the point here, so I won't press them). This doesn't seem to scale. best regards From list-mgr@ISI.EDU Tue Jan 10 08:59:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 11:12:24 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 10:59:32 -0800 Received: from trystero.radio.com by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 10:59:29 -0800 Received: (carl@localhost) by trystero.radio.com (8.6.9/940816.06ccg) id NAA14222; Tue, 10 Jan 1995 13:59:13 -0500 From: Carl Malamud Message-Id: <199501101859.NAA14222@trystero.radio.com> Subject: Re: What is IMS trying to achieve? To: J.P.Knight@lut.ac.uk (Jon P. Knight) Date: Tue, 10 Jan 1995 13:59:12 -0500 (EST) Cc: carl@radio.com, Graeme.Wood@ucs.edinburgh.ac.uk, mbone In-Reply-To: from "Jon P. Knight" at Jan 10, 95 05:15:13 pm Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1610 > RTFM is cool radio station (it certainly impressed the sixth formers who > visited one of the workstation labs last week) but I think its got to be > EITHER Radio Free Vat OR RTFM. Too many people have had their virtual > wrists slapped for running non-RFV radio stations in the past. If RTFM is > legal and RFV isn't, then I guess we go with RTFM? > We're out of here ... I dropped the ttl to 31 on RT-FM. We still have been unable to work out a deal with BMI and I don't want to keep sending out data if we don't have the license in writing. IMHO, however, that we need to figure out a much better way of allocating resources on the MBONE. Having a few people vote on whether they like a particular thing (e.g., jazz versus senate versus princess di) is absolutely nuts. Condoning the illegal use of music is also nuts and will really hurt us in the long run. I'm not quite sure what to do about things like the U.S. Senate. Opinion seems quite mixed on this issue. No feedback at all on World Radio Network or National Press Club luncheons or other things that we do. I had really hoped that, barring other events actually ready to go and wanting to use the mbone, it wouldn't hurt anything to send out a few 16 kbps streams of audio. I'm not sure what is being hurt by doing this and several people have written to say they either appreciate the material or are using the non-stop data stream to test various pieces of software of protocols. Again, we'll scale back if that is the consensus, but I'd like to make sure that this is based on more than "I don't like politicians." Carl From list-mgr@ISI.EDU Tue Jan 10 19:06:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 11:19:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 11:07:08 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 11:07:04 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id TAA07091; Tue, 10 Jan 1995 19:06:45 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id TAA27409; Tue, 10 Jan 1995 19:06:42 GMT Date: Tue, 10 Jan 1995 19:06:42 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Carl Malamud Cc: mbone Subject: Re: What is IMS trying to achieve? In-Reply-To: <199501101859.NAA14222@trystero.radio.com> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Jan 1995, Carl Malamud wrote: > IMHO, however, that we need to figure out a much better way of allocating > resources on the MBONE. Having a few people vote on whether they like > a particular thing (e.g., jazz versus senate versus princess di) is > absolutely nuts. Condoning the illegal use of music is also nuts and > will really hurt us in the long run. Absolutely. > I'm not quite sure what to do about things like the U.S. Senate. Opinion > seems quite mixed on this issue. No feedback at all on World Radio Network > or National Press Club luncheons or other things that we do. I had really > hoped that, barring other events actually ready to go and wanting to use > the mbone, it wouldn't hurt anything to send out a few 16 kbps streams > of audio. I'm not sure what is being hurt by doing this and several people > have written to say they either appreciate the material or are using the > non-stop data stream to test various pieces of software of protocols. > > Again, we'll scale back if that is the consensus, but I'd like to make > sure that this is based on more than "I don't like politicians." Well my personal opinion is that things like the US Senate and US House probably aren't relevant for most people outside the US most of the time. That is not saying that you might not want to increase the TTL from time to time for certain debates. The World Radio Network is useful but the quality is so bad at the moment from where I am sitting that it is not worth listening to. We need to get this duplicate generation problem sorted out. I have listened to the National Press Club stuff from time to time and some of it is interesting. Please keep up the good work. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Tue Jan 10 03:58:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 12:23:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 12:08:55 -0800 Received: from research.unbc.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 12:08:48 -0800 Received: by research.unbc.edu (940715.SGI.52/931108.SGI.ANONFTP) for mbone@ISI.EDU id AA17976; Tue, 10 Jan 95 11:58:05 -0800 Date: Tue, 10 Jan 1995 11:58:04 -0800 (PST) From: Lyndon Nerenberg To: "Jon P. Knight" Cc: Carl Malamud , Graeme.Wood@ucs.edinburgh.ac.uk, mbone Subject: Re: What is IMS trying to achieve? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Jan 1995, Jon P. Knight wrote: > Heh, I don't think it would be a great use of precious bandwidth. We > already get Parliment on TV and Radio and the MPs still manage to lie > through their teeth, pass unpopular laws and get involved in hideous > scandals. How would wasting MBONE bandwidth on palimentary (or US Senate > or House or Russian Parliment or EC Parliment) sessions change things > exactly? I'd go along with the others in suggesting that the US Senate > and House politicking isn't terribly interesting on this side of the pond > most of the time. Maybe just worldwide multicasts of important, world > shattering sessions or ones that have been requested by users? Yes, you can watch the UK parliament on TV, and I can watch the Canadian parliament on TV, however you cannot see or hear the Canadian parliament, and I cannot see or hear the UK parliament. The MBONE is perhaps the only communications medium currently in existence that allows me (and you) to further our awareness of various local perspectives on international events by tapping into the thoughts of parliamentarians around the world. Admittedly the politicians are not the most unbiased authoraties, however having that ability to consider a wide variety of perspectives allows the biases to cancel out for the most part. Personally I am very much in favour of low-bandwidth international audio feeds of the sessions of parliamentary bodies. --lyndon (network geek with a life outside of queueing theory) From list-mgr@ISI.EDU Tue Jan 10 10:25:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 12:46:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 12:26:06 -0800 Received: from trystero.radio.com by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 12:25:49 -0800 Received: (carl@localhost) by trystero.radio.com (8.6.9/940816.06ccg) id PAA14673; Tue, 10 Jan 1995 15:25:32 -0500 From: Carl Malamud Message-Id: <199501102025.PAA14673@trystero.radio.com> Subject: Re: What is IMS trying to achieve? To: FLAVELL@v2.ph.gla.ac.uk Date: Tue, 10 Jan 1995 15:25:32 -0500 (EST) Cc: mbone In-Reply-To: <950110184118.23c00109@v2.ph.gla.ac.uk> from "FLAVELL@v2.ph.gla.ac.uk" at Jan 10, 95 06:41:18 pm Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1511 > I am just very > concerned that by letting things get switched on more or less continuously > that don't make very effective use of it, the Mbone will become unusable > for anything else, at any rate on an international scope. It's been the > custom to carefully negotiate the slots for Mbone events of wide scope: > then suddenly four new channels appear, that are apparently meant > to operate more or less continuously, at ttl 127, without (AFAIK) > any detailed discussion before the event, and also contrary to the > collective view that VAT should be the only "radio" channel (my own > views on that are not the point here, so I won't press them). > > This doesn't seem to scale. Sigh. You people are making *lots* of assumptions. As I said in my first message today: We have no problem scaling back ttl to 16 as our main goal is to get this data on disk. Why are people assuming everything is permanent and bad? I've seen lots of useless demos go on the net and it seemed to me that there might be a few people who might be interested in what it takes to link satellite dishes and major sites such as the U.S. Capitol to the mbone. Believe me, that is not a simple thing to do and, barring the lack of other activities on the net, doesn't seem to be a bad thing to do for a while. You don't have to listen, the streams are not permanent, the ttl is not fixed in stone, and we're learning *lots* by conducting this experiment. Isn't that the purpose of a research environment? Carl From list-mgr@ISI.EDU Wed Jan 11 18:20:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 14:34:24 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 14:20:40 -0800 Received: from brolga.cc.uq.oz.au by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 14:20:38 -0800 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Wed, 11 Jan 1995 08:20:06 +1000 To: Graeme.Wood@ucs.ed.ac.uk Cc: Carl Malamud , mbone Subject: Re: What is IMS trying to achieve? In-Reply-To: Your message of "Tue, 10 Jan 1995 14:55:16 GMT." X-Mailer: exmh version 1.5phi 9/15/94 Date: Wed, 11 Jan 1995 08:20:02 +1000 Message-Id: <24170.789776402@brolga.cc.uq.oz.au> From: George Michaelson Also the IMS:RT-FM channel seems to fly in the face of the agreed policy of restricting "music radio" channels to Radio Free Vat. Aha. I beg to disagree with Graeme here. IMS has gained copyright approval for its radio re-broadcasting and playage of CD and other recorded material. I prefer IMS RT-FM and World radio to RFV any day if we're talking about high visibility and issues of legality. -George From list-mgr@ISI.EDU Tue Jan 10 12:28:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 14:35:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 14:21:28 -0800 Received: from merit.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 14:21:25 -0800 Received: from ohm.merit.edu (ohm.merit.edu [198.108.60.65]) by merit.edu (8.6.9/merit-2.0) with ESMTP id RAA03955 for ; Tue, 10 Jan 1995 17:21:24 -0500 From: William Bulley Received: (web@localhost) by ohm.merit.edu (8.6.9/8.6.5) id RAA01500 for mbone@ISI.EDU; Tue, 10 Jan 1995 17:28:53 -0500 Message-Id: <199501102228.RAA01500@ohm.merit.edu> Subject: Re: What is IMS trying to achieve? To: mbone Date: Tue, 10 Jan 1995 17:28:53 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 499 My two cents worth: I think the idea of "a few 16k" feeds of audio from the House/Senate is a *great* idea. Look at how C-SPAN has brought sanity to the world of U.S. politics... We're talking about a *democracy* here, after all! Regards, web... -- William Bulley, N8NXN Senior Systems Research Programmer Merit Network Inc. Domain: web@merit.edu 1071 Beal Avenue MaBell: (313) 764-9993 Ann Arbor, Michigan 48109-2103 Fax: (313) 747-3745 From list-mgr@ISI.EDU Wed Jan 11 18:22:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 14:35:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 14:23:32 -0800 Received: from brolga.cc.uq.oz.au by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 14:23:30 -0800 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Wed, 11 Jan 1995 08:22:58 +1000 To: Carl Malamud Cc: mbone Subject: Re: What is IMS trying to achieve? In-Reply-To: Your message of "Tue, 10 Jan 1995 09:29:24 EST." <199501101429.JAA11420@trystero.radio.com> X-Mailer: exmh version 1.5phi 9/15/94 Date: Wed, 11 Jan 1995 08:22:53 +1000 Message-Id: <24213.789776573@brolga.cc.uq.oz.au> From: George Michaelson If the aim is Hansard and record of event, then I think a lower TTL for most stuff and high ttl by agreement in rem-conf (eg if Mother Theresa is commissioned to sing minnie the moocher to the joint houses, or a mass smoke-in is held in the white-house grounds) is just fine. My comment was more about content and not bandwidth. I'd have been just as upset if this was BBC approved re-broadcasts of John Major or Mitterand on RTF/1 None of this matters that much given ones freedom to listen or not... -George From list-mgr@ISI.EDU Wed Jan 11 23:23:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 18:25:09 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 18:24:07 -0800 Received: from jarrah.itd.adelaide.edu.au by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 18:23:57 -0800 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU+NF/UA-5.28) id AA22842; Wed, 11 Jan 1995 12:53:13 +1030 Message-Id: <9501110223.AA22842@jarrah.itd.adelaide.edu.au> To: George Michaelson Cc: mbone Subject: Re: What is IMS trying to achieve? In-Reply-To: Your message of "Tue, 10 Jan 1995 09:29:14 +1000." <"brolga.cc.uq:056180:950109232919"@cc.uq.oz.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jan 1995 12:53:13 +1030 From: Mark Prior I think its a nice idea, but I can't see that US house/senate is the wave of the future. Maybe a PBS form classical music station would be nicer than pork barrel and rhetoric #101. Anyone else a bit freaked by this social development? Could the ttl maybe wind back to US-states only? It seemed like a waste of space to me but so is Radio Free Vat. I just hope the pruning is working and we aren't wasting bandwidth on it. Mark. From list-mgr@ISI.EDU Tue Jan 10 17:56:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 19:57:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 19:56:26 -0800 Received: from panix.com by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 19:56:24 -0800 Received: by panix.com id AA16027 (5.67b/IDA-1.5 for mbone@ISI.EDU); Tue, 10 Jan 1995 22:56:17 -0500 Date: Tue, 10 Jan 1995 22:56:16 -0500 (EST) From: Ken Feingold To: Carl Malamud Cc: "Jon P. Knight" , carl@radio.com, Graeme.Wood@ucs.edinburgh.ac.uk, mbone Subject: Re: What is IMS trying to achieve? In-Reply-To: <199501101859.NAA14222@trystero.radio.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII "...several people have written to say they either appreciate the material or are using the non-stop data stream to test various pieces of software of protocols." please add my vote as your supporter for both reasons. Ken From list-mgr@ISI.EDU Wed Jan 11 04:10:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 20:27:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 20:25:11 -0800 Received: from alink-gw.apple.com by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 20:25:08 -0800 Received: by alink-gw.apple.com (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA16729; Tue, 10 Jan 95 20:11:35 -0800 for MBONE@ISI.EDU Date: 11 Jan 95 04:10 GMT From: CREIGHTON.B@AppleLink.Apple.COM (Creighton, Bert) Subject: Unsubscribe To: MBONE Message-Id: <789797494.1167665@AppleLink.Apple.COM> Please unsubscribe me. From list-mgr@ISI.EDU Wed Jan 11 22:45:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 20:52:01 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 20:48:25 -0800 Received: from nms.etri.re.kr by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 10 Jan 1995 20:47:28 -0800 Received: from sde.etri.re.kr ([129.254.11.30]) by nms.etri.re.kr (4.1/NMS-0.1) id AA24281; Wed, 11 Jan 95 13:46:20 KST Received: by sde.etri.re.kr (4.1/sde-0.1) id AA24852; Wed, 11 Jan 95 13:45:39 KST From: kimsk@sde.etri.re.kr (Sang-Kug Kim) Message-Id: <9501110445.AA24852@sde.etri.re.kr> Subject: Unsubscribe To: MBONE Date: Wed, 11 Jan 1995 13:45:38 +0900 (KST) X-Mailer: ELM [version 2.4 PL21-h3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 630 Please Unsubscribe Me kimsk@sde.etri.re.kr -- Yours Sincerely KIM, SANG-KUG -----------+( E T R I )+------------------ eeee tttttt rrrrrr iiiiii + Post: P.O. Box 106, Yusong, Taejon, KOREA + e t r rr i + Phone: 82-42-860-6331 + eeee t rrrr i + E-mail : kimsk@sde.etri.re.kr + e t r r i + Full name : Kim Sang Kug + eeeee t r r iiiiii + Fax : 82-42-861-1033 + ---------+( Electronics & Telecommunications Research Institute )+-------------- From list-mgr@ISI.EDU Thu Jan 12 06:58:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 00:59:20 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 00:58:08 -0800 Received: from peladon.rmit.EDU.AU by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 00:58:04 -0800 Received: from exxilon.xx.rmit.EDU.AU by peladon.rmit.EDU.AU with SMTP id AA21195 (5.65c/IDA-1.4.4 for ); Wed, 11 Jan 1995 19:57:58 +1100 Received: (richard@localhost) by exxilon.xx.rmit.EDU.AU (8.6.9/8.6.4/ram5) id TAA28114; Wed, 11 Jan 1995 19:58:12 +1100 From: "Richard A. Muirden" Message-Id: <199501110858.TAA28114@exxilon.xx.rmit.EDU.AU> Subject: vat mixing question To: mbone Date: Wed, 11 Jan 1995 19:58:12 +1100 (EDT) Cc: o.benschop@info.curtin.edu.au X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1308 G'day all, I've been trying to get the following idea in operation: * Person X at the end of a 128k link on a mac(gag!) using maven * Me on high speed link, full multicast tools What we want to do is this: point to point vat to his maven to get audio out (works like a charm). Then hook that point to point vat session to a multicast session to get the audio onto the mbone (the eventual end product here is that he wants to have his radio program go to the mbone). I thought the vat 'mixing' (-m) switch would do this, and tried lots of combinations until it seemed to hook up ok, but no audio. I used vat -c -m now on the multicast session I could then see: * my local session * the 'mixing' session * his session In the name bars. But no audio. Did I do something wrong here, or is what I am trying impossible to do? :-) cheers, richard -- Richard A. Muirden, Sys. Admin |Fan of Shostakovich, "Star Trek" and the Boeing Mailto: richard@rmit.EDU.AU |777 (launch: May 15, 1995 - United Airlines). Phone: (+61 3) 660 3814 |I created alt.fan.shostakovich! Fly: UA,QF,WN http://www.rmit.edu.au/richard |Can *YOU* beat my 102 Shost CD's? :-) * 1995: Remembering 20 years since the death of Shostakovich (1906-75) * From list-mgr@ISI.EDU Thu Jan 12 07:00:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 01:01:32 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 01:00:38 -0800 Received: from peladon.rmit.EDU.AU by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 01:00:36 -0800 Received: from exxilon.xx.rmit.EDU.AU by peladon.rmit.EDU.AU with SMTP id AA21257 (5.65c/IDA-1.4.4 for ); Wed, 11 Jan 1995 20:00:29 +1100 Received: (richard@localhost) by exxilon.xx.rmit.EDU.AU (8.6.9/8.6.4/ram5) id UAA28141; Wed, 11 Jan 1995 20:00:44 +1100 From: "Richard A. Muirden" Message-Id: <199501110900.UAA28141@exxilon.xx.rmit.EDU.AU> Subject: PS To: mbone Date: Wed, 11 Jan 1995 20:00:43 +1100 (EDT) Cc: o.benschop@info.curtin.edu.au X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 794 A quick PS to the last email I sent: I forgot to mention that I am running the vat 'mixer' on a seprate multicast host. I read the part in the manual page regarding having only one vat session going because the audio hardware is needed for timimg. The mixer is on a Sun Sparc10, 4.1.3_U1B, Multicast v3.3 my workstation: Indy R4000, Irix 5.2, Multicast v2.x (irix?) apologies for mail flood. -richard -- Richard A. Muirden, Sys. Admin |Fan of Shostakovich, "Star Trek" and the Boeing Mailto: richard@rmit.EDU.AU |777 (launch: May 15, 1995 - United Airlines). Phone: (+61 3) 660 3814 |I created alt.fan.shostakovich! Fly: UA,QF,WN http://www.rmit.edu.au/richard |Can *YOU* beat my 102 Shost CD's? :-) * 1995: Remembering 20 years since the death of Shostakovich (1906-75) * From list-mgr@ISI.EDU Wed Jan 11 12:10:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 02:12:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 02:12:01 -0800 Received: from cicg-communication.grenet.fr by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 02:11:51 -0800 Message-Id: <199501111011.AA19729@venera.isi.edu> Received: by cicg-communication.grenet.fr (4.1/Ccomm.94021501) id AA07926; Wed, 11 Jan 95 11:10:55 +0100 Date: Wed, 11 Jan 95 11:10:55 +0100 From: cc@grenet.fr (Claudine Chassagne) Posted-Date: Wed, 11 Jan 95 11:10:55 +0100 To: mbone Please unsubscribe me (cc@grenet.fr) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Claudine Chassagne | Service Reseaux | | Centre Interuniversitaire de Calcul de Grenoble | | | BP53 | Fax : 76 42 11 71 | | 38041 GRENOBLE-CEDEX9 | Tel : 76 51 42 91 | | e-mail : Claudine.Chassagne@grenet.fr | | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From list-mgr@ISI.EDU Wed Jan 11 00:36:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 02:37:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 02:36:28 -0800 Received: from interlock.ans.net by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 02:36:26 -0800 Received: by interlock.ans.net id AA22347 (InterLock SMTP Gateway 1.1 for mbone@isi.edu); Wed, 11 Jan 1995 05:36:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 11 Jan 1995 05:36:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 11 Jan 1995 05:36:24 -0500 Date: Wed, 11 Jan 1995 05:36:22 -0500 From: Luis Garces Message-Id: <199501111036.AA104703@foo.ans.net> To: mbone Subject: unsubscribe Please unsubscribe me. From list-mgr@ISI.EDU Wed Jan 11 12:08:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 03:05:49 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 03:04:43 -0800 Received: from ds (ds.cesga.es) by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 03:04:12 -0800 Received: from jucar.dtc.uvigo.es ([193.144.37.34]) by ds (4.1/1.34) id AA22376; Wed, 11 Jan 95 12:02:15 +0100 Date: Wed, 11 Jan 95 12:08:10 GMT From: agil@dtc.uvigo.es (Alberto Gil Solla) Message-Id: <9501111208.AA22458@jucar.dtc.uvigo.es> To: mbone please, unsubscribe me. From list-mgr@ISI.EDU Wed Jan 11 15:18:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 03:21:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 03:20:40 -0800 Received: from concave.cs.wits.ac.za by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 03:20:29 -0800 Received: by concave.cs.wits.ac.za (931110.SGI.ANONFTP/940306.cs.wits.ac.za) for mbone@isi.edu id AA07877; Wed, 11 Jan 95 13:18:13 +0200 Date: Wed, 11 Jan 1995 13:18:13 +0200 (SAT) From: Andrew Myers To: mbone Subject: Unsubscribe In-Reply-To: <199501100610.AA25381@venera.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please unsubscribe me.. Thanks.. Ill read the mail via the ftp site. Andrew ________________________________________________________________________ Andrew Myers [Sys Admin - Wits Comp Sci Dept] [Sys Admin - Wits Medical Library] WWW : http://www.cs.wits.ac.za/~andrew TEL : +2711 609 - 3697 SMAIL : P.O.Box 8029, Edenglen, 1613, Transvaal, South Africa OTHER : finger andrew@concave.cs.wits.ac.za _______________________________________________________________________ From list-mgr@ISI.EDU Wed Jan 11 12:21:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 04:53:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 04:52:43 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 04:52:41 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 04:52:38 -0800 Message-Id: <199501111252.AA19747@quark.isi.edu> Received: from muridae.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 11 Jan 1995 12:22:20 +0000 To: Carl Malamud Cc: mbone Subject: Re: What is IMS trying to achieve? In-Reply-To: Your message of "Tue, 10 Jan 95 15:25:32 EST." <199501102025.PAA14673@trystero.radio.com> Date: Wed, 11 Jan 95 12:21:24 +0000 From: Gordon Joly An observation I would make would be to compare the number of participants in NASA Select vat window compared with IMS sessions. Gordo Gordon Joly Email: G.Joly@cs.ucl.ac.uk +441713807934 FAX +441713871397 Computer Science, University College London, Gower St., LONDON WC1E 6BT http://www.cs.ucl.ac.uk/people/gordo/ http://artaids.dcs.qmw.ac.uk:8001/ From list-mgr@ISI.EDU Tue Jan 10 22:35:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 06:31:42 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 06:31:40 -0800 Received: by rx7.ee.lbl.gov for mbone-na@isi.edu (5.65/1.44r) id AA01872; Wed, 11 Jan 95 06:35:21 -0800 Message-Id: <9501111435.AA01872@rx7.ee.lbl.gov> To: mbone-na Subject: jpuckett@168.18.130.249 sendig 600kb/s video Date: Wed, 11 Jan 95 06:35:19 PST From: Van Jacobson Someone named jpuckett in Georgia (domain peachnet.edu) is sending ridiculous amounts of video (400-600kb/s) to the "Live from Antarctica" session (and most other mbone video sessions). The reverse dns mapping for this address doesn't work so I haven't been able to send email to this individual. Could someone get in touch with them & explain to them that this behavior is antisocial? Thanks. - Van From list-mgr@ISI.EDU Wed Jan 11 02:40:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 06:43:17 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 06:40:36 -0800 Received: from tampico.cso.uiuc.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 06:40:34 -0800 Received: from [128.174.33.159] (tobago.cso.uiuc.edu) by tampico.cso.uiuc.edu with SMTP id AA10012 (5.67b/IDA-1.5 for ); Wed, 11 Jan 1995 08:40:09 -0600 X-Sender: kline@tampico.cso.uiuc.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jan 1995 08:40:11 -0600 To: "Richard A. Muirden" , mbone From: Charley Kline Subject: Re: vat mixing question Cc: o.benschop@info.curtin.edu.au At 7:58p 1/11/95, Richard A. Muirden wrote: >But no audio. > >Did I do something wrong here, or is what I am trying impossible to >do? :-) Maven is a little flaky when the conference ID is nonzero and you're talking to a vat mixer. Version d23 is worse than a18, for some reason. We'll get this sorted out soon, but you might want to use zero conference ID's as a workaround in the meantime. /cvk From list-mgr@ISI.EDU Wed Jan 11 04:58:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 07:00:56 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 06:59:38 -0800 Received: from trystero.radio.com by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 06:59:35 -0800 Received: (carl@localhost) by trystero.radio.com (8.6.9/940816.06ccg) id JAA21993; Wed, 11 Jan 1995 09:58:27 -0500 From: Carl Malamud Message-Id: <199501111458.JAA21993@trystero.radio.com> Subject: Re: What is IMS trying to achieve? To: G.Joly@cs.ucl.ac.uk (Gordon Joly) Date: Wed, 11 Jan 1995 09:58:27 -0500 (EST) Cc: carl@radio.com, mbone In-Reply-To: <199501111252.AA19747@quark.isi.edu> from "Gordon Joly" at Jan 11, 95 12:21:24 pm Organization: Internet Multicasting Service 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 According to Gordon Joly: > > > An observation I would make would be to compare the number of > participants in NASA Select vat window compared with IMS sessions. > That is one of the silliest comments I've heard in a long time (and I live in Washington, D.C., the home of silly comments). Do you really want to get into the business of judging what forms of content are acceptable to be transmitted? This list has no business deciding that Nasa is OK, Princess Di is not; the Rolling Stones are OK, the U.S. Senate is not. Far as I can tell, the issue is how we allocate bandwidth on the mbone. I don't think we have a scalable solution yet, though ideas like scoping addresses, finer-grain ttl mechanisms, and, above all, more use of local and regional ttl on sessions pre-configured conferences show promise. For the short term, I don't see anything broken. No person who wants to transmit something appears to have been denied the opportunity to do so. Please don't get into the business of deciding if other people's work has merit. If we're hurting you, yell. If there isn't a real problem that needs solving, however, wouldn't it make more sense to concentrate on your own work? Carl From list-mgr@ISI.EDU Wed Jan 11 04:48:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 06:51:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 06:48:59 -0800 Received: from schiaparelli.rutgers.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 06:48:55 -0800 Received: (from dpz@localhost) by schiaparelli.rutgers.edu (8.6.8.1+bestmx+oldruq+newsunq/8.6.6) id JAA07784 for mbone@isi.edu; Wed, 11 Jan 1995 09:48:34 -0500 Date: Wed, 11 Jan 95 9:48:34 EST From: David Paul Zimmerman To: mbone Subject: Unsubscribing Message-Id: Folks, A friendly reminder: mbone@isi.edu is not the place to send unsubscription requests. You should be sending them to mbone-request@isi.edu instead. dp From list-mgr@ISI.EDU Wed Jan 11 05:01:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 06:57:51 -0800 Received: from noodle.med.yale.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 06:57:43 -0800 Received: by noodle.med.yale.edu; Wed, 11 Jan 95 10:01:21 EST Date: Wed, 11 Jan 95 10:01:21 EST From: Glynn Robinson Message-Id: <9501111501.AA18095@noodle.med.yale.edu> To: mbone-na Subject: Where can I get mbone feed? Hi, I was just wondering if anybody could point me to an mbone feed I could tunnel to? I have checked on campus and apparently nobody is running a feed here, and I'm not sure which of the MBONE providers listed in the FAQ is "the best" for me. FYI I have set up sd/nv/vat/wb on an Indy and Indgigo^2 (both running 5.2) and 2 sparcs (1 running 2.2 the other 2.3). I _appear_ to be able to get site sessions working using the default address given by sd. Is this the _best_ way to get site specific sessions, or should/can I use a local address? Glynn ==================================================================== Dr. G.P. Robinson | Department of Diagnostic Radiology, | "You know, some cultures Yale University Medical School | are defined by their 333 Cedar Street | relationship to cheese." New Haven, CT 06520-8042 | -Joon | e-mail: robinson@noodle.med.yale.edu | Tel: 203 785 4910 | From Benny & Joon 1993 MGM Fax: 203 737 4273 | ==================================================================== From list-mgr@ISI.EDU Wed Jan 11 01:33:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 07:37:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 07:34:50 -0800 Received: from campus.mty.itesm.mx by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 07:34:46 -0800 Received: from tyrcompaq.mty.itesm.mx (tyrcompaq.mty.itesm.mx [131.178.62.253]) by campus.mty.itesm.mx (8.6.9/8.6.9) with SMTP id JAA66702 for ; Wed, 11 Jan 1995 09:34:42 -0600 From: Erick Mancera To: mbone Subject: PIM: sparse vs dense for my campus? Message-Id: Date: Wed, 11 Jan 1995 09:33:54 -0800 (CDT) Priority: NORMAL X-Mailer: ECSMail for Windows v3 Please send me a copy of the answer. Thanks in advance. Erick Mancera On Mon, 9 Jan 1995 14:17:05 -0500 (EST) Michael Mealling wrote: >I just rebooted all of our routers with 10.2(2) and I need to know which >of my routers should be run in dense and which in sparse? Our border >router will have tunnels to other universities so I think that it should >be in sparse but I'm not sure about my other internal routers. Should >I even worry about it? > >The next question concerns an RP. Do I need one? If so should it be >our border router? > >Thanks for any suggestions. A pointer to more info would great! > >-MM > >-- >------------------------------------------------------------------------------ >
>
Michael Mealling
>
michael.mealling@oit.gatech.edu
==================================== Erick Alejandro Mancera Davila Director de Telecomunicaciones y Redes ITESM Campus Monterrey Tel (8) 328-4086 Fax (8) 369-2004 email: emancera@campus.mty.itesm.mx ==================================== From list-mgr@ISI.EDU Wed Jan 11 04:21:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 08:15:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 08:14:10 -0800 Received: from peyote.mty.itesm.mx by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 08:14:08 -0800 Received: by peyote.mty.itesm.mx (NX5.67d/NX3.0M) id AA15443; Wed, 11 Jan 95 10:21:14 -0600 Date: Wed, 11 Jan 95 10:21:14 -0600 From: Lino Corlay Message-Id: <9501111621.AA15443@peyote.mty.itesm.mx> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: mbone Subject: Tunnel request from Sprint Greetings. Could someone please point me at the right person from Sprint to request a tunnel? We wish to receive some of the mbone transmissions. Right now, we have a connection with Sprint in Forth Worth. Thanks for your attention Lino Corlay From list-mgr@ISI.EDU Thu Jan 12 10:24:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 08:26:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 08:25:56 -0800 Received: from nezu.jain.ad.jp by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 08:25:51 -0800 Received: by nezu.jain.ad.jp (5.67+1.6W/6.4JAIN-1.1) id AA01868; Thu, 12 Jan 95 01:24:51 JST Return-Path: Message-Id: <9501111624.AA01868@nezu.jain.ad.jp> To: mbone Subject: MBone int'l tunnel between US and JP has been (accidentally) changed Date: Thu, 12 Jan 1995 01:24:50 +0900 From: Masaki Hirabaru Up to yesterday, the threshold between US and JP MBones was 160 through WIDE to NASA AMES. Tonight I found another int'l tunnel has been set up through SINET to SPRINT and this seems to make the threshold between US and JP lower than 128. As far as I know, JP members of MBone don't know this change, so this would happen without any coordination within JP. I'm afraid that local sessions where we speak Japanese might leak out (and big wave of traffic might reach over JP). I don't know who is in charge of this change, so I simply inform you all. (Now is over 1 am in Japan time, so I won't look for the person who did this.) -- Masaki From list-mgr@ISI.EDU Wed Jan 11 07:21:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 09:16:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 09:13:47 -0800 Received: from merit.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 09:13:45 -0800 Received: from ohm.merit.edu (ohm.merit.edu [198.108.60.65]) by merit.edu (8.6.9/merit-2.0) with ESMTP id MAA14052; Wed, 11 Jan 1995 12:13:44 -0500 From: William Bulley Received: (web@localhost) by ohm.merit.edu (8.6.9/8.6.5) id MAA00768; Wed, 11 Jan 1995 12:21:13 -0500 Message-Id: <199501111721.MAA00768@ohm.merit.edu> Subject: Re: What is IMS trying to achieve? To: G.Joly@cs.ucl.ac.uk (Gordon Joly) Date: Wed, 11 Jan 1995 12:21:12 -0500 (EST) Cc: mbone In-Reply-To: <199501111705.MAA13952@merit.edu> from "Gordon Joly" at Jan 11, 95 05:04:06 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 900 According to Gordon Joly: > > Funny. I didn't vote in the house elections. > > Did you vote in the Poplart by-lection on December 15th (Lansbury > ward)? What I meant was that in a democracy (and even on the Internet) :-) information is supposed to flow freely. Are you objecting to the US Congress information making it across the puddle to England? I don't object to using the MBONE to listen to the British Parliament (kinda neat, actually, if it did...) but I don't have to listen if I don't want to. And I could point out that you needn't listen to Mr. Newt if you don't want to. I don't see what all the fuss is about... Regards, web... -- William Bulley, N8NXN Senior Systems Research Programmer Merit Network Inc. Domain: web@merit.edu 1071 Beal Avenue MaBell: (313) 764-9993 Ann Arbor, Michigan 48109-2103 Fax: (313) 747-3745 From list-mgr@ISI.EDU Wed Jan 11 19:28:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 09:30:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 09:28:34 -0800 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 09:28:32 -0800 Received: from [129.69.30.90] (ksmac1.rus.uni-stuttgart.de) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA18853; Wed, 11 Jan 95 09:28:00 PST Message-Id: <9501111728.AA18853@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jan 1995 18:28:16 +0100 To: Carl Malamud From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Silly comment? Regarding IMS on MBone Cc: mbone regarding Carl's note: >> An observation I would make would be to compare the number of >> participants in NASA Select vat window compared with IMS sessions. >> >That is one of the silliest comments I've heard in a long time (and I >live in Washington, D.C., the home of silly comments). While I wish it were so, I do not agree with this. >For the short term, I don't see anything broken. No person who wants to >transmit something appears to have been denied the opportunity to do so. Not true. People have often been denied the opportunity to transmit, and those that have transmitted often have not been able to get through due to resource limitations. This is particularly true here in Europe, even with pruning (which, incidently, I didn't see included in your technical "fix" list). Of course I may be misunderstanding you. If you mean that at the moment nobody is unable to transmit, this may well be true at some locations. Still, to then argue for lazze faire on the MBone at this point seems to me an ineffective approach (unfortunately). >Do you really want to get into the business of judging what forms >of content are acceptable to be transmitted? Of course not, BUT >This list has no business deciding that Nasa is OK, Princess Di is not; >the Rolling Stones are OK, the U.S. Senate is not. If not this list, then how is it to be determined? I certainly agree that I (and I expect everyone else) would perfer not being in the horribly awkward position that we are in now with a limited resource and none but social disencentives for abuse. However, it does seem to be where we are. The technical "fix"es, even if they are all successful, will not fix the problem for the foreseeable future (of MBone anyway). >Far as I can tell, the issue is how we allocate bandwidth on the mbone. Yep. Helpful suggestions are solicited. James E. (Jed) Donnelley - http://www-atp.llnl.gov/atp/jed.html Advanced Telecom. Prog. - http://www-atp.llnl.gov/atp/atp.html LAWRENCE LIVERMORE LAB. - http://www.llnl.gov/ Until 4/95 at Uni-Stuttgart - http://www.uni-stuttgart.de/ jed@llnl.gov - NOTE - http://www-atp.llnl.gov/atp/comp-comm.html also the more general: http://www-atp.llnl.gov/atp/link.html From list-mgr@ISI.EDU Wed Jan 11 17:58:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 10:03:29 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 09:59:29 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 09:59:28 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 09:59:20 -0800 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 11 Jan 1995 17:58:17 +0000 To: William Bulley Cc: G.Joly@cs.ucl.ac.uk (Gordon Joly), mbone Subject: Re: What is IMS trying to achieve? In-Reply-To: Your message of "Wed, 11 Jan 95 12:21:12 EST." <199501111721.MAA00768@ohm.merit.edu> Date: Wed, 11 Jan 95 17:58:10 +0000 Message-Id: <18362.789847090@cs.ucl.ac.uk> From: Stuart Clayman >> According to Gordon Joly: >> > >> > Funny. I didn't vote in the house elections. >> > >> > Did you vote in the Poplart by-lection on December 15th (Lansbury >> > ward)? >> >> What I meant was that in a democracy (and even on the Internet) :-) >> information is supposed to flow freely. Are you objecting to the >> US Congress information making it across the puddle to England? >> >> I don't object to using the MBONE to listen to the British Parliament >> (kinda neat, actually, if it did...) but I don't have to listen if I >> don't want to. And I could point out that you needn't listen to Mr. >> Newt if you don't want to. I don't see what all the fuss is about... >> >> Regards, >> >> web... Furthermore, it might be nice for Americans living, working, or visiting the UK (or other places for that matter) to listen the the House and Senate whilst away. This also applies to British people in the US. Only the Internet could bring you the joys of your home parliament (or whatever) available on any machine in the world. I think Carl has the right approach with what he is trying to do. He is clearly demonstrating that this kind of international service is easy(ish) to do on the Internet, but completely infeasible with other existing technologies, their sky high transmission costs, and their controllng interests. The more streams of live source material that are available, which are beyond the editorial control of some radio or TV station the better. I agree with people who are worried about the bandwidth usage. Maybe this will encourage more people to run a pruning mrouted. Keep it up Carl. stuart From list-mgr@ISI.EDU Wed Jan 11 11:50:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 13:57:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 13:50:48 -0800 Received: from math.lsa.umich.edu (null.math.lsa.umich.edu) by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 13:50:46 -0800 Received: from schwarzkopf.math.lsa.umich.edu by math.lsa.umich.edu with SMTP id AA05141 (5.67a/IDA-1.5 for mbone@isi.edu); Wed, 11 Jan 1995 16:50:23 -0500 Message-Id: <199501112150.AA05141@math.lsa.umich.edu> To: mbone Subject: Tunnel question and request Date: Wed, 11 Jan 1995 16:50:22 -0500 From: Bill Niester Hi, I currently have the multicast kernels (3.3) up and functioning on my local network of Sun Sparcs (1's 10's and 20's). I can run sd, vat, wb and nv locally and everything works find. Now I would like to have an outside feed into my site. I know I have to run Mrouted on one of my machines and I need to set up a tunnel. My question is can I just get a tunnel to my machine and not be a forwarding site (i.e. just feed off someone else and not feed anyone else)? If so could someone set up a tunnel for me or point me to the right person. I am here at the University of Michigan (math dept) and know that Merit is part of the MBONE but I don't know who to ask. If someone knows any of the above questions I would greatly appreciate any help I could get. thanks, Bill ####################################################################### # # # Bill Niester Email: niester@umich.edu # # The University of Michigan Phone: (313) 763-1182 # # Mathematics Department Pager: (313) 210-0167 # # Systems Manager Address: Rm 425 West Engineering # # Ann Arbor, MI 48109 # # # ####################################################################### From list-mgr@ISI.EDU Thu Jan 12 18:44:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 14:46:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 14:45:44 -0800 Received: from brolga.cc.uq.oz.au by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 14:45:41 -0800 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Thu, 12 Jan 1995 08:44:51 +1000 To: Carl Malamud Cc: G.Joly@cs.ucl.ac.uk (Gordon Joly), mbone Subject: Re: What is IMS trying to achieve? In-Reply-To: Your message of "Wed, 11 Jan 1995 09:58:27 EST." <199501111458.JAA21993@trystero.radio.com> X-Mailer: exmh version 1.5phi 9/15/94 Date: Thu, 12 Jan 1995 08:44:43 +1000 Message-Id: <14939.789864283@brolga.cc.uq.oz.au> From: George Michaelson I'm sorry if my wording has caused some offense. I don't see Carl as epitomising the worst excesses of American cultural export, nor do I really object to the politicians penchant for bad rhetoric. I'd rather have seen a 24-hour-a-day elvis impersonator radio station or a variety of sources than anybodies parliment. I hope when MTV-MBONE comes along we get more than just House video stream. I find the suggestion that visitors overseas are lusting after their own political speeches faintly ludicrous. Perhaps all those years of honour pledges and flag-burning debates have wrought more effect than I suspected. The only argument to date I find useful (and its Carls) is that the house and world radio is predominantly a speech channel, of known and consistent audio quality at the source, and represents a useful test load for MBONE and Internet at large. What worries me about this is the lack of dialogue. Ther *are* going to be "wannabes" just as RFV caused a spate of pirate broadcasts until a permanent SD declaration was added. Van has already had to re-work vat to set default TTL down, and one suspects that long-haul bandwidth will not scale anything like as quickly as US mainland (I don't know of any provider discussing OC-3 class of atlantic/pacific links for general purpose use) And whilst 3 or 4 or maybe 10 <64k channels are no big deal, given doubling effects on the internet, 10 will be 100 and then load will be non-trivial. So how about some kind of moratorium on any MORE (semi) permanent high-ttl channels until a bit more discussion about bandwidth/scaling has gone on? -George From list-mgr@ISI.EDU Thu Jan 12 16:11:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 16:15:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 16:14:25 -0800 Received: from info.curtin.edu.au by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 16:12:00 -0800 Received: from [134.7.170.120] (ob1.curtin.edu.au) by info.curtin.edu.au with SMTP id AA27166 (5.67a/IDA-1.4.5 for ); Thu, 12 Jan 1995 08:10:43 +0800 X-Sender: ibenscho@info.curtin.edu.au Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jan 1995 08:11:08 +0800 To: "Richard A. Muirden" , mbone From: o.benschop@info.curtin.edu.au (Onno Benschop) Subject: Re: vat mixing question At 22:40 11/01/95, Charley Kline wrote: >At 7:58p 1/11/95, Richard A. Muirden wrote: >>But no audio. >> >>Did I do something wrong here, or is what I am trying impossible to >>do? :-) > >Maven is a little flaky when the conference ID is nonzero and you're >talking to a vat mixer. Version d23 is worse than a18, for some reason. >We'll get this sorted out soon, but you might want to use zero conference >ID's as a workaround in the meantime. Ok. We're up with Port=9270, ID=0 -- ()/)/)() ..Visual for Onno.. ..Fasten your seatbelt on the information super highway.. mailto:o.benschop@info.curtin.edu.au From list-mgr@ISI.EDU Thu Jan 12 20:07:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 18:08:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 18:08:06 -0800 Received: from nezu.jain.ad.jp by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 18:08:04 -0800 Received: by nezu.jain.ad.jp (5.67+1.6W/6.4JAIN-1.1) id AA03634; Thu, 12 Jan 95 11:07:06 JST Return-Path: Message-Id: <9501120207.AA03634@nezu.jain.ad.jp> To: mbone Subject: Re: MBone int'l tunnel between US and JP has been (accidentally) changed In-Reply-To: Your message of Thu, 12 Jan 1995 01:24:50 JST. <9501111624.AA01868@nezu.jain.ad.jp> Date: Thu, 12 Jan 1995 11:07:05 +0900 From: Masaki Hirabaru Rich Martin changed the threshold of Sprintlink side with 128, but the its value of SINET side is still 32. So I'm afraid JP domestic traffic might be leaking out. Fortunately there is no JP domestic multicasting event now excepting a few permanent JP domestic sessions. I'm trying to contact with the person who is in charge on JP side. -- Masaki From list-mgr@ISI.EDU Fri Jan 13 02:04:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 20:07:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 20:05:12 -0800 Received: from corinna.its.utas.edu.au by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 20:04:50 -0800 Received: from [131.217.5.126] (mg4_126.its.utas.edu.au) by corinna.its.utas.edu.au with SMTP id AA29561 (5.67a/IDA-1.5 for ); Thu, 12 Jan 1995 15:04:38 +1100 Date: Thu, 12 Jan 1995 15:04:38 +1100 Message-Id: <199501120404.AA29561@corinna.its.utas.edu.au> X-Sender: daj@postoffice.sandybay.utas.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: Doone.Jones@humsoc.utas.edu.au subscribe Doone Alison Jones Technical Officer School of Humanites and Social Science University of Tasmania GPO Box 252C HOBART TAS 7001 AUSTRALIA Fax:002 202279 Tel: 002 202060 From list-mgr@ISI.EDU Fri Jan 13 07:40:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 12 Jan 1995 01:41:29 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 12 Jan 1995 01:40:30 -0800 Received: from peladon.rmit.EDU.AU by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 12 Jan 1995 01:40:28 -0800 Received: from exxilon.xx.rmit.EDU.AU by peladon.rmit.EDU.AU with SMTP id AA06001 (5.65c/IDA-1.4.4 for ); Thu, 12 Jan 1995 20:40:26 +1100 Received: (richard@localhost) by exxilon.xx.rmit.EDU.AU (8.6.9/8.6.4/ram5) id UAA02288 for mbone@isi.edu; Thu, 12 Jan 1995 20:40:40 +1100 From: "Richard A. Muirden" Message-Id: <199501120940.UAA02288@exxilon.xx.rmit.EDU.AU> Subject: Thanks everyone! To: mbone Date: Thu, 12 Jan 1995 20:40:39 +1100 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1130 Hi all. The other day I asked about connecting a maven session to a multicast vat session. I thought I'd give the know how to the list for those that might be interested. As was mailed to me by several readers, the way to do it is with the CU-SeeMe reflector software. I compiled v3.0b1. The options I found that did what I needed were this: * Point the maven at my reflector with the port defined by VAT-UC-PORT in the reflect.conf file * Also in the reflect.conf file hav VAT-MC-OUT pointing to the multicast session's ip and ttl, with VAT-MC-PORT and VAT-CONF-ID also set to match the session details * start it up. It all worked perfectly! The result of these efforts will be coming along in the next message. cheers, richard -- Richard A. Muirden, Sys. Admin |Fan of Shostakovich, "Star Trek" and the Boeing Mailto: richard@rmit.EDU.AU |777 (launch: May 15, 1995 - United Airlines). Phone: (+61 3) 660 3814 |I created alt.fan.shostakovich! Fly: UA,QF,WN http://www.rmit.edu.au/richard |Can *YOU* beat my 105 Shost CD's? :-) * 1995: Remembering 20 years since the death of Shostakovich (1906-75) * From list-mgr@ISI.EDU Fri Jan 13 07:51:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 12 Jan 1995 01:54:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 12 Jan 1995 01:51:12 -0800 Received: from peladon.rmit.EDU.AU by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 12 Jan 1995 01:51:10 -0800 Received: from exxilon.xx.rmit.EDU.AU by peladon.rmit.EDU.AU with SMTP id AA06102 (5.65c/IDA-1.4.4 for ); Thu, 12 Jan 1995 20:51:01 +1100 Received: (richard@localhost) by exxilon.xx.rmit.EDU.AU (8.6.9/8.6.4/ram5) id UAA02336; Thu, 12 Jan 1995 20:51:14 +1100 From: "Richard A. Muirden" Message-Id: <199501120951.UAA02336@exxilon.xx.rmit.EDU.AU> Subject: Internet Radio Program to be broadcast to the Mbone To: mbone, rem-conf@es.net Date: Thu, 12 Jan 1995 20:51:13 +1100 (EDT) Cc: o.benschop@info.curtin.edu.au X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1201 Hi all, Onno Benschop hosts a community radio program about Computing issues. His program for next Tuesday, Jan 17th 1994 will be broadcast via the mbone. He would apprieciate any and all feedback regarding his program via email. email to: online@info.curtin.edu.au Online is an hour of the very latest in Computing and Information Technology. Broadcast every Tuesday between 10:00 and 11:00 GMT. Programme features: Computing News, Interviews, Tips, Tricks, Reviews, Music and prizes. Tuesday January 17, 1995: The Internet - how, why, what, where, who. This program is coming from Perth, Western Australia, and being routed to the Mbone via the Royal Melbourne Institute of Technology Computer Centre. A booking has been placed in the mbone agenda and an sd entry will appear shortly. cheers, richard -- Richard A. Muirden, Sys. Admin |Fan of Shostakovich, "Star Trek" and the Boeing Mailto: richard@rmit.EDU.AU |777 (launch: May 15, 1995 - United Airlines). Phone: (+61 3) 660 3814 |I created alt.fan.shostakovich! Fly: UA,QF,WN http://www.rmit.edu.au/richard |Can *YOU* beat my 105 Shost CD's? :-) * 1995: Remembering 20 years since the death of Shostakovich (1906-75) * From list-mgr@ISI.EDU Thu Jan 12 06:13:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 12 Jan 1995 14:16:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 12 Jan 1995 14:12:58 -0800 Received: from euclid.jpl.nasa.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 12 Jan 1995 14:12:56 -0800 Received: by euclid.Jpl.Nasa.Gov (8.6.7/SMI-4.1+DXRm2.5) id OAA27966; Thu, 12 Jan 1995 14:13:33 -0800 Subject: Audio dropouts - IMS only? To: mbone Reply-To: Peter.J.Scott@jpl.nasa.gov X-Mailer: Poste 2.0 From: "Peter J. Scott" Date: Thu, 12 Jan 95 14:13:28 -0800 Message-Id: <950112141328.26296@euclid> Encoding: 7 TEXT, 2 TEXT SIGNATURE The IMS audio sessions have so many dropouts here that I've given up listening to them - they're just about intelligible, but too annoying to listen to for long, even in conference mode in VAT. There aren't many listeners, so I'm wondering whether this is due to some additional net congestion of other packets, multicast congestion, a problem at the source, or some other problem. I've heard much better quality in the past on other sessions. Peter J. Scott, Member of Technical Staff | pjs@euclid.jpl.nasa.gov Jet Propulsion Laboratory, NASA/Caltech | NSI DECNet: GROUCH::PJS From list-mgr@ISI.EDU Fri Jan 13 03:55:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 13 Jan 1995 06:07:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 13 Jan 1995 05:55:15 -0800 Received: from trystero.radio.com by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 13 Jan 1995 05:55:13 -0800 Received: (carl@localhost) by trystero.radio.com (8.6.9/940816.06ccg) id IAA13383; Fri, 13 Jan 1995 08:55:06 -0500 From: Carl Malamud Message-Id: <199501131355.IAA13383@trystero.radio.com> Subject: Re: Audio dropouts - IMS only? To: Peter.J.Scott@jpl.nasa.gov Date: Fri, 13 Jan 1995 08:55:05 -0500 (EST) Cc: mbone In-Reply-To: <950112141328.26296@euclid> from "Peter J. Scott" at Jan 12, 95 02:13:28 pm Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1899 I noticed the same dropout problems on World Radio Network. We took off silence suppression, narrowed the audio subcarrier range on the satellite dish, and added a filter to try and get rid of local interference. That occurred about 5PM ET last night. Anybody notice a difference? For the House and Senate, the problem still appears to be inside the net, a combination of lost and duplicated packets which the GSM encoding is quite sensitive to. Our black magic theory is that switching to "lecture" mode helps a bit. We know that DVI or PCM works just fine for this, but we're a bit leary about switching to either encoding for two reasons: 1) We're already quite bruised for even doing this at all. 2) We'd like to do the disk-based recording at GSM and adding a mixer into the chain is just another level of complexity. For the issue of "I don't want to hear this" there are two suggestions that I've heard that seem to make some real sense. 1) Have us reduce ttl to 95. A ttl of 96 is the "global session with lots of video" ttl we used at IETF. My theory (perhaps wrong) is that if you are willing to swallow random video, you probably don't care about a couple of GSM sessions. *CAVEAT*: We *still* scale back during times of peak use to ttl's of 63 or less. (RT-FM is at 31 currently.) 2) A suggestion was made that we apply for a permanent block of multicast addressess. That moves us out of the dynamic address space and makes it possible for a network operator to filter us at the router. Kind of a netnews approach. Any technical discussions? I don't want to get into a discussion on the merits of the U.S. Senate versus Max Headroom, but would appreciate any specific suggestions on how we can a) avoid giving you unwanted data but still let people who want the stuff get it and b) improve the audio quality. Carl From list-mgr@ISI.EDU Fri Jan 13 05:08:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 13 Jan 1995 07:04:20 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 13 Jan 1995 07:03:22 -0800 Received: from airborne.cnm.bell-atl.com by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 13 Jan 1995 07:03:20 -0800 Message-Id: <199501131503.AA01423@venera.isi.edu> From: skropac@airborne.cnm.bell-atl.com Date: Fri, 13 Jan 95 10:08 EST Reply-To: skropac@cnm.bell-atl.com To: mbone Subject: imm loading error on solaris2.3 Content-Type: text Content-Length: 230 I'm trying to install imm into my sessin directory and i get a imm: fatal: libX11.so.4: can't open file: errno=2 if anyone can help me out with this please send me mail. Any help is greatly appreciated. Steve Kropac From list-mgr@ISI.EDU Fri Jan 13 06:50:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 13 Jan 1995 14:57:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 13 Jan 1995 14:51:14 -0800 Received: from hub.ubc.ca by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 13 Jan 1995 14:50:10 -0800 Received: by hub.ubc.ca (4.1/1.14) id AA04275; Fri, 13 Jan 95 14:50:08 PST Date: 13 Jan 95 14:50 -0800 From: Marilyn Martin To: mbone Message-Id: <36972*martin@ucs.ubc.ca> Subject: mrouted 3.3 install problem Greetings! I am installing mrouted 3.3 on a sun os 4.1.3 sparcstation IPX system that did not have a previous mrouted installed. The new kernel built fine, after noting that the RSVP_ISI option was required, not optional. When starting up mrouted, I get the following error: mrouted[220]: mrouted version 3.3 mrouted[220]: setsockopt DVMRP_ADD_VIF: Invalid argument I apologize is this is a question that has been answered before. Please let me know if you need any further information. Thanks and take care, Marilyn Martin voice mail: 604-822-5438 Network Management Centre fax mail: 604-822-5116 University of British Columbia e-mail: Marilyn.Martin@ubc.ca Vancouver, B.C. Canada V6T 1Z2 From list-mgr@ISI.EDU Fri Jan 13 16:59:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 13 Jan 1995 19:11:49 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 13 Jan 1995 19:01:30 -0800 Received: from emoryu1.cc.emory.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 13 Jan 1995 19:01:28 -0800 Received: from slacker.cc.emory.edu by emoryu1.cc.emory.edu (5.65/Emory_cc.4.0.1) via SMTP id AA21298 ; Fri, 13 Jan 95 22:01:25 -0500 Return-Path: cfs@unix.cc.emory.edu Received: by slacker.cc.emory.edu (5.x) id AA00401; Fri, 13 Jan 1995 21:59:31 -0500 From: "Charles Stephens" Message-Id: <9501132159.ZM399@unix.cc.emory.edu> Date: Fri, 13 Jan 1995 21:59:30 -0500 In-Reply-To: skropac@airborne.cnm.bell-atl.com "imm loading error on solaris2.3" (Jan 13, 10:08am) References: <199501131503.AA01423@venera.isi.edu> X-Face: T|#%a&$x59DW~,pKoDdqC"X'xx{6BZ@F3Wk_(tCPo%ntZ NS(4(|)RvCQU2[Sl>{O5Ze[E,m=J@]A,E~Vax7R*>a-F-7u#Dm,^j(HC`M\XpL+44WpHT]Q92 X-Mailer: Z-Mail (3.2.0 06sep94) To: mbone Subject: Re: imm loading error on solaris2.3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jan 13, 10:08am, skropac@airborne.cnm.bell-atl.com wrote: > Subject: imm loading error on solaris2.3 > I'm trying to install imm into my sessin directory and i get a > > imm: fatal: libX11.so.4: can't open file: errno=2 > > if anyone can help me out with this please send me mail. Any help is greatly > appreciated. > > Steve Kropac >-- End of excerpt from skropac@airborne.cnm.bell-atl.com Is your LD_LIBRARY_PATH variable set? cfs -- /-------------------\ Charles F. Stephens, UNIX Systems Daddy-Macker | HELLO, my name is | Open Systems Group, |-------------------| Network Systems, | cfs@emory.edu | Information Technology Division, | Charles Stephens | Emory University, Atlanta, Georgia, USA | | **PGP 2.6.1 Public key is available by fingering me at** \-------------------/ **cfs@dooley.cc.emory.edu or email me your public key.** From list-mgr@ISI.EDU Sun Jan 15 20:49:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 04:50:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 04:46:38 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 04:46:37 -0800 Received: by rx7.ee.lbl.gov for mbone@isi.edu (5.65/1.44r) id AA01999; Mon, 16 Jan 95 04:49:45 -0800 Message-Id: <9501161249.AA01999@rx7.ee.lbl.gov> To: Carl Malamud Cc: mbone Subject: IMS audio dropouts, possible uunet/rutgers misconfiguration Date: Mon, 16 Jan 95 04:49:44 PST From: Van Jacobson Carl, Over this weekend I took a look at the loss pattern from the 'world radio network' vat session. At LBL I see almost no duplicate or misordered packets & nothing terribly strange except for a bad case of "cisco disease" at 5 minute intervals. The major problem seems to be just an incredibly high rate of random packet loss. I see a 7-10% loss rate that's not periodic (I looked at the autocorrelation function of the losses in 10 minute, 30 minute & 2 hour packet traces and it was uniformly random with no sign of periodicity) and relatively constant (it doesn't vary with time of day). This is more than enough to make a gsm feed almost unintelligible. (gsm is the most loss sensitive of the available audio encodings. This is because it was designed by telephony types, not network types, and the decoder assumes sequential delivery with a very low loss rate. I.e., the decoder needs not only the data in the current packet, it also needs a bunch of state left over from decoding the previous packet. This in turn means that, in general, losing a single 80ms frame of gsm data trashes at least 160ms of audio because the frame after the lost frame will be mis-decoded & garbled. All the other vat encodings are idempotent. I.e., all the data needed to decode the packet is in the packet so packets can be decoded in any order and at most 80ms of audio is lost on any packet loss. Now this isn't to say that you shouldn't use gsm -- it would work fine up to a 1-2% loss rate and anything larger than a 2% loss rate is grounds for finding a new network provider.) So I think the mystery on the IMS dropouts comes down to finding out the cause of this incredibly high loss rate. If more sites would switch to mrouted 3.3 so we could run multicast traceroute, this kind of problem would be easy to track down. As it is, you'll need to get people at different distances from you to report on what vat loss rates they see & try to narrow it down that way. My guess is the losses are happening at JVNC and they're happening because all traffic sent through UUNET reaches the mbone backbone by going to hill-gw.rutgers.edu then on to y-wing.jvnc.net. Based on past reports from several sites, JVNC has the highest loss rate on the MBone & 10% losses probably represents a good day for them. I suspect that neither Rutgers nor UUNET intend for traffic to go this way (at least, the two times in the past that I've pointed out that Rutgers was serving as the transit between UUNET & the MBone both parties have said that this was unintentional and that the intended path from UUNET to the MBone was via Sura -- a path that is up but not being used because of the way the tunnel metrics are set). As near as I can tell, traffic has been flowing this way for at least a week and probably longer & this would probably explain most of the trouble people have reporting. It also explains the high loss rates from some other sites that go via UUNET (e.g., the iuma.com testing that goes via interop.net then uunet was seeing 20% loss rates earlier tonight). A quick test to see if this is the problem would be to have someone at Rutgers report the loss rate they see on the IMS world radio session. If it's small, the losses are probably happening at JVNC. Or Rutgers could disable the tunnel to y-wing.jvnc.net so that UUNET starts sending via Sura & the rest of us could see if things improve. - Van From list-mgr@ISI.EDU Mon Jan 16 13:45:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 05:51:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 05:51:00 -0800 Received: from mailhost.lut.ac.uk (bgate.lut.ac.uk) by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 05:50:53 -0800 Received: by suna.lut.ac.uk (4.1/SMI-4.1) id AA06617; Mon, 16 Jan 95 13:50:14 GMT Date: Mon, 16 Jan 1995 13:45:03 +0000 (GMT) From: "Jon P. Knight" Subject: Re: IMS audio dropouts, possible uunet/rutgers misconfiguration To: Van Jacobson Cc: Carl Malamud , mbone In-Reply-To: <9501161249.AA01999@rx7.ee.lbl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 16 Jan 1995, Van Jacobson wrote: > Over this weekend I took a look at the loss pattern from the > 'world radio network' vat session. At LBL I see almost no > duplicate or misordered packets & nothing terribly strange > except for a bad case of "cisco disease" at 5 minute intervals. As another data point, I tried listening to WRN last night (Sunday 15th Jan @ approx. 19:00-20:00GMT) and I was seeing a huge number (thousands) of misordered and dropped. I didn't see any missing packets surprisingly. There were also a few funnies such as a few (<10) packets with bad encodings. The audio was barely intelligable at times but often sunk into garbled noise. I was doing this on an SGI Indy with no heavy CPU load on a quiet subnet that actually has the main campus multicast router on it (dgate.lut.ac.uk if anyone's interested - it is running mrouted 3.3). This is usually a very good set up for handling MBONE sessions so I'm pretty sure the local gear is ok. Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Research Student in High Performance Networking and Distributed Systems in the Department of _Computer_Studies_ at Loughborough University. * It's not how big your share is, its how much you share that's important * From list-mgr@ISI.EDU Mon Jan 16 05:28:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 07:32:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 07:28:51 -0800 Received: from barsoom.sura.net (aotearoa.sura.net) by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 07:28:47 -0800 Received: from localhost by barsoom.sura.net with SMTP (5.67b/($Id: sendmail.cf,v 1.17 1991/02/11 14:07:23 jmalcolm Exp $)) id AA05958; Mon, 16 Jan 1995 10:28:41 -0500 Message-Id: <199501161528.AA05958@barsoom.sura.net> To: Van Jacobson Cc: Carl Malamud , mbone Subject: Re: IMS audio dropouts, possible uunet/rutgers misconfiguration In-Reply-To: Your message of "Mon, 16 Jan 1995 04:49:44 PST." <9501161249.AA01999@rx7.ee.lbl.gov> Date: Mon, 16 Jan 1995 10:28:41 -0500 From: Erik Sherk Van, You mention some suboptimal metrics between UUnet and SURAnet. We should be using this tunnel: 192.80.214.198 -> 137.39.43.34 (MBONE1.UU.NET) [1/32/tunnel] and it has the metrics that you would expect. Can you give me a pointer to where you see the problem and I'll look into it. Erik > Carl, > > Over this weekend I took a look at the loss pattern from the > 'world radio network' vat session. At LBL I see almost no > duplicate or misordered packets & nothing terribly strange > except for a bad case of "cisco disease" at 5 minute intervals. > The major problem seems to be just an incredibly high rate of > random packet loss. I see a 7-10% loss rate that's not periodic > (I looked at the autocorrelation function of the losses in 10 > minute, 30 minute & 2 hour packet traces and it was uniformly > random with no sign of periodicity) and relatively constant (it > doesn't vary with time of day). This is more than enough to > make a gsm feed almost unintelligible. (gsm is the most loss > sensitive of the available audio encodings. This is because it > was designed by telephony types, not network types, and the > decoder assumes sequential delivery with a very low loss rate. > I.e., the decoder needs not only the data in the current packet, > it also needs a bunch of state left over from decoding the > previous packet. This in turn means that, in general, losing a > single 80ms frame of gsm data trashes at least 160ms of audio > because the frame after the lost frame will be mis-decoded & > garbled. All the other vat encodings are idempotent. I.e., all > the data needed to decode the packet is in the packet so packets > can be decoded in any order and at most 80ms of audio is lost on > any packet loss. Now this isn't to say that you shouldn't use > gsm -- it would work fine up to a 1-2% loss rate and anything > larger than a 2% loss rate is grounds for finding a new network > provider.) > > So I think the mystery on the IMS dropouts comes down to finding > out the cause of this incredibly high loss rate. If more sites > would switch to mrouted 3.3 so we could run multicast > traceroute, this kind of problem would be easy to track down. > As it is, you'll need to get people at different distances from > you to report on what vat loss rates they see & try to narrow > it down that way. > > My guess is the losses are happening at JVNC and they're > happening because all traffic sent through UUNET reaches the > mbone backbone by going to hill-gw.rutgers.edu then on to > y-wing.jvnc.net. Based on past reports from several sites, JVNC > has the highest loss rate on the MBone & 10% losses probably > represents a good day for them. I suspect that neither Rutgers > nor UUNET intend for traffic to go this way (at least, the two > times in the past that I've pointed out that Rutgers was serving > as the transit between UUNET & the MBone both parties have said > that this was unintentional and that the intended path from > UUNET to the MBone was via Sura -- a path that is up but not > being used because of the way the tunnel metrics are set). As > near as I can tell, traffic has been flowing this way for at > least a week and probably longer & this would probably explain > most of the trouble people have reporting. It also explains the > high loss rates from some other sites that go via UUNET (e.g., > the iuma.com testing that goes via interop.net then uunet was > seeing 20% loss rates earlier tonight). > A quick test to see if this is the problem would be to have > someone at Rutgers report the loss rate they see on the IMS > world radio session. If it's small, the losses are probably > happening at JVNC. Or Rutgers could disable the tunnel to > y-wing.jvnc.net so that UUNET starts sending via Sura & the rest > of us could see if things improve. > > - Van From list-mgr@ISI.EDU Mon Jan 16 06:38:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 08:40:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 08:38:13 -0800 Received: from ziggy.csc.ncsu.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 08:38:09 -0800 Received: by Ziggy.csc.ncsu.edu (4.1/Sun) id AA09759; Mon, 16 Jan 95 11:38:05 EST From: patel@ziggy.csc.ncsu.edu (Sanjay Patel) Posted-Date: Mon, 16 Jan 1995 11:38:05 -0500 (EST) Message-Id: <9501161638.AA09759@Ziggy.csc.ncsu.edu> Subject: BAD PACKETS/GARBAGE WITH MROUTED To: mbone Date: Mon, 16 Jan 1995 11:38:05 -0500 (EST) Cc: patel@ziggy.csc.ncsu.edu (Sanjay Patel) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 806 I have been told that this is the best place to ask this question. first, let me tell you about my setup: i am running mrouted on a sparcstation 10 using solaris 2.4. now, here is my problem, whenever i have mrouted running, a mac on the same subnet with builtin ethernet has problems with tcp connectivity. has anyone else experienced this problem, or know what may be causing this? i would really like to have mbone running on that subnet and it is making it difficult for me to do so with the mac dropping out whenever i do. i do have other machines on the same subnet (all UNIX boxes) and they do not seem to experience any problems with mbone running. thanks in advance. -- -Sanjay Phone: 919 515 1964 Email: patel@adm.csc.ncsu.edu URL: http://www.csc.ncsu.edu/cgi-bin/S_Patel.pl From list-mgr@ISI.EDU Mon Jan 16 08:15:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 10:17:00 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 10:15:40 -0800 Received: from aristotles.rutgers.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 10:15:33 -0800 Received: by aristotles.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02137; Mon, 16 Jan 95 13:15:26 EST Date: Mon, 16 Jan 95 13:15:25 EST From: Kevin Hobson To: Van Jacobson Cc: Carl Malamud , mbone X-Usmail: Computing Services/Telecommunications, Busch Campus, Brett Road, Hill Center, Room 018, Piscataway, NJ 08855-0879 X-Telephone: +1 908 932-2351 X-Fax: +1 908 932-2968 Subject: Re: IMS audio dropouts, possible uunet/rutgers misconfiguration In-Reply-To: Your message of Mon, 16 Jan 95 04:49:44 PST Message-Id: ... >My guess is the losses are happening at JVNC and they're >happening because all traffic sent through UUNET reaches the >mbone backbone by going to hill-gw.rutgers.edu then on to >y-wing.jvnc.net. Based on past reports from several sites, JVNC >has the highest loss rate on the MBone & 10% losses probably >represents a good day for them. I suspect that neither Rutgers >nor UUNET intend for traffic to go this way (at least, the two >times in the past that I've pointed out that Rutgers was serving >as the transit between UUNET & the MBone both parties have said >that this was unintentional and that the intended path from >UUNET to the MBone was via Sura -- a path that is up but not >being used because of the way the tunnel metrics are set). As >near as I can tell, traffic has been flowing this way for at >least a week and probably longer & this would probably explain >most of the trouble people have reporting. It also explains the >high loss rates from some other sites that go via UUNET (e.g., >the iuma.com testing that goes via interop.net then uunet was >seeing 20% loss rates earlier tonight). > >A quick test to see if this is the problem would be to have >someone at Rutgers report the loss rate they see on the IMS >world radio session. If it's small, the losses are probably >happening at JVNC. Or Rutgers could disable the tunnel to >y-wing.jvnc.net so that UUNET starts sending via Sura & the rest >of us could see if things improve. > > - Van > Since I am not the primary Mbone contact at Rutgers (Dave Zimmerman is), for now, I have shutdown the tunnel to JvNCnet on our cisco router tunnel and left up the Alternet connection until Dave can look into it. With JvNCnet routing topology changes to new NSFnet, we have been getting different reports from our users about dropped packets through JvNCnet and in some cases Alternet. In the case of the Alternet, some of their links are being overloaded as result of their customers (like us) getting to other organizations network (like ES.NET). I cannot be sure if this might be causing some of the Mbone problems since I do not know if we can use multicasting traceroute with cisco 10.2(2.2) software. I do not think we have the software on any of our Mbone network Suns, either. Kevin Hobson ("finger hobson@noc.rutgers.edu" for more information; option WWW) Rutgers - The State University of New Jersey INTERNET:hobson@noc.rutgers.edu Computing Services/Telecommunications Division PHONE: 908-445-4780 Busch Campus, Brett Rd, Hill Center, Rm 018, Piscataway, New Jersey, 08855-0879 From list-mgr@ISI.EDU Mon Jan 16 07:52:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 11:54:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 11:52:59 -0800 Received: from fnal.fnal.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 11:52:58 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HLX083DKY800TOSM@FNAL.FNAL.GOV>; Mon, 16 Jan 1995 13:52:48 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA01852; Mon, 16 Jan 95 13:52:05 CST Date: Mon, 16 Jan 1995 13:52:04 -0600 From: Matt Crawford Subject: Re: Silly comment? Regarding IMS on MBone In-Reply-To: Your message of Wed, 11 Jan 95 18:28:16 +0100. <9501111728.AA18853@ocfmail.ocf.llnl.gov> Sender: crawdad@munin.fnal.gov To: Carl Malamud , mbone Message-Id: <9501161952.AA01852@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Carl malamud says: >> For the short term, I don't see anything broken. No person who wants to >> transmit something appears to have been denied the opportunity to do so. Wow. Is this the very same Carl Malamud who was cursing at Fermilab people for planning a three-party physics meeting during IETF week? And doing that cursing a day or two *after* their meeting was over? From list-mgr@ISI.EDU Mon Jan 16 06:55:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 14:56:55 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 14:56:03 -0800 Received: from hub.ubc.ca by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 14:55:52 -0800 Received: by hub.ubc.ca (4.1/1.14) id AA14136; Mon, 16 Jan 95 14:55:40 PST Date: 16 Jan 95 14:55 -0800 From: Marilyn Martin To: mbone Message-Id: <36986*martin@ucs.ubc.ca> Subject: Re: mrouted 3.3 install problem Greetings, It was suggested to me that I may not have rebuilt the kernel correctly on my second attempt. I completely removed the new kernel directory and did a rebuild from scratch. I still get this same error message: mrouted[170]: mrouted version 3.3 mrouted[170]: setsockopt DVMRP_ADD_VIF: Invalid argument The /etc/mrouted.conf file only has one entry to tunnel with an existing router: tunnel 137.82.112.4 137.82.5.133 Any suggestions would be helpful. Thanks and take care, Marilyn Martin voice mail: 604-822-5438 Network Management Centre fax mail: 604-822-5116 University of British Columbia e-mail: Marilyn.Martin@ubc.ca Vancouver, B.C. Canada V6T 1Z2 ========================================================================= From my previous message: I am installing mrouted 3.3 on a sun os 4.1.3 sparcstation IPX system that did not have a previous mrouted installed. The new kernel built fine, after noting that the RSVP_ISI option was required, not optional. When starting up mrouted, I get the following error: mrouted[220]: mrouted version 3.3 mrouted[220]: setsockopt DVMRP_ADD_VIF: Invalid argument I apologize is this is a question that has been answered before. Please let me know if you need any further information. From list-mgr@ISI.EDU Mon Jan 16 19:33:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 21:38:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 21:35:35 -0800 Received: from louie.udel.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 16 Jan 1995 21:35:27 -0800 Received: from snow-white-fddi.udel.edu by louie.udel.edu id aa21601; 17 Jan 95 0:34 EST Received: from louie.udel.edu by snow-white.ee.udel.edu id aa16488; 17 Jan 95 0:34 EST Received: from snow-white.ee.udel.edu by stimpy.eecis.udel.edu id aa11312; 17 Jan 95 5:33 GMT To: Marilyn Martin Cc: mbone Subject: Re: mrouted 3.3 install problem In-Reply-To: Your message of "16 Jan 1995 14:55:00 PST." <36986*martin@ucs.ubc.ca> Date: Tue, 17 Jan 1995 00:33:51 -0500 From: Ajit Thyagarajan Message-Id: <9501170533.aa11312@stimpy.eecis.udel.edu> In message <36986*martin@ucs.ubc.ca>you wrote: > mrouted[170]: mrouted version 3.3 > mrouted[170]: setsockopt DVMRP_ADD_VIF: Invalid argument > It looks like you might want to check the operation of mrouted itself. Here are some indications: (1) are you sure mrouted is started up as root? (2) did you compile mrouted properly? There are more reasons, but these are good places to start. Best of luck... Ajit From list-mgr@ISI.EDU Tue Jan 17 04:21:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 06:24:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 06:22:32 -0800 Received: from schiaparelli.rutgers.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 06:22:30 -0800 Received: (from dpz@localhost) by schiaparelli.rutgers.edu (8.6.8.1+bestmx+oldruq+newsunq/8.6.6) id JAA12668; Tue, 17 Jan 1995 09:21:03 -0500 Date: Tue, 17 Jan 95 9:21:03 EST From: David Paul Zimmerman To: Van Jacobson Cc: mbone Subject: Re: IMS audio dropouts, possible uunet/rutgers misconfiguration In-Reply-To: Your message of Mon, 16 Jan 95 04:49:44 PST Message-Id: Van, I'm pretty sure that Rutgers has been completely uninvolved with any transit MBone traffic for at least a couple of months now. We've nailed both our JvNCNet and AlterNet tunnels to a Cisco router, and are doing filtering on the networks that we advertise to the rest of the world. (mrouted's lack of filtering was the only reason we were doing transit service before.) More specifically, we _should_ only be advertising Rutgers networks. If you can find otherwise, I'd be interested in knowing, because it is definately not our intent to be a transit path (more so than ever). I've turned our JvNCNet tunnel back on for now. dp From list-mgr@ISI.EDU Tue Jan 17 06:40:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 08:48:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 08:46:51 -0800 Received: from Princeton.EDU by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 08:46:41 -0800 Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.115/princeton) id AA11381; Tue, 17 Jan 95 11:40:18 -0500 Received: from flagstaff.Princeton.EDU by ponyexpress.princeton.edu (5.65c/1.7/newPE) id AA24263; Tue, 17 Jan 1995 11:40:17 -0500 Received: by flagstaff.Princeton.EDU (4.1/Phoenix_Cluster_Client) id AA28894; Tue, 17 Jan 95 11:40:17 EST Message-Id: <9501171640.AA28894@flagstaff.Princeton.EDU> From: rshigeta@phoenix.Princeton.EDU (Ronald T. Shigeta) Date: Tue, 17 Jan 1995 11:40:17 EST X-Mailer: Mail User's Shell (7.2.2 3/2/90) To: mbone Subject: unsubscribe me Please unsubscribe me from the MBone mailing list. -- | Ron Shigeta rshigeta@phoenix.Princeton.edu | Frick Labs | Princeton University From list-mgr@ISI.EDU Tue Jan 17 10:20:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 12:23:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 12:21:06 -0800 Received: from herman.cmf.nrl.navy.mil by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 12:21:04 -0800 Received: from localhost (fenner@localhost) by herman.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id PAA01851; Tue, 17 Jan 1995 15:20:04 -0500 Message-Id: <199501172020.PAA01851@herman.cmf.nrl.navy.mil> X-Mailer: exmh version 1.5.1 12/2/94 To: David Paul Zimmerman Cc: Van Jacobson , mbone Subject: Re: IMS audio dropouts, possible uunet/rutgers misconfiguration In-Reply-To: Your message of "Tue, 17 Jan 95 09:21:03 EST." X-Face: -*.ZYbFWa}{2c8NmF| > I'm pretty sure that Rutgers has been completely uninvolved with any transit > MBone traffic for at least a couple of months now. We've nailed both our > JvNCNet and AlterNet tunnels to a Cisco router, and are doing filtering on the > networks that we advertise to the rest of the world. With route filtering entering the picture, we will *really* need a working multicast traceroute, as you can no longer simply use "mrmap" and "mrdebug" to discover a multicast route. Only 272 out of the 1200 mrouters in my last map were at 3.3 . Debugging the MBONE is becoming more and more a daunting task. Bill From list-mgr@ISI.EDU Tue Jan 17 17:58:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 20:00:58 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 19:58:28 -0800 Received: from stone.ucs.indiana.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 19:58:23 -0800 Received: by stone.ucs.indiana.edu (4.1/9.7jsm) id AA04816; Tue, 17 Jan 95 22:58:22 EST Date: Tue, 17 Jan 1995 22:58:21 -0500 (EST) From: Allen Robel Subject: If anyone notices any weirdness from 129.79.211.254... To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, We just switched our tunnel with CICnet from a Sparc running 3.3 to a cisco 7000 running 10.3(0.12). I've configured what I think are acceptable filters and things look OK, but would appreciate getting a note from anyone who sees this setup causing problems. I'm not subscribed to the list yet so please direct responses to mcast@stone.ucs.indiana.edu Many thanks! +--------------------------------------------------------------------+ | Allen Robel | http://cell-relay.indiana.edu/allen/home.html | | robelr@indiana.edu | "a page with no excuse..." | +--------------------------------------------------------------------+ From list-mgr@ISI.EDU Tue Jan 17 13:17:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 21:27:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 21:17:20 -0800 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 17 Jan 1995 21:17:17 -0800 Posted-Date: Tue 17 Jan 95 21:17:14 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 17 Jan 95 21:17:15 PST Date: Tue 17 Jan 95 21:17:14 PST From: Stephen Casner Subject: Upgrading to 3.3 (Was: IMS audio dropouts, ...) To: fenner@cmf.nrl.navy.mil Cc: MBONE Message-Id: <790406234.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199501172020.PAA01851@herman.cmf.nrl.navy.mil> Mail-System-Version: > Only 272 out of the 1200 mrouters in my last map were at 3.3 . From the comments I've received back in response to my exhortations on this subject, part of the explanation is that many of the mrouters are not SPARCs running SunOS. -- Steve ------- From list-mgr@ISI.EDU Tue Jan 17 16:36:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 00:39:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 00:38:23 -0800 Received: from baker.nwnet.net by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 00:38:22 -0800 Received: by baker.nwnet.net (5.65/UW-NDC Revision: 2.29 ) id AA04369; Wed, 18 Jan 95 00:36:59 -0800 Date: Wed, 18 Jan 1995 00:36:59 -0800 (PST) From: David Comay To: MBONE Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) In-Reply-To: <790406234.0.CASNER@XFR.ISI.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 17 Jan 1995, Stephen Casner wrote: > > Only 272 out of the 1200 mrouters in my last map were at 3.3 . > > on this subject, part of the explanation is that many of the mrouters > are not SPARCs running SunOS. speaking of which, could someone in the know comment on the progress of the 3.3 port for bsdi? i checked the mbone archive on venera.isi.edu but didn't really see anything solid on this. i might consider doing it myself although there is a new release of BSDI/OS coming out which might be using 3.3 as a code base. anybody know? on a related note, can anyone comment on how development of future 3.x releases relates to the work being done on the DVMRP/MOSPF/PIM-aware gated? thanks, dsc From list-mgr@ISI.EDU Tue Jan 17 23:12:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 01:13:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 01:12:29 -0800 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 01:12:28 -0800 Received: from BILL-THE-CAT.MIT.EDU by MIT.EDU with SMTP id AA06041; Wed, 18 Jan 95 04:12:26 EST From: jhawk@MIT.EDU Received: by bill-the-cat.MIT.EDU (5.0/4.7) id AA28695; Wed, 18 Jan 1995 04:12:22 -0500 Date: Wed, 18 Jan 1995 04:12:22 -0500 Message-Id: <9501180912.AA28695@bill-the-cat.MIT.EDU> To: mbone Subject: Grey Rects at Usenix Content-Length: 360 I feel like I'm playing Van Jacobson for a moment :-) The USENIX keynote vic video is currently receiving two gray rectangles (At low bandwith, but still there). Somebody should please shut these off. One is from 128.3.112.135, and seems to come from LBL. The other is 192.35.215.130, which is mbtest.ucop.edu... Thanks. --John Hawkinson jhawk@mit.edu. From list-mgr@ISI.EDU Wed Jan 18 04:30:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 06:32:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 06:30:23 -0800 Received: from duke.cs.duke.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 06:30:18 -0800 Received: from macbeth.cs.duke.edu by duke.cs.duke.edu (5.65/3.10G/4.1.3) id AA27499; Wed, 18 Jan 95 09:30:15 -0500 Received: from localhost by macbeth.cs.duke.edu (5.65/3.10L/4.1.3) id AA18899; Wed, 18 Jan 95 09:30:13 -0500 Message-Id: <9501181430.AA18899@macbeth.cs.duke.edu> To: David Comay Cc: MBONE Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <18896.790439412.1@macbeth.cs.duke.edu> Date: Wed, 18 Jan 1995 09:30:12 -0500 From: Thomas Pusateri In message you write: > >on a related note, can anyone comment on how development of future 3.x >releases relates to the work being done on the DVMRP/MOSPF/PIM-aware >gated? thanks, > >dsc The current gated PIM implementation (which is almost ready for public consumption) assumes a modified 4.4 Lite kernel. This kernel stores (Group,Source) pairs in the radix tree and adds and deletes cache entries using the routing socket. The kernel source and a paper describing it is available for anonymous ftp. (Send me mail for a pointer.) In order to promote more widespread use, gated PIM will soon run on a slightly modified 3.3 kernel as well. The modifications required will be sent back to Ajit, Steve, and friends to hopefully be included in a subsequent release. This is probably still a month or so away. Hope this helps, Tom From list-mgr@ISI.EDU Wed Jan 18 19:14:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 07:22:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 07:20:53 -0800 Received: from lohi.dat.tele.fi by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 07:20:37 -0800 Message-Id: <199501181520.AA10194@venera.isi.edu> Received: from lohi.dat.tele.fi by lohi.dat.tele.fi id <02666-0@lohi.dat.tele.fi>; Wed, 18 Jan 1995 17:14:41 +0200 To: pusateri@cs.duke.edu Cc: dsc@nwnet.net, MBONE In-Reply-To: <9501181430.AA18899@macbeth.cs.duke.edu> (pusateri@cs.duke.edu) Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) Date: Wed, 18 Jan 1995 17:14:41 +0200 From: Juha Heinanen Sender: Juha.Heinanen@lohi.dat.tele.fi In order to promote more widespread use, gated PIM will soon run on a slightly modified 3.3 kernel as well. The modifications required will be sent back to Ajit, Steve, and friends to hopefully be included in a subsequent release. This is probably still a month or so away. if you really would like to have widespread use, a port to linux would be very desirable. -- juha From list-mgr@ISI.EDU Wed Jan 18 05:37:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 07:42:30 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 07:37:56 -0800 Received: from relay.hp.com by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 07:37:53 -0800 Received: from it_750.ch.apollo.hp.com by relay.hp.com with SMTP (1.37.109.14/15.5+ECS 3.3) id AA262523470; Wed, 18 Jan 1995 07:37:50 -0800 Message-Id: <199501181537.AA262523470@relay.hp.com> Received: from dcetv.ch.apollo.hp.com by it_750.ch.apollo.hp.com for MBONE@ISI.EDU id AA23237; Wed, 18 Jan 1995 10:37:49 -0500 To: Thomas Pusateri Cc: David Comay , MBONE Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) In-Reply-To: Your message of "Wed, 18 Jan 1995 09:30:12 EST." <9501181430.AA18899@macbeth.cs.duke.edu> X-Mailer: exmh version 1.4.1 7/21/94 Date: Wed, 18 Jan 1995 10:37:47 -0500 From: John Brezak > In message you writ e: > > > >on a related note, can anyone comment on how development of future 3.x > >releases relates to the work being done on the DVMRP/MOSPF/PIM-aware > >gated? thanks, > > > >dsc > > The current gated PIM implementation (which is almost ready for public > consumption) assumes a modified 4.4 Lite kernel. This kernel stores > (Group,Source) pairs in the radix tree and adds and deletes cache > entries using the routing socket. The kernel source and a paper describing > it is available for anonymous ftp. (Send me mail for a pointer.) > > In order to promote more widespread use, gated PIM will soon run on a > slightly modified 3.3 kernel as well. The modifications required will > be sent back to Ajit, Steve, and friends to hopefully be included in a > subsequent release. This is probably still a month or so away. > > Hope this helps, > Tom > I would also like to see mrouted be able to run on a 4.4Lite kernel with the gated mods. It seems that the gated changes are more generic than the current 3.3 kernel mods. I'd like to see some discussion on this topic. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5140 From list-mgr@ISI.EDU Wed Jan 18 05:43:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 07:45:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 07:44:04 -0800 Received: from bnl.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 07:44:02 -0800 Received: by bnl.gov (5.57/Ultrix3.0-C) id AA27878; Wed, 18 Jan 95 10:43:59 -0500 Received: by sirius.ccd.bnl.gov (940715.SGI.52/930416.SGI.AUTO) for @bnl.gov:mbone@isi.edu id AA22144; Wed, 18 Jan 95 10:43:57 -0500 From: "Graham Campbell" Message-Id: <9501181043.ZM22142@sirius.ccd.bnl.gov> Date: Wed, 18 Jan 1995 10:43:55 -0500 Reply-To: gc@bnl.gov X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: mbone Subject: Cisco router configuration Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 We are getting ready to test a Cisco router as a multicast router. However we have seen many comments about the havoc that configuration errors can cause. Can someone tell us what these problems are and what to be careful about in configuring this beast? -- Graham gc@bnl.gov From list-mgr@ISI.EDU Wed Jan 18 01:29:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 09:31:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 09:29:59 -0800 Received: from nuku.nosc.mil by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 09:29:58 -0800 Received: from neko by nuku.nosc.mil (NX5.67e/NX3.0M) id AA04684; Wed, 18 Jan 95 09:29:44 -0800 Received: by neko.nosc.mil (NX5.67e/NX3.0S) id AA03774; Wed, 18 Jan 95 09:29:42 -0800 Message-Id: <9501181729.AA03774@neko.nosc.mil> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v116.1) Received: by NeXT.Mailer (1.116.1) From: Ron Broersma Date: Wed, 18 Jan 95 09:29:34 -0800 To: mbone, rem-conf@es.net Subject: IP Multicast for 4.1.4? Cc: cooper@nuku.nosc.mil Reply-To: ron@nuku.nosc.mil Does anyone know if the multicast 3.3 release (ipmulti3.3-sunos413x.tar.Z) will drop into a SunOS 4.1.4 kernel? And work? We are about to attempt this but would like to be warned right away if there is a problem with this, so we don't waste time and effort on it. Thanks, --Ron From list-mgr@ISI.EDU Wed Jan 18 01:44:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 09:46:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 09:44:21 -0800 Received: from mic.ucla.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 09:44:20 -0800 Received: from caviar.mic.ucla.edu by mic.ucla.edu (4.1/MIC1.01) id AA01243; Wed, 18 Jan 95 09:44:19 PST Received: (from wada@localhost) by caviar.mic.ucla.edu (8.6.9/8.6.9) id JAA02119 for mbone@isi.edu; Wed, 18 Jan 1995 09:44:13 -0800 From: Kent Wada Message-Id: <199501181744.JAA02119@caviar.mic.ucla.edu> Subject: campus MBONE policy documents? To: mbone Date: Wed, 18 Jan 1995 09:44:13 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 876 We are currently planning to put together a couple of documents on the use of the MBONE at UCLA, probably in the form of an operational policy document, and a FAQ on what you need to get started here on campus. The goal is not to have everyone jump onto the MBONE bandwagon instantly, but to try and set down the important guiding principles and requirements for when people come knocking on our door to be connected. The FAQ would be contain as much local information as we can think of, plus pointers to all the resources already out there on the net. We'd be very interested to hear if anyone has already done something similar. Comments are welcome, of course. -Kent -- Kent Wada Coordinator, Advanced Workstation Program UCLA/OAC Microcomputer Support Office Tel: +1 310 206 3874 / FAX: +1 310 206 1700 WWW: http://www.ucla.edu/bios/kentwada.html From list-mgr@ISI.EDU Wed Jan 18 07:47:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 09:48:49 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 09:47:15 -0800 Received: from home.merit.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 09:47:13 -0800 Received: from localhost (ljb@localhost) by home.merit.edu (8.6.9/merit-2.0) with SMTP id MAA10875; Wed, 18 Jan 1995 12:47:12 -0500 Message-Id: <199501181747.MAA10875@home.merit.edu> To: Stephen Casner Cc: fenner@cmf.nrl.navy.mil, MBONE Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) In-Reply-To: Your message of "Tue, 17 Jan 1995 21:17:14 PST." <790406234.0.CASNER@XFR.ISI.EDU> Date: Wed, 18 Jan 1995 12:47:11 -0500 From: "Larry J. Blunk" > > Only 272 out of the 1200 mrouters in my last map were at 3.3 . > > >From the comments I've received back in response to my exhortations > on this subject, part of the explanation is that many of the mrouters > are not SPARCs running SunOS. > -- Steve > ------- Do we have any updates on ports of ipmulti-3.3 to Solaris 2.x and SGI's IRIX. We have several customers running these and they're bleating at me since we've made 3.3 a requirement here. Larry J. Blunk Merit/MichNet From list-mgr@ISI.EDU Wed Jan 18 22:27:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 10:31:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 10:28:21 -0800 Received: from castor.cc.utu.fi by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 10:28:13 -0800 Received: by utu.fi id <166289-2>; Wed, 18 Jan 1995 20:28:05 +0200 Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) From: Matti Aarnio To: ljb@merit.edu (Larry J. Blunk) Date: Wed, 18 Jan 1995 20:27:51 +0200 (EET) Cc: mbone In-Reply-To: <199501181747.MAA10875@home.merit.edu> from "Larry J. Blunk" at Jan 18, 95 12:47:11 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 568 Message-Id: <95Jan18.202805+0200_eet.166289-2+349@utu.fi> > > > Only 272 out of the 1200 mrouters in my last map were at 3.3 . ... > Do we have any updates on ports of ipmulti-3.3 to Solaris 2.x and > SGI's IRIX. We have several customers running these and they're bleating > at me since we've made 3.3 a requirement here. I recall a comment from Sun engineer either here on MBONE, or on REM-CONF who said that SPARC-Solaris-2.4 will have the kernel aspects of the ipmulti-3.3. I am yet to get my Solaris 2.4... (i386+ version didn't have it) > Larry J. Blunk > Merit/MichNet /Matti Aarnio From list-mgr@ISI.EDU Wed Jan 18 18:54:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 10:56:10 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 10:55:21 -0800 Received: from mailsun.aber.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 10:55:12 -0800 Received: from mailhost.aber.ac.uk (actually host thorbb.dcs.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Wed, 18 Jan 1995 18:54:38 +0000 To: Matti Aarnio , mbone Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) In-Reply-To: Your message of Wed, 18 Jan 1995 20:27:51 +0200. <95Jan18.202805+0200_eet.166289-2+349@utu.fi> Date: Wed, 18 Jan 1995 18:54:34 +0000 Message-Id: <7687.790455274@mailhost.aber.ac.uk> From: D E PRICE Dear All, I must say that I am specifically holding back on an upgrade to `3.3' hoping that I can just install Solaris 2.4. There must be many other like this. Can we not get an `official' verdict + test verification of what Solaris 2.4 will give us? Dave Price From list-mgr@ISI.EDU Wed Jan 18 08:59:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 11:03:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 11:01:07 -0800 Received: from VIXEN.CS.UTK.EDU by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 11:01:05 -0800 Received: from LOCALHOST.cs.utk.edu by vixen.cs.utk.edu with SMTP (cf v2.9c-UTK) id OAA09948; Wed, 18 Jan 1995 14:00:06 -0500 Message-Id: <199501181900.OAA09948@vixen.cs.utk.edu> To: ron@nuku.nosc.mil Cc: mbone, rem-conf@es.net Reply-To: ron@nuku.nosc.mil Subject: Re: IP Multicast for 4.1.4? In-Reply-To: Your message of Wed, 18 Jan 1995 09:29:34 -0800. <9501181729.AA03774@neko.nosc.mil> Date: Wed, 18 Jan 1995 13:59:27 -0500 From: Judi Theg Talley You spoke thusly: > Does anyone know if the multicast 3.3 release (ipmulti3.3-sunos413x.tar.Z) will > drop into a SunOS 4.1.4 kernel? And work? > > We are about to attempt this but would like to be warned right away if there is > a problem with this, so we don't waste time and effort on it. > > Thanks, > > --Ron We installed this on a SS5 running 4.1.4 and everything seems to be fine. No crashes yet... (It's not an mrouter, tho.) Reception is fine, including audio. Just dropped in and ran. 'Course, it's been only a week. Enjoy! Judi --- Judi Theg Talley There are no good system administrators, merely temporarily satisfied users. --Tim Martin, UT Sys Admin From list-mgr@ISI.EDU Wed Jan 18 23:02:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 11:04:47 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 11:03:15 -0800 Received: from castor.cc.utu.fi by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 11:03:12 -0800 Received: by utu.fi id <166290-2>; Wed, 18 Jan 1995 21:03:00 +0200 Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) From: Matti Aarnio To: Juha.Heinanen@lohi.dat.tele.fi (Juha Heinanen) Date: Wed, 18 Jan 1995 21:02:49 +0200 (EET) Cc: pusateri@cs.duke.edu, dsc@nwnet.net, MBONE In-Reply-To: <199501181520.AA10194@venera.isi.edu> from "Juha Heinanen" at Jan 18, 95 05:14:41 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 660 Message-Id: <95Jan18.210300+0200_eet.166290-2+353@utu.fi> > In order to promote more widespread use, gated PIM will soon run on a > slightly modified 3.3 kernel as well. The modifications required will > be sent back to Ajit, Steve, and friends to hopefully be included in a > subsequent release. This is probably still a month or so away. > > if you really would like to have widespread use, a port to linux would > be very desirable. Indeed, however so far the Linux kernel does not have ANY of the necessary kernel aspects of routing. It will join local multicast channels on the Ethernet, but that is not enough.. ( Linux kernel version 1.1.82 ) > -- juha /Matti Aarnio From list-mgr@ISI.EDU Wed Jan 18 19:08:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 11:11:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 11:08:56 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 11:08:43 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id TAA08730; Wed, 18 Jan 1995 19:08:36 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id TAA08829; Wed, 18 Jan 1995 19:08:30 GMT Date: Wed, 18 Jan 1995 19:08:29 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: D E PRICE Cc: mbone Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) In-Reply-To: <7687.790455274@mailhost.aber.ac.uk> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 18 Jan 1995, D E PRICE wrote: > Dear All, > I must say that I am specifically holding back > on an upgrade to `3.3' hoping that I can just install > Solaris 2.4. There must be many other like this. > > Can we not get an `official' verdict + test verification > of what Solaris 2.4 will give us? Support for 3.3 is not in Solaris 2.4 Early Access. I cannot categorically state that it is not in the 11/94 release but I can see no indications from the release notes or documentation that it does. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Wed Jan 18 18:10:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 11:42:24 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 11:40:58 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 11:40:53 -0800 Received: from scorpio.ucs.ed.ac.uk (root@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id TAA08868; Wed, 18 Jan 1995 19:40:03 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id SAA08607; Wed, 18 Jan 1995 18:10:51 GMT Date: Wed, 18 Jan 1995 18:10:49 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Kent Wada Cc: mbone Subject: Re: campus MBONE policy documents? In-Reply-To: <199501181744.JAA02119@caviar.mic.ucla.edu> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 18 Jan 1995, Kent Wada wrote: > We are currently planning to put together a couple of documents on the > use of the MBONE at UCLA, probably in the form of an operational > policy document, and a FAQ on what you need to get started here on > campus. The goal is not to have everyone jump onto the MBONE bandwagon > instantly, but to try and set down the important guiding principles > and requirements for when people come knocking on our door to be > connected. The FAQ would be contain as much local information as we > can think of, plus pointers to all the resources already out there on > the net. > > We'd be very interested to hear if anyone has already done something > similar. Comments are welcome, of course. You might care to look at the Web servers provided by the MICE National Support Centres in Europe. These servers contain documentation produced by MICE on using conferencing tools and also on how to go about preparing for a conference. The pages also contain many links to documents produced elsewhere, such as the MBONE FAQ. The URL is http://www.cs.ucl.ac.uk/mice/mice-nsc/ ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Wed Jan 18 10:06:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 12:08:00 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 12:07:01 -0800 Received: from herman.cmf.nrl.navy.mil by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 12:06:58 -0800 Received: from localhost (fenner@localhost) by herman.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id PAA07172; Wed, 18 Jan 1995 15:06:52 -0500 Message-Id: <199501182006.PAA07172@herman.cmf.nrl.navy.mil> X-Mailer: exmh version 1.5.1 12/2/94 To: David Comay Cc: MBONE Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) In-Reply-To: Your message of "Wed, 18 Jan 95 00:36:59 PST." X-Face: -*.ZYbFWa}{2c8NmF| > speaking of which, could someone in the know comment on the progress of > the 3.3 port for bsdi? I don't know about BSDI, but FreeBSD 2.0 includes mrouted 3.3, and I think NetBSD 1.0 might as well. I would think that either of those pieces of code would be the proper place to start if you were going to do a BSDI port. Bill From list-mgr@ISI.EDU Wed Jan 18 04:15:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 12:17:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 12:16:13 -0800 Received: from ell.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 12:16:12 -0800 Received: by ell.ee.lbl.gov (8.6.9/1.43r) id MAA15522; Wed, 18 Jan 1995 12:16:00 -0800 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199501182016.MAA15522@ell.ee.lbl.gov> To: jhawk@MIT.EDU Cc: mbone Subject: Re: Grey Rects at Usenix In-Reply-To: Your message of Wed, 18 Jan 95 04:12:22 -0500. <9501180912.AA28695@bill-the-cat.MIT.EDU> Date: Wed, 18 Jan 95 12:15:59 PST > The USENIX keynote vic video is currently receiving two gray rectangles > (At low bandwith, but still there). Somebody should please shut these > off. One is from 128.3.112.135, and seems to come from LBL. The other > is 192.35.215.130, which is mbtest.ucop.edu... The gray rectangles are actually caused by session packets appearing on the data port, or vice versa. Fortunately, a change to the RTPv2 spec at the last IETF meeting will allow detection of this condition. The next version of vic will do this. The immediate problem is due to a rogue (vic-2.7a?) SGI binary that we gave to a few sites for testing. It has a bug where some of the session packets end up on the data port. Steve From list-mgr@ISI.EDU Wed Jan 18 21:30:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 13:33:45 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 13:29:25 -0800 Received: from nlm.nih.gov (lhc.nlm.nih.gov) by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 13:29:16 -0800 Received: from billings.csb (billings.nlm.nih.gov) by nlm.nih.gov (4.1/SMI-4.0) id AA14598; Wed, 18 Jan 95 16:29:13 EST Received: by billings.csb (5.0/SMI-SVR4) id AA20169; Wed, 18 Jan 1995 16:30:33 +0500 Date: Wed, 18 Jan 1995 16:30:33 +0500 From: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Message-Id: <9501182130.AA20169@billings.csb> To: mbone Subject: Re: campus MBONE policy documents? X-Sun-Charset: US-ASCII Content-Length: 954 On Wed, 18 Jan 1995, Graeme Wood wrote: > On Wed, 18 Jan 1995, Kent Wada wrote: > > > We are currently planning to put together a couple of documents on the > > use of the MBONE at UCLA, probably in the form of an operational > > policy document, and a FAQ on what you need to get started here on > > campus [...] > > We'd be very interested to hear if anyone has already done something > > similar. Comments are welcome, of course. > > You might care to look at the Web servers provided by the MICE National > Support Centres in Europe for your multimedia conferencing support. Another potentially useful reference is the report we put together about our experiences trying to multicast the 2nd International World-Wide Web Conf. from Chicago last October: http://www.nlm.nih.gov/reports.dir/multicasting.dir/report.html Let us all know about your final document(s), as they may be quite useful to the broad community... Cheerio, Rick Rodgers From list-mgr@ISI.EDU Wed Jan 18 06:30:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:26:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:14:45 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:14:44 -0800 Received: from power.net (touchstone.power.net) by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 14:34:58 -0800 Received: by power.net (Smail3.1.28.1 #11) id m0rUitW-000syCC; Wed, 18 Jan 95 14:30 PST Date: Wed, 18 Jan 1995 14:30:26 -0800 (PST) From: Elias Levy To: Juha Heinanen Cc: pusateri@cs.duke.edu, dsc@nwnet.net, MBONE Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) In-Reply-To: <199501181520.AA10194@venera.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 18 Jan 1995, Juha Heinanen wrote: > > In order to promote more widespread use, gated PIM will soon run on a > slightly modified 3.3 kernel as well. The modifications required will > be sent back to Ajit, Steve, and friends to hopefully be included in a > subsequent release. This is probably still a month or so away. > > if you really would like to have widespread use, a port to linux would > be very desirable. > > -- juha > I must second this one. Most other tools other than VAT have already been ported. All that is missing now is a multicast router for linux. elias@power.net (Elias Levy) PowerNet, Inc. From list-mgr@ISI.EDU Wed Jan 18 12:25:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:37:30 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:36:13 -0800 Received: from relay.hp.com by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:36:12 -0800 Received: from it_750.ch.apollo.hp.com by relay.hp.com with SMTP (1.37.109.14/15.5+ECS 3.3) id AA243627944; Wed, 18 Jan 1995 14:25:44 -0800 Message-Id: <199501182225.AA243627944@relay.hp.com> Received: from dcetv.ch.apollo.hp.com by it_750.ch.apollo.hp.com for MBONE@ISI.EDU id AA09517; Wed, 18 Jan 1995 17:25:43 -0500 To: "William C. Fenner" Cc: David Comay , MBONE Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) In-Reply-To: Your message of "Wed, 18 Jan 1995 15:06:51 EST." <199501182006.PAA07172@herman.cmf.nrl.navy.mil> X-Mailer: exmh version 1.4.1 7/21/94 Date: Wed, 18 Jan 1995 17:25:41 -0500 From: John Brezak > > speaking of which, could someone in the know comment on the progress of > > the 3.3 port for bsdi? > > I don't know about BSDI, but FreeBSD 2.0 includes mrouted 3.3, and I think > NetBSD 1.0 might as well. I would think that either of those pieces of code > would be the proper place to start if you were going to do a BSDI port. > > Bill > FreeBSD 2.0 has the code but I'm not sure it works as a mrouter. NetBSD 1.0 is underway, but I think that the gated method may be better in the long run. The release 3.3 code needs to be fixed up for a 4.4lite kernel. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5140 From list-mgr@ISI.EDU Thu Jan 19 18:27:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:25:20 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:24:10 -0800 Received: from brolga.cc.uq.oz.au by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:24:04 -0800 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Thu, 19 Jan 1995 08:27:54 +1000 X-Mailer: exmh version 1.5.1 12/2/94 To: video@research.ftp.com Cc: mbone Subject: Re: PC/Windows Video Tool In-Reply-To: Your message of "Wed, 18 Jan 1995 14:34:50 EST." <9501181934.AA15753@mailserv-D.ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jan 1995 08:27:50 +1000 Message-Id: <3597.790468070@brolga.cc.uq.oz.au> From: George Michaelson [I got this on a non-headered list inside FTP. Inc. If you subscribed MBONE to an internal list I'm not 100% sure that meets community standards...] Lovely to hear of a commercial supplier getting into this area. now the nice part is said... Why the &*$% doesn't is do any kind of NV/Vic/CUSeeMe interop? The sources for all three (well cuseeme I'm guessing) are freely available so doing this shouldn't have been that hard. Is it high on the to-do list? We just don't need yet another standard in this area. If you didn't do RTP based encoding, maybe you can explain what problems it has and everyone can progress. Ditto H.261/JPEG/NV/CuSeeMe video encoding algs... -George From list-mgr@ISI.EDU Wed Jan 18 07:23:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:26:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:23:12 -0800 Received: from power.net (touchstone.power.net) by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:23:12 -0800 Received: by power.net (Smail3.1.28.1 #11) id m0rUjiU-000sxWC; Wed, 18 Jan 95 15:23 PST Date: Wed, 18 Jan 1995 15:23:06 -0800 (PST) From: Elias Levy To: mbone Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 18 Jan 1995, Juha Heinanen wrote: > > In order to promote more widespread use, gated PIM will soon run on a > slightly modified 3.3 kernel as well. The modifications required will > be sent back to Ajit, Steve, and friends to hopefully be included in a > subsequent release. This is probably still a month or so away. > > if you really would like to have widespread use, a port to linux would > be very desirable. > > -- juha > I must second this one. Most other tools other than VAT have already been ported. All that is missing now is a multicast router for linux. elias@power.net (Elias Levy) PowerNet, Inc. From list-mgr@ISI.EDU Wed Jan 18 07:24:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:26:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:24:11 -0800 Received: from power.net (touchstone.power.net) by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 18 Jan 1995 15:24:11 -0800 Received: by power.net (Smail3.1.28.1 #11) id m0rUjjR-000sxWC; Wed, 18 Jan 95 15:24 PST Date: Wed, 18 Jan 1995 15:24:05 -0800 (PST) From: Elias Levy To: mbone Subject: Re: Upgrading to 3.3 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 18 Jan 1995, Juha Heinanen wrote: > > In order to promote more widespread use, gated PIM will soon run on a > slightly modified 3.3 kernel as well. The modifications required will > be sent back to Ajit, Steve, and friends to hopefully be included in a > subsequent release. This is probably still a month or so away. > > if you really would like to have widespread use, a port to linux would > be very desirable. > > -- juha > I must second this one. Most other tools other than VAT have already been ported. All that is missing now is a multicast router for linux. elias@power.net (Elias Levy) PowerNet, Inc. From list-mgr@ISI.EDU Thu Jan 19 08:55:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 00:57:24 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 00:56:06 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 00:56:05 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 00:56:03 -0800 Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 19 Jan 1995 08:55:42 +0000 To: George Michaelson Cc: video@research.ftp.com, mbone Subject: Re: PC/Windows Video Tool In-Reply-To: Your message of "Thu, 19 Jan 95 08:27:50 +1000." <3597.790468070@brolga.cc.uq.oz.au> Date: Thu, 19 Jan 95 08:55:37 +0000 Message-Id: <1388.790505737@cs.ucl.ac.uk> From: Jon Crowcroft >[I got this on a non-headered list inside FTP. Inc. If you subscribed MBONE > to an internal list I'm not 100% sure that meets community standards...] hmmmm... >Lovely to hear of a commercial supplier getting into this area. yes - i was pleased tooo.... PCs are (however unfortyunately) with us.... >now the nice part is said... > Why the &*$% doesn't is do any kind of NV/Vic/CUSeeMe interop? well, it could - however, the first priority (as per the spec) is to support formats that occur commonly in Microsoft's Video For Windows to make all desk top video capable programs potentially first class internet citezens - at least one of the encodings (block mode indeo) is pretty bandwidth friendly, so its all fairly ok plus we (UCL CS) have done a fast hack first cut at unix decoder (pre alpha is on ftp://cs.ucl.ac.uk/darpa/loki.tar.Z) which works ok (no user interface, and some of my understanding of X color is non-polynomial) >The sources for all three (well cuseeme I'm guessing) are freely available >so doing this shouldn't have been that hard. cuseeme is non-multicast so far - the FTP folks' stuff is both cuseeme mode AND multicast.... >Is it high on the to-do list? We just don't need yet another standard in >this area. If you didn't do RTP based encoding, maybe you can explain what >problems it has and everyone can progress. Ditto H.261/JPEG/NV/CuSeeMe >video encoding algs... my feeling is that we should encourage the PC tools that conform to the loki spec to _add_ an nv or ivs decode mode, and the unix tools to _add_ a loki mode - it wouldn't be too hard, and it would give maximum flexibility for bandwith v. CPU tradeoff cheers jon From list-mgr@ISI.EDU Thu Jan 19 08:15:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 05:28:40 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 05:26:41 -0800 Received: from research.ftp.com by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 05:26:40 -0800 Received: by Research.Ftp.Com (931110.SGI/) for mbone@isi.edu id AA05578; Thu, 19 Jan 95 08:14:50 -0500 Received: by Research.Ftp.Com id AA05578; Thu, 19 Jan 95 08:14:50 -0500 Date: Thu, 19 Jan 1995 08:14:50 +0001 (EST) From: Frank Kastenholz Subject: Re: PC/Windows Video Tool To: George Michaelson Cc: video@Research.Ftp.Com, mbone In-Reply-To: <3597.790468070@brolga.cc.uq.oz.au> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII George, Thanks for your comments on the video tool. We've not implemented the "standard" encodings. The software was developed as a research effort here, to determine what the issues were surrounding doing video on PCs. Early on it became readily apparent that PCs were a resource challenged environment when it comes to doing video so I decided to keep things as simple as possible. I was, quite honestly, very surprised to see how effective it turned out anyway, and went on working on other things, unrelated to the actual encodings, such as the adaptive transmit rate algorithms. Learning the NV algorithm and formats, per se, were not high on my priority list. Eventually we decided that we should make the excutables available over the net to let anyone play with them, as is. As I said in the announcement, this is not a product, nor is it indicative of any product plans that we may have. Any product that we develop, I imagine, would certainly include an NV encoder/decoder, as well as one that works with VIC and H.261. The software is RTP-based. RTP is a 'sub-layer' over which different encodings can operate. NV, etc, all operate (or will operate) over RTP2, as does my software. The encodings, the way the actual video data is framed and sent over RTP, are different. There are some folks working on developing a decoder for NV, so that NV can receive transmissions from our software. More about that when it's ready... Frank From list-mgr@ISI.EDU Thu Jan 19 04:36:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 06:42:15 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 06:40:52 -0800 Received: from portal.netedge.com by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 06:40:50 -0800 Received: from NetEdge.COM by portal.netedge.com id AA28650; Thu, 19 Jan 95 09:39:05 EST Received: from suicidesix.NetEdge.COM by NetEdge.COM id AA16264; Thu, 19 Jan 95 09:40:02 EST Return-Path: Received: from localhost by suicidesix.NetEdge.COM (4.1/NECL-6.14) id AA12690; Thu, 19 Jan 95 09:36:02 EST Message-Id: <9501191436.AA12690@NetEdge.COM> To: "William C. Fenner" Cc: David Comay , MBONE Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) In-Reply-To: Your message of "Wed, 18 Jan 1995 15:06:51 EST." <199501182006.PAA07172@herman.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <12687.790526161.1@suicidesix> Date: Thu, 19 Jan 1995 09:36:01 -0500 From: Thomas Pusateri In message <199501182006.PAA07172@herman.cmf.nrl.navy.mil> you write: >> speaking of which, could someone in the know comment on the progress of >> the 3.3 port for bsdi? > >I don't know about BSDI, but FreeBSD 2.0 includes mrouted 3.3, and I think >NetBSD 1.0 might as well. I would think that either of those pieces of code >would be the proper place to start if you were going to do a BSDI port. > > Bill No. NetBSD 1.0 does not. It still has the 2.x version that came with BSD 4.4 Lite. I would talk to the BSDI folks before doing a port because I think they are working on this. Tom From list-mgr@ISI.EDU Thu Jan 19 05:41:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 07:42:47 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 07:41:53 -0800 Received: from enfm.utcc.utoronto.ca by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 07:41:51 -0800 Received: from localhost by enfm.utcc.utoronto.ca with SMTP id <606540>; Thu, 19 Jan 1995 10:41:40 -0500 To: mbone Subject: change in Canadian mbone connectivity Organization: UT Network & Operations Services, External Network Fac. Mgmt. Phone: +1 416 978 3328 Date: Thu, 19 Jan 1995 10:41:21 -0500 From: "Eric M. Carroll" Message-Id: <95Jan19.104140est.606540@enfm.utcc.utoronto.ca> I am not sure who tracks this stuff anymore, but mbone.on.canet.ca now has a tunnel up to homeric.merit.edu, thanks to Merit and CICnet. This is better suited to being connected to MCI. The tunnel from mbone.on.canet.ca to Cornell has been removed. Eric Carroll University of Toronto Network & Operations Services External Networking Facilities Management CA*net Network Engineering From list-mgr@ISI.EDU Thu Jan 19 02:42:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 10:58:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 10:42:58 -0800 Received: from aphid.fhcrc.org by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 10:42:57 -0800 Received: from fred.fhcrc.org by aphid.fhcrc.org (5.0/SMI-SVR4) id AA17670; Thu, 19 Jan 1995 10:48:49 +0800 Received: from [140.107.32.78] (mparker-mac) by fred.fhcrc.org (4.1/SMI-4.1) id AA13109; Thu, 19 Jan 95 10:42:07 PST Message-Id: <9501191842.AA13109@fred.fhcrc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jan 1995 10:42:56 -0800 To: mbone From: mparker@fred.fhcrc.org (Michael Parker) Subject: Where is VIC Content-Length: 76 Could someone please point me to the location of VIC for Solaris. Thanks From list-mgr@ISI.EDU Thu Jan 19 19:12:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 11:17:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 11:16:17 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 11:13:04 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id TAA22148; Thu, 19 Jan 1995 19:12:31 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id TAA01944; Thu, 19 Jan 1995 19:12:30 GMT Date: Thu, 19 Jan 1995 19:12:30 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Michael Parker Cc: mbone Subject: Re: Where is VIC In-Reply-To: <9501191842.AA13109@fred.fhcrc.org> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Jan 1995, Michael Parker wrote: > Could someone please point me to the location of VIC for Solaris. ftp://ftp.ee.lbl.gov/conferencing/vic/vic-*.tar.Z ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Wed Jan 18 17:02:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 11:30:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 11:28:53 -0800 Received: from elroy.jpl.nasa.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 11:28:51 -0800 Received: from isolar.UUCP by elroy.jpl.nasa.gov (4.1/SMI-4.1+DXR) id AA17513; Thu, 19 Jan 95 04:45:57 PST Received: by isolar.Tujunga.CA.US (4.1/SATAN-6.6.6) id AA17695; Thu, 19 Jan 95 01:02:27 PST Date: Thu, 19 Jan 95 01:02:27 PST From: earle@isolar.Tujunga.CA.US (Greg Earle) Message-Id: <9501190902.AA17695@isolar.Tujunga.CA.US> To: mbone Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) Newsgroups: jpl.mail.mbone In-Reply-To: <790406234.0.CASNER@XFR.ISI.EDU> References: <790406234.0.CASNER@XFR.ISI.EDU> <199501172020.PAA01851@herman.cmf.nrl.navy.mil> Organization: Personal Usenet site, Tujunga, CA USA Cc: casner In article <790406234.0.CASNER@XFR.ISI.EDU> you write: >> Only 272 out of the 1200 mrouters in my last map were at 3.3 . > > From the comments I've received back in response to my exhortations > on this subject, part of the explanation is that many of the mrouters > are not SPARCs running SunOS. While we're on the subject, my $0.02: the reason I haven't upgraded my mrouter from 2.2 to 3.3 (it's a Sun-4/380 ... you know, one of those boxes that Sun isn't supporting anymore, starting with Solaris 2.5 ... NetBSD/SPARC, anyone?) My mrouter has a Sun VMEbus FDDI board (yes, one of *those* hoary old gee-this- doesn't-get-100-Mbit/sec,-it-gets-15-Mbit/sec-with-a-good-tailwind boards). It was a *bitch* to get the 2.2 Multicast code to work on it. I was waiting for 3.3 to be declared "stable" by someone who knows better than I, and *then* I was hoping that some brave soul had charted the same waters with this old crippled hardware and thus avoid the considerable pain to get it working that 2.2 was. Anyone else with an mrouter that has a Sun FDDI board running SunLink FDDI/DX 2.0 software under 4.1.3 that has braved the upgrade to 3.3 and lived, please drop me a line and I'll endeavor to change Steve's statistics to 273 ... - Greg From list-mgr@ISI.EDU Thu Jan 19 05:48:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 13:49:10 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 13:48:27 -0800 Received: from Sun.COM by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 13:48:26 -0800 Received: from Eng.Sun.COM ([129.145.1.18]) by Sun.COM (sun-barr.Sun.COM) id AA22052; Thu, 19 Jan 95 13:48:22 PST Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25189; Thu, 19 Jan 95 13:48:11 PST Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id NAA20905; Thu, 19 Jan 1995 13:48:21 -0800 Received: by bobo.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id NAA11351; Thu, 19 Jan 1995 13:48:08 -0800 Date: Thu, 19 Jan 1995 13:48:08 -0800 From: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Message-Id: <199501192148.NAA11351@bobo.Eng.Sun.COM> To: dap@aber.ac.uk Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) Cc: mbone, nordmark@jurassic-248.Eng.Sun.COM Mime-Version: 1.0 > I must say that I am specifically holding back > on an upgrade to `3.3' hoping that I can just install > Solaris 2.4. There must be many other like this. > > Can we not get an `official' verdict + test verification > of what Solaris 2.4 will give us? Solaris 2.4 does not contain 3.3 multicast support. We are currently working on 3.3. When this work is done and tested we plan on making 3.3 available (pick it up using FTP) for Solaris 2.3 and 2.4. Erik Nordmark Internet Engineering SunSoft From list-mgr@ISI.EDU Thu Jan 19 13:34:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 15:37:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 15:35:03 -0800 Received: from wizard.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 19 Jan 1995 15:34:58 -0800 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA03053; Thu, 19 Jan 95 18:34:52 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9501192334.AA03053@wizard.gsfc.nasa.gov> Subject: Re: campus MBONE policy documents? To: wada@mic.ucla.edu (Kent Wada) Date: Thu, 19 Jan 1995 18:34:51 -0500 (EST) Cc: mbone In-Reply-To: <199501181744.JAA02119@caviar.mic.ucla.edu> from "Kent Wada" at Jan 18, 95 09:44:13 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 10596 > We are currently planning to put together a couple of documents on the > use of the MBONE at UCLA, probably in the form of an operational > policy document, and a FAQ on what you need to get started here on > campus. The goal is not to have everyone jump onto the MBONE bandwagon > instantly, but to try and set down the important guiding principles > and requirements for when people come knocking on our door to be > connected. The FAQ would be contain as much local information as we > can think of, plus pointers to all the resources already out there on > the net. > > We'd be very interested to hear if anyone has already done something > similar. Comments are welcome, of course. > > -Kent Kent, Here's something I recently wrote up for the NASA Goddard campus regarding MBone usage. Feel free to use any of it you might find useful. I also usually include a copy of the Steve Casner FAQ and Dan Mosedale's Quick and Dirty Guide to Getting Connected to the MBONE. -Bill P.S. Some terminology: CNE = our Center Network Environment Rib = User Ethernet or FDDI network segment Rib Manager = Person responsible for a Rib NASA GSFC MBone FAQ: ------------------------------------------------------------------------ Here are the current steps for getting GSFC MBone connectivity: 0. The users must recognize that the MBone is a pilot, experimental capability and as such has certain risks and does not have the same level of support as other CNE services. They should not rely on it for any truly critical applications, although it is usually fairly stable. It is still evolving at a rapid rate and users of this technology should be able to adapt to rapid changes in their environment. Current GSFC support for MBone activities is on an as available basis at a relatively low priority (but slowly increasing as more users start to take advantage of it). Because of the bare bones support, changes may sometimes be made with minimal or no advance notice. 1. Because of the extensive bandwidth requirements and other considerations, we only support MBone connectivity to Ribs that are behind a router with a CNE FDDI connection. 2. A multicast tunnel will need to be set up to your subnet if it doesn't already have MBone connectivity. The following conditions must be met for setting up and operating MBone routers. a. The Rib Manager must give approval for the multicast and tunnel traffic to be transmitted on the Rib. b. The mrouted software must be kept up-to-date with the latest version adopted for general use on the MBone. This is required for the health and optimal functioning of the global MBone. c. One of the provisos for getting a tunnel to your subnet is agreeing to provide 3 or 4 tunnels to other subnets, if and when this is deemed appropriate by the IP Protocol Manager. We have limited resources at present to support MBone activities at Goddard and so it is necessary for those who want to participate to share their resources with others to provide maximum coverage and benefit to everyone. d. IP multicast tunnel support is fairly CPU intensive, and thus it is necessary to have some assurance that the MBone router system has sufficient free CPU cycles available to properly support the required tunnels, i.e. it should comfortably handle up to 5 tunnels along with its other normal functions. e. Any topology changes such as new tunnels or new interfaces being added to the MBone router system must be coordinated and approved by the IP Protocol Manager in advance. f. The following Standard Multicast IP Router Agreement must be agreed and adhered to. ======== Standard Multicast IP Router Agreement ======== In order to do multicast IP routing at GSFC, you must agree to the following: 1. Initial configuration and *ALL* changes require the approval of the IP Protocol Manager. 2. The IP Protocol Manager is to have a non-privileged account on the MBone router system for the purpose of monitoring the MBone router, and needs to have access to ping and traceroute tools on that system (and other normal network monitoring commands such as netstat and ifconfig). Access to tcpdump is highly desirable. 3. mrouted or other network configuration changes requested by the IP Protocol Manager need to be handled expeditiously. These include such changes as adding new tunnels, changing tunnel endpoints, changing tunnel parameters such as threshold, or changing system routing tables for configured tunnels. 4. In case of emergencies, the IP Protocol Manager reserves the right to shut down the multicast tunnel to the MBone router system. It would be highly desirable for the IP Protocol Manager to have a mechanism for modifying the mrouted configuration on the MBone router system, and to be able to shut down or restart the mrouted process on the MBone router system. 3. You will need to have or build an IP Multicasting kernel for your system. 4. FDDI gotcha: If you have a Sun SPARC system with the Sun FDDI board, you will also need to apply the Anders Klemets FDDI driver patches. With this patch, the FDDI interface will be able to coexist with the IP Multicasting kernel, and it will be able to support FDDI tunnels, but it will *NOT* support actually doing IP multicasting on the FDDI network. There are other vendors Sun FDDI boards, such as Crescendo, which do fully support IP multicasting on the FDDI interface (although they may still require the Anders Klemets FDDI driver patches). 5. You will need to obtain (and keep up-to-date) the multicasting tools such as sd, vat, nv, vic, and wb for your system. Many of these tools are available via anonymous ftp on ftp.ee.lbl.gov in subdirectories of the conferencing directory. 6. Once the above has been done, you should be in position to receive multicast conferences such as the IETF and NASA Space Shuttle missions. 7. For any multicast transmissions you want to initiate from Goddard, you should adhere to the following guidelines and acceptable use policies: a. Origination of any conferences or other multicast transmissions with a Goddard-wide or wider scope should be announced in advance to the IP Protocol Manager by sending e-mail to mbone@gsfc.nasa.gov. This is so if anything goes haywire, we'll know about it, and quickly know who to contact to fix the problem, or what to shut down if we can't get in touch with anyone. In addition, origination of any global conferences should be coordinated well in advance via the Rem-Conf Internet e-mail list (see below). This is so the limited global MBone resources can be equitably shared among all its worldwide users. b. Always keep in mind what TTL you are using for multicast transmissions and the related scope of the multicast transmission. Always use the smallest applicable TTL/scope. TTL Scope --- ----- 1 Local subnet 15 Local project or organization 31 GSFC-wide 47 All NASA Centers 63 All NASA Centers & affiliated sites >63 Worldwide c. Limit the amount of bandwidth you use for multicast transmissions. In general, don't use more than 128 Kbps for video transmissions, and *NEVER* use more than 128 Kbps for worldwide video transmissions. d. It is generally a very bad idea to leave multicast transmissions run unattended, especially if they are multicast beyond your local subnet. e. Radio station type audio multicasts are severely frowned upon outside your local subnet, and this is especially true if sent worldwide. There is a special multicast session already set up called Radio Free Vat for people who would like to play DJ, and is only used when it doesn't conflict with other more significant events. f. Please use common sense whenever transmitting. Don't for example leave an open mike while listening in on a worldwide audio multicast such as the IETF, or send your own video to a public conference unless requested to do so. Practice just listening and viewing first, and getting familiar with the multicast applications in a receive only mode, before trying sending your own audio or video, especially in worldwide conferences. g. If you are transmitting audio or video to a public conference, don't forget you're "live" and inadvertently do something you wouldn't want to be seen or heard in public. 8. It is highly recommended that you subscribe to the rem-conf@es.net mailing list by sending a message to rem-conf-request@es.net. This list is for general discussion of remote conferencing, announcements of public multicast conferences, and to learn about new or updated multicast applications and protocols. You may also want to subscribe to the mbone@isi.edu mailing list by sending a message to mbone-nasa-request@nsipo.nasa.gov (they handle all NASA requests to be added to the mbone@isi.edu mailing list). This list is for discussions of the global MBone topology and infrastructure including problem reporting, IP Multicast kernel and mrouted, multicast routing, and tools to assist with monitoring and troubleshooting IP multicasting. People responsible for MBone router systems should probably be on this list (and actively pay attention to it). 9. This is a final reminder that the MBone is a constantly and rapidly changing environment and is not for the timid, but it can be very exciting and rewarding for those who are ready for it and put in the effort. And just as the MBone is subject to continual change, these rules and guidelines are also subject to changes as new conditions warrant. 10. For those non-Unix types, there's something called CU-SeeMe that does audio and video conferencing for Macs and PCs but that's a whole separate topic (it's somewhat limited at present because Macs and PCs don't currently have IP multicast support but that's also coming in the not too distant future). Please direct any questions to mbone@gsfc.nasa.gov. ------------------------------------------------------------------------ From list-mgr@ISI.EDU Sat Jan 21 05:04:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sat, 21 Jan 1995 13:17:18 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sat, 21 Jan 1995 13:04:16 -0800 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-20) id ; Sat, 21 Jan 1995 13:04:15 -0800 Received: from grus.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA01818; Sat, 21 Jan 95 13:04:58 PST Date: Sat, 21 Jan 1995 13:04:57 -0800 (PST) From: Michael Macedonia To: rem-conf@es.net Cc: mbone, carl@radio.com Subject: Ideas for Confernce Connection In-Reply-To: <9501161249.AA01999@rx7.ee.lbl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Background: The ACM Symposium on 3D Interactive Graphics is going to be held at the Hyatt in Monterey, CA in April. This is a big event for the technical SIGGRAPH folks (Apple, SGI, HP, Sun, etc) and this year we are putting on a demo of the NPSNET 3D vehicle/human simulator over Mbone in conjuction with NRL, GMU, and others. Essentialy, we want to show the future of networked interactive 3D entertainment to the community. Loaded Questions: Whats the best way to connect the demo to the Mbone? I was impressed by the IETF setup. Whats required to get that level of quality? Any folks interested in helping? Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From list-mgr@ISI.EDU Wed Jan 25 09:29:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 25 Jan 1995 01:34:21 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 25 Jan 1995 01:32:15 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 25 Jan 1995 01:32:13 -0800 Received: from mailsun.aber.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 25 Jan 1995 01:32:10 -0800 Received: from mailhost.aber.ac.uk (actually host thorbb.dcs.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Wed, 25 Jan 1995 09:29:36 +0000 To: ron@nuku.nosc.mil Cc: mbone, rem-conf@es.net, cooper@nuku.nosc.mil, dap@aber.ac.uk Subject: Re: IP Multicast for 4.1.4? In-Reply-To: Your message of Wed, 18 Jan 1995 09:29:34 -0800. <9501181729.AA03774@neko.nosc.mil> Date: Wed, 25 Jan 1995 09:29:18 +0000 Message-Id: <10172.791026158@mailhost.aber.ac.uk> From: D E PRICE Dear Ron, A few days agao, I posted on this same topic and received the following from a Sun man.... Dave Price Date: Thu, 19 Jan 1995 13:48:08 -0800 From: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Message-Id: <199501192148.NAA11351@bobo.Eng.Sun.COM> To: dap@aber.ac.uk Subject: Re: Upgrading to 3.3 (Was: IMS audio dropouts, ...) Cc: mbone@ISI.EDU, nordmark@jurassic-248.Eng.Sun.COM Mime-Version: 1.0 > I must say that I am specifically holding back > on an upgrade to `3.3' hoping that I can just install > Solaris 2.4. There must be many other like this. > > Can we not get an `official' verdict + test verification > of what Solaris 2.4 will give us? Solaris 2.4 does not contain 3.3 multicast support. We are currently working on 3.3. When this work is done and tested we plan on making 3.3 available (pick it up using FTP) for Solaris 2.3 and 2.4. Erik Nordmark Internet Engineering SunSoft From list-mgr@ISI.EDU Wed Jan 25 00:36:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 25 Jan 1995 03:43:01 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 25 Jan 1995 03:40:05 -0800 Received: from andy.dia.atd.net by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 25 Jan 1995 03:40:04 -0800 Received: (from crobson@localhost) by andy.dia.atd.net (8.6.9/8.6.9) id FAA00495; Wed, 25 Jan 1995 05:36:46 -0500 Date: Wed, 25 Jan 1995 05:36:45 -0500 (EST) From: Chris Robson ATDNet Admin Subject: MBONE, Firewalls vs. Security To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks Does anyone have info on the MBONE and it's use through a Firewall. I.e. what are the security issues? How much or will the MBONE compromise the firewall? tks......chris From list-mgr@ISI.EDU Thu Jan 26 13:36:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 26 Jan 1995 03:43:10 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 26 Jan 1995 03:38:02 -0800 Received: from mgate.uni-hannover.de by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 26 Jan 1995 03:37:06 -0800 Received: from helios.tnt.uni-hannover.de by mgate.uni-hannover.de with SMTP (PP); Thu, 26 Jan 1995 12:38:08 +0100 Received: from ikarus.tnt.uni-hannover.de by helios.tnt.uni-hannover.de (4.1/SMI-4.1) id AA25818; Thu, 26 Jan 95 12:36:10 +0100 Date: Thu, 26 Jan 95 12:36:10 +0100 From: bloemer@tnt.uni-hannover.de (Arnold Bloemer) Message-Id: <9501261136.AA25818@helios.tnt.uni-hannover.de> To: mbone, rem-conf@es.net, mbone-de@informatik.uni-erlangen.de Subject: MBone Demo Session, Today 13:45 - 14:15 MET (GMT+1) Cc: gruen@rvs.uni-hannover.de My boss just told me, that I should give a short MBone demo to some guests. Sorry for the very late announcement. The session is announced via sd. We will use vat, vic and wb. Please join in if you like! A test will take place from 13:45 - 14:00 MET (GMT+1), the demo approximately from 14:00 - 14:15 MET (GMT+1). If there are any conflicts with other sessions, please send me a mail, I would then lower ttl. Arnold P.S.: I would like to demonstrate the h261 mode of vic. If you haven't got vic, it is available from ftp://ftp.ee.lbl.gov:/conferencing/vic ________________________________________________________________________________ Dipl.-Ing. Arnold Bloemer Universitaet Hannover Institut fuer Theoretische Nachrichtentechnik und Informationsverarbeitung bloemer@tnt.uni-hannover.de Appelstrasse 9A fax: +49 511 762-5333 D-30167 Hannover phone: +49 511 762-5320 Germany ________________________________________________________________________________ From list-mgr@ISI.EDU Thu Jan 26 12:34:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 26 Jan 1995 20:37:47 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 26 Jan 1995 20:34:59 -0800 Received: from mic.ucla.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 26 Jan 1995 20:34:57 -0800 Received: from caviar.mic.ucla.edu by mic.ucla.edu (4.1/MIC1.01) id AA26575; Thu, 26 Jan 95 20:34:56 PST Received: (from wada@localhost) by caviar.mic.ucla.edu (8.6.9/8.6.9) id UAA22107; Thu, 26 Jan 1995 20:34:49 -0800 From: Kent Wada Message-Id: <199501270434.UAA22107@caviar.mic.ucla.edu> Subject: campus MBONE policy documents, part II To: mbone Date: Thu, 26 Jan 1995 20:34:48 -0800 (PST) Cc: scott@cns.ucla.edu (Scott Burris) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 813 A few days ago, I sent out a query to this list to see what others had done in putting together local policy documents regarding the use of the MBONE at their site. I received several helpful replies. We have been working on our `UCLA MBONE FAQ', and have a draft which we would like to put out for comment. It was quite a bit more difficult than expected: there is a delicate line between documenting important items while not reinventing the wheel. It can be found at http://caviar.mic.ucla.edu/uclambone/faq.html Your thoughts and comments would be welcome, but we would prefer to avoid being flamed. :-) -Kent -- Kent Wada Coordinator, Advanced Workstation Program UCLA/OAC Microcomputer Support Office Tel: +1 310 206 3874 / FAX: +1 310 206 1700 WWW: http://caviar.mic.ucla.edu/ From list-mgr@ISI.EDU Fri Jan 27 12:02:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 04:06:24 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 04:04:03 -0800 Received: from lust.mrrl.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 04:03:04 -0800 Received: from localhost (martin@localhost) by lust.mrrl.lut.ac.uk (8.6.9/8.6.9) with SMTP id MAA12524 for ; Fri, 27 Jan 1995 12:02:27 GMT Message-Id: <199501271202.MAA12524@lust.mrrl.lut.ac.uk> X-Mailer: exmh version 1.5.3 12/28/94 To: mbone X-Uri: Subject: ipmulti 3.3 and SunOS 4.1.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Jan 1995 12:02:26 +0000 From: Martin Hamilton Hi, There've been a few queries recently about ipmulti vs. SunOS 4.1.4 I installed ipmulti 3.3 on a SPARC 10 running SunOS 4.1.4 on Jan 3rd, and have been running with it since then without any problems. This week I turned the machine into an mrouter, and it still seems to be behaving itself I've been using various incantations of tcpdump to keep an eye on the traffic (e.g. "tcpdump -v ip multicast", "tcpdump -v ip proto igmp", ...), plus checking out the mrouted cache and dump. Perhaps there are other things I should be doing -- any suggestions ? The installation (via mcast_install) went smoothly. As I recall, the only change I had to make was symlinking sys.sunos414 -> sys.sunos413_U1 Obviously I would be happier with a kosher ipmulti release for 4.1.4 -- Ajit/Steve, how about it ? Cheerio, Martin From list-mgr@ISI.EDU Sat Jan 28 11:10:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 05:15:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 05:11:19 -0800 Received: from cheops.anu.edu.au by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 05:11:16 -0800 Message-Id: <199501271311.AA18251@venera.isi.edu> Received: by cheops.anu.edu.au (1.38.193.3/16.2) id AA16001; Sat, 28 Jan 95 00:10:56 +1100 From: Darren Reed Subject: Re: ipmulti 3.3 and SunOS 4.1.4 To: martin@mrrl.lut.ac.uk (Martin Hamilton) Date: Sat, 28 Jan 1995 00:10:56 +1100 (EDT) Cc: mbone In-Reply-To: <199501271202.MAA12524@lust.mrrl.lut.ac.uk> from "Martin Hamilton" at Jan 27, 95 12:02:26 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1056 > > Hi, > > There've been a few queries recently about ipmulti vs. SunOS 4.1.4 > > I installed ipmulti 3.3 on a SPARC 10 running SunOS 4.1.4 on Jan 3rd, > and have been running with it since then without any problems. This > week I turned the machine into an mrouter, and it still seems to be > behaving itself > > I've been using various incantations of tcpdump to keep an eye on the > traffic (e.g. "tcpdump -v ip multicast", "tcpdump -v ip proto igmp", > ...), plus checking out the mrouted cache and dump. Perhaps there > are other things I should be doing -- any suggestions ? > > The installation (via mcast_install) went smoothly. As I recall, the > only change I had to make was symlinking sys.sunos414 -> > sys.sunos413_U1 > > Obviously I would be happier with a kosher ipmulti release for 4.1.4 > -- Ajit/Steve, how about it ? ...from my casual observations, at least ip_icmp.{c,o} has changed rather significantly from 4.1.3_U1 to 4.1.4. I'm not sure what this means for other portions of the kernel's networking... darren From list-mgr@ISI.EDU Fri Jan 27 18:32:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 06:34:35 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 06:32:18 -0800 Received: from lohi.dat.tele.fi by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 06:32:15 -0800 Message-Id: <199501271432.AA19349@venera.isi.edu> Received: from lohi.dat.tele.fi by lohi.dat.tele.fi id <03560-0@lohi.dat.tele.fi>; Fri, 27 Jan 1995 16:32:07 +0200 To: mbone Cc: van@ee.lbl.gov Subject: sd for linux Date: Fri, 27 Jan 1995 16:32:07 +0200 From: Juha Heinanen Sender: Juha.Heinanen@lohi.dat.tele.fi i tried to find (without luck) sd sources so that i could compile sd for linux/xfree3.1. does anyone know, if the sources could be obtained from somewhere for such a purpose? -- juha From list-mgr@ISI.EDU Thu Jan 26 21:00:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 06:40:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 06:35:12 -0800 Received: from louie.udel.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 06:35:10 -0800 Received: from snow-white-fddi.udel.edu by louie.udel.edu id aa01165; 27 Jan 95 9:23 EST Received: from louie.udel.edu by snow-white.ee.udel.edu id ab25339; 27 Jan 95 9:23 EST Received: from snow-white.ee.udel.edu by malarky.udel.edu id aa04396; 26 Jan 95 21:00 GMT To: Martin Hamilton Cc: mbone Subject: Re: ipmulti 3.3 and SunOS 4.1.4 In-Reply-To: Your message of "Fri, 27 Jan 1995 12:02:26 GMT." <199501271202.MAA12524@lust.mrrl.lut.ac.uk> Date: Thu, 26 Jan 1995 21:00:23 +0000 From: Ajit Thyagarajan Message-Id: <9501262100.aa04396@malarky.udel.edu> In message <199501271202.MAA12524@lust.mrrl.lut.ac.uk>you wrote: >Hi, > >I installed ipmulti 3.3 on a SPARC 10 running SunOS 4.1.4 on Jan 3rd, >and have been running with it since then without any problems. This >week I turned the machine into an mrouter, and it still seems to be >behaving itself > >Obviously I would be happier with a kosher ipmulti release for 4.1.4 >-- Ajit/Steve, how about it ? Sure! ipmulti3.4+ should have support for 4.1.4 platforms. Ajit From list-mgr@ISI.EDU Fri Jan 27 16:51:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 07:00:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 06:56:35 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 06:56:33 -0800 Received: from concorde.inria.fr by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 06:56:15 -0800 Received: from electre.inria.fr (electre.inria.fr [128.93.2.11]) by concorde.inria.fr (8.6.9/8.6.9) with SMTP id PAA25002; Fri, 27 Jan 1995 15:51:31 +0100 Received: by electre.inria.fr; Fri, 27 Jan 1995 14:51:30 GMT From: Christian DONOT Message-Id: <199501271451.AA00645@electre.inria.fr> Subject: fmroute1-1 DOWN this weekend To: mbone Date: Fri, 27 Jan 1995 15:51:29 +0100 (MET) Cc: mbone-fr-rest@electre.inria.fr X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 952 At all, For electric intervention, the mrouted fmroute1-1.exp.fr will be down this weekend from friday the 27th at 6:00 PM to monday the 30th 9:00 AM "french hour". Best regards. Christian -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Christian Donot =+=+=+=+=+=+=+= * French Multicast Bone Manager (mbone-fr@inria.fr) To get "mbone-fr" map : ftp anonymous from electre.inria.fr:pub/mbone ftp anonymous from ftp.inria.fr:network/mbone/map * Technical Co-ordinator for the INRIA video-conferencing application "telesia" (telesia-technique@inria.fr). To get "telesia" : ftp anonymous from electre.inria.fr:pub/videoconf/telesia =+=+=+=+=+=+=+= Tel : +33 1 39 63 57 75 | INRIA/ARISTOTE Fax : +33 1 39 63 55 34/53 30 | BP 105 Email : Christian.Donot@inria.fr | 78153 LE CHESNAY CEDEX : chd@inria.fr | FRANCE =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= From list-mgr@ISI.EDU Fri Jan 27 19:36:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 07:38:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 07:36:42 -0800 Received: from cc.lut.fi by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 07:36:40 -0800 Received: (from ruokonen@localhost) by cc.lut.fi (8.6.8/8.6.6/1.17.kim) id RAA01473; Fri, 27 Jan 1995 17:36:27 +0200 From: Vesa Ruokonen Message-Id: <199501271536.RAA01473@cc.lut.fi> Subject: Re: sd for linux To: Juha.Heinanen@lohi.dat.tele.fi (Juha Heinanen) Date: Fri, 27 Jan 1995 17:36:26 +0200 (EET) Cc: mbone In-Reply-To: <199501271432.AA19349@venera.isi.edu> from "Juha Heinanen" at Jan 27, 95 04:32:07 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 526 > i tried to find (without luck) sd sources so that i could compile sd for > linux/xfree3.1. does anyone know, if the sources could be obtained from While LBL's backup robots are looking for the sd sources you might like to test the tty version of sd by Tom Pusateri/J.P.Knight ftp.funet.fi:/pub/unix/networking/multicast/sd_listen-1.5.c.gz and for lazy people there's Linux binary ftp.funet.fi:/pub/unix/networking/multicast/LINUX/linux-sd_listen.gz -- Vesa.Ruokonen@lut.fi From list-mgr@ISI.EDU Fri Jan 27 20:22:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 10:28:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 10:23:07 -0800 Received: from mgate.uni-hannover.de by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 27 Jan 1995 10:23:00 -0800 Received: from helios.tnt.uni-hannover.de by mgate.uni-hannover.de with SMTP (PP); Fri, 27 Jan 1995 19:24:39 +0100 Received: from ikarus.tnt.uni-hannover.de by helios.tnt.uni-hannover.de (4.1/SMI-4.1) id AA29248; Fri, 27 Jan 95 19:22:41 +0100 Date: Fri, 27 Jan 95 19:22:41 +0100 From: bloemer@tnt.uni-hannover.de (Arnold Bloemer) Message-Id: <9501271822.AA29248@helios.tnt.uni-hannover.de> To: mbone, rem-conf@es.net Subject: CeBIT'95 Fair MBone Activities Preannouncement of CeBIT'95 Fair MBone Activities ------------------------------------------------- We are planning major MBone activities for CeBIT'95 fair. CeBIT'95 Fair will take place from 8-MAR-1995 until 15-MAR-1995. CeBIT fair is the world-wide largest and leading fair on information technology, telecommunication and networking. This year there will be over 6000 exhibitors from 57 countries and probably over 675,000 visitors. A special attraction will be the 'NEWS NET', which will be the largest network ever shown on a fair, integrating such different technologies as ATM-, FDDI-, Ethernet- and Token Ring on systems from a lot of vendors. On top of NEWS NET we will install an MBone Net which will cover the whole fair ground. This net will be connected to the Internet via a 2 Mbit/s connection to the WIN (German Research Network) which will be provided by the DFN (German Research Association). The connection to the international MBone will be realized via a 512 Kb/s tunnel to RRZN Hannover. The central point of all MBone activities on CeBIT will be the booth of the 'Greater Hannover Association' (Hall 22, Booth B15) and I am responsible for the organisation and coordination. So far the following organisations will participate in the MBone CeBIT Net: - Greater Hannover Association - European Advanced Networking Test Center (EANTC) (TU Berlin) - MICE National Support Center - Germany (RUS Stuttgart) - TNT at the booth of SUN Microsystems - TNT at the booth of University of Hannover If anybody else would like to show MBone technology on CeBIT'95 fair, we invite him to particpate in our net. Please contact me. We plan to setup two channels, one high bandwidth channel for the local CeBIT Net and one low bandwidth channel with world-wide reach. On the international channel we plan the following activities: - Report on Demand This will certainly be our most interesting and innovative MBone service. We will invite all MBone members to express wishes for reports on any CeBIT related topics they are interested in. Our local reporter team will then go out to the booths and do interviews. These interviews will then be send out to the MBone each day at fixed time slots. Language will be English. - MBone CeBIT Forum The MBone CeBIT Forum will take place at fixed times and shall serve as a discussion forum for CeBIT related topics. We will give status reports on what is happening on the fair, answer questions and collect wishes for in depth reports. Language will be English. - Open Forum Unmoderated discussion forum - German TV Programs from CeBIT fair Possibly we will get permissions from german tv stations to rebroadcast their CeBIT reports on MBone. Language will be German. (Anybody out there from CNN or other international tv stations who would like to cooperate with us?) - Videos from different vendors Product demonstrations from different vendors We will setup a WWW Server at the booth of the 'Greater Hannover Association' where we will give detailed information about our activities and will provide fill-out forms for the Report on Demand Service. The WWW server will be announced on the 27'th of February. We would be very happy about any hints, recommendations or comments regarding our MBone CeBIT'95 activities. Please contact me or discuss it on the mbone and rem-conf mailing lists. (I couldn't decide what the most appropriate group for this announcement is because it announces on the one side a major MBone activity and on the other side tries to coordinate MBone activities and tunneling for CeBIT fair. So I send it out to both.) Please tell us also about any other activities which are planned to take place from 8-MAR-1995 until 15-MAR-1995 and how we can coordinate activities. For example: Will there be a broadcast of the shuttle mission which is scheduled in that time range? We hope that the shuttle will take off and that a broadcast will take place which will cover the whole flight. That broadcast would be a major attraction for our visitors on CeBIT fair. But will there be a problem if we send in parallel? Hoping that you will enjoy our CeBIT'95 coverage, Arnold ________________________________________________________________________________ Dipl.-Ing. Arnold Bloemer Universitaet Hannover Institut fuer Theoretische Nachrichtentechnik und Informationsverarbeitung bloemer@tnt.uni-hannover.de Appelstrasse 9A fax: +49 511 762-5333 D-30167 Hannover phone: +49 511 762-5320 Germany ________________________________________________________________________________ From list-mgr@ISI.EDU Sun Jan 29 09:02:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 10:22:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 10:21:44 -0800 Received: from mic.ucla.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 10:21:42 -0800 Received: from caviar.mic.ucla.edu by mic.ucla.edu (4.1/MIC1.01) id AA27258; Sun, 29 Jan 95 17:02:53 PST Received: (from wada@localhost) by caviar.mic.ucla.edu (8.6.9/8.6.9) id RAA05309 for mbone@isi.edu; Sun, 29 Jan 1995 17:02:52 -0800 From: Kent Wada Message-Id: <199501300102.RAA05309@caviar.mic.ucla.edu> Subject: experiences with MBONE and CU-SeeMe To: mbone Date: Sun, 29 Jan 1995 17:02:52 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2862 (I meant to copy the MBONE list when I first sent this out, but forgot to do so. Here it is, in case anyone else is interested. -Kent) From wada Thu Jan 26 15:43:56 1995 Subject: experiences with MBONE and CU-SeeMe To: cu-seeme-l@cornell.edu Date: Thu, 26 Jan 1995 15:43:56 -0800 (PST) Cc: scott@cns.ucla.edu (Scott Burris) After sending various questions to this list in the past, I thought I would return the favor and describe some of our experiences in joining the CUSM and MBONE worlds together. The good news, as many of you are probably already aware, is that it is indeed possible to exchange bidirectional audio and video streams between the two worlds. At our height, we had 2 SPARCstation 20s with Solaris 2.4, nv 3.3beta, vat 3.4 with SunVideo boards/SunCameras and SunMicrophones 1 Centris 650 with System 7.11, 0.80b1 CUSM with integrated CCD camera/microphone 1 PowerBook Duo 230 with System 7.5, 0.80b1 CUSM with builtin microphone 1 PS/Valuepoint DX2/50 with FreeBSD 2.0, nv 3.3beta 1 PS/Valuepoint DX2/50 with Windows 3.1, 0.34b4 CUSM all receiving, and some sending, audio and video through a 3.00b3 reflector running on a SPARCstation IPC (SunOS 4.1.3). Thanks to the recent reflector work which no longer requires us to use a vat mixer! We have also done a very preliminary "telecommuting" test whereby a CUSM client running on a Quadra 900 with a microphone was connected to the same reflector above via a 28.8 modem over a fractional T1 to the Internet. A low-rate video stream generated on a Sun came across quite nicely on the Quadra, but audio in both directions was quite horrendous. We ended up talking on the telephone simultaneously to gauge the effects, and found, without much surprise, that the apparent degredation probably involved dropped packets as well as an "elongation" effect. The caveats: 1) For bidirectional video, you must tell nv to send a CUSM-encoded video stream rather than a native nv-encoded stream. In particular, this means that CUSM clients wouldn't be able to interpret most video being broadcast over the MBONE. 2) It took us a while to figure out that the PC CUSM client will not accept a "high resolution" image. When we sent a smaller image video, things worked fine. 3) We have successfully run a reflector off of SunOS 4.1.3 and AIX 3.2.5 systems. A reflector running under Solaris 2.3 or 2.4 dies shortly after an nv video source becomes active, although it seems to work fine with CUSM clients only. 4) The system running the reflector is unable to see CUSM streams in nv itself, presumably because it is not looking at the multicast packets it is putting out. -Kent -- Kent Wada Coordinator, Advanced Workstation Program UCLA/OAC Microcomputer Support Office Tel: +1 310 206 3874 / FAX: +1 310 206 1700 WWW: http://caviar.mic.ucla.edu/ From list-mgr@ISI.EDU Mon Jan 30 07:18:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 10:43:20 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 10:42:57 -0800 Received: from banner.ecn.purdue.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 10:42:56 -0800 Received: from banner.ecn.purdue.edu (salama@localhost) by banner.ecn.purdue.edu (8.6.9/3.5davy) id MAA18628; Mon, 30 Jan 1995 12:18:18 -0500 Message-Id: <199501301718.MAA18628@banner.ecn.purdue.edu> Date: Mon, 30 Jan 1995 12:18:18 -0500 From: Paul Salama To: mbone Subject: Subscription X-Sun-Charset: US-ASCII Please subscribe me Paul Salama (salama@ecn.purdue.edu) From list-mgr@ISI.EDU Mon Jan 30 19:01:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 11:02:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 11:00:45 -0800 Received: from nlm.nih.gov (lhc.nlm.nih.gov) by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 11:00:44 -0800 Received: from billings.csb (billings.nlm.nih.gov) by nlm.nih.gov (4.1/SMI-4.0) id AA29519; Mon, 30 Jan 95 14:00:34 EST Received: by billings.csb (5.0/SMI-SVR4) id AA09353; Mon, 30 Jan 1995 14:01:56 +0500 Date: Mon, 30 Jan 1995 14:01:56 +0500 From: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Message-Id: <9501301901.AA09353@billings.csb> To: mbone, rem-conf@es.net Subject: Proposed multicast from 3rd Int. WWW Conf. in Darmstadt Germany, 10-14 April '95 Content-Length: 1357 Dear MBONE Colleagues, We are currently planning to multicast from the Third International World-Wide Web Conference, to be held in Darmstadt Germany from 10-14 April, 1995. There is a possibility of doing two simultaneous sessions (if it does not conflict with other groups using the MBONE), though we are concentrating on doing one session well rather than two poorly. We gained much experience through multicasting the Second International World-Wide Web Conference from Chicago last October; for a summary report, see: http://www.nlm.nih.gov/reports.dir/multicasting.dir/report.html We have been able to start much earlier this time, and think the results will be much better (we were hamstrung in Chicago by a poor Internet connection which we could not test in advance, and a poor audio setup which was out of our control). Please let us know if these dates pose a problem for anyone; we stand ready to work with any other parties desiring to do multicasts during this period. We also hope to set up "remote conference centers" around the world, where groups of people can gather to participate in the meeting remotely via the MBONE. This will require appropriate projection and audio equipment at the remote site. Anyone interested in setting up such a site can get in touch with me via email (rodgers@nlm.nih.gov). Cheerio, Rick Rodgers From list-mgr@ISI.EDU Mon Jan 30 04:01:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 12:01:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 12:01:07 -0800 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 12:01:06 -0800 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA28637; Mon, 30 Jan 95 12:01:49 PST From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9501302001.AA28637@taurus.cs.nps.navy.mil> Subject: Re: Proposed multicast from 3rd Int. WWW Conf. in Darmstadt Germany, 10-14 April '95 To: rodgers@nlm.nih.gov (R. P. C. Rodgers M.D.) Date: Mon, 30 Jan 1995 12:01:44 -0800 (PST) Cc: mbone, rem-conf@es.net In-Reply-To: <9501301901.AA09353@billings.csb> from "R. P. C. Rodgers, M.D." at Jan 30, 95 02:01:56 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 827 We are also hoping to multicast a single session from the ACM SIGGRAPH 1995 Symposium on Interactive 3D Graphics from Monterey California. Home page is ftp://taurus.cs.nps.navy.mil/pub/SYMPOSIUM_MOSAIC/symposium_mosaic.html We are hoping that the time zone difference will minimize schedule collisions. It might mean that any delayed rebroadcasts from the WWW conference in Germany might be postponed for a week. Currently we are the only event scheduled under April 95 at the MBone Session Agenda page at http://www.cilea.it/MBone/agenda.html Further suggestions are welcome. regards, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3697 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv.html From list-mgr@ISI.EDU Mon Jan 30 10:43:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 12:06:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 12:06:14 -0800 Received: from pimac2.iet.unipi.it by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 12:06:08 -0800 Received: by pimac2.iet.unipi.it (5.57/Ultrix3.0-C) id AA28351; Mon, 30 Jan 95 09:43:08 +0100 Date: Mon, 30 Jan 95 09:43:08 +0100 Message-Id: <9501300843.AA28351@pimac2.iet.unipi.it> X-Sender: stefano@radar.iet.unipi.it Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: giordano@pimac2.iet.unipi.it (Stefano Giordano) Subject: VIDEO CARD for HP 9000/735-125 X-Mailer: Dear friends, I'd like to know if someone had experiences with HP 735-125 workstations over the MBONE. I know that it is possible to use such system for VAT, NV, and probably IVS and other tools. Could someone which is using HP system send me some indications about which video card to use over the MBONE with those programs. Thank you very much in advance Stefano ---------------------------------------------------------------------- X ... X X e-mail giordano@iet.unipi.it (o o) Stefano Giordano X X TEL. +39 50 568539 ... v ... X X FAX +39 50 550560 .. .. University of Pisa X X ..... Department of X X TELECOMMUNICATIONS GROUP **^*^** Information Engineering X X Via Diotisalvi 2 X X 56126 PISA X X ITALY X ---------------------------------------------------------------------- From list-mgr@ISI.EDU Mon Jan 30 13:07:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 15:18:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 15:10:45 -0800 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 30 Jan 1995 15:10:44 -0800 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA05349; Mon, 30 Jan 1995 18:07:11 +0500 Message-Id: <9501302307.AA05349@msf.psi.net.> To: mbone Subject: MAE-bone scheduled outage. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <5347.791507231.1@msf.psi.net> Date: Mon, 30 Jan 1995 18:07:11 -0500 From: "Mark S. Fedor" Content-Length: 264 Tomorrow Evening, January 31 at 11PM Eastern Standard Time US, MAE-BONE.PSI.NET will be off the net for about 15 minutes for scheduled maintenance. Needless to say, all tunnels being served by this machine will be down for that time. Thank you. Mark Fedor PSI From list-mgr@ISI.EDU Tue Jan 31 10:02:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 00:09:54 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 00:02:21 -0800 Received: from pimac2.iet.unipi.it by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 00:02:17 -0800 Received: by pimac2.iet.unipi.it (5.57/Ultrix3.0-C) id AA05283; Tue, 31 Jan 95 09:02:12 +0100 Date: Tue, 31 Jan 95 09:02:12 +0100 Message-Id: <9501310802.AA05283@pimac2.iet.unipi.it> X-Sender: stefano@radar.iet.unipi.it Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: giordano@pimac2.iet.unipi.it (Stefano Giordano) Subject: VIDEO CARD and MBONE for HP X-Mailer: The information I received so far are the following 2 mails: ****************************************************************************** We have some HP workstations that are MBONE enabled. Multicast extensions are available for version 9.03 (and 9.01) of the operating system. You have to contact HP about getting the extensions though - they aren't available from any public ftp site. As for the video board, our workstations don't have one, but I believe the one you want is called 'VideoLive'. I know 'nv' supports this board. Leigh Anne Rettinger ******************************************************************************* Hi, The HP marketed Raster Ops card is supposed to work but will only send 8 frames/sec - The Parallax card should work but I don't know for sure. I would appreciate it if you forwarded what answers you get to me. For info from parallax send mail to: harrigan@parallax.com (John Harrigan) hurf ******************************************************************************* Do you know which is the best video card which support H.261 coding (IVS or VIC)? Do you think it is possible to find a card which could perform the coding in hardware? Thnk you a lot in advance! Stefano ---------------------------------------------------------------------- X ... X X e-mail giordano@iet.unipi.it (o o) Stefano Giordano X X TEL. +39 50 568539 ... v ... X X FAX +39 50 550560 .. .. University of Pisa X X ..... Department of X X TELECOMMUNICATIONS GROUP **^*^** Information Engineering X X Via Diotisalvi 2 X X 56126 PISA X X ITALY X ---------------------------------------------------------------------- From list-mgr@ISI.EDU Tue Jan 31 03:38:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 06:17:17 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 05:38:31 -0800 Received: from zon.cc.ncsu.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 05:38:29 -0800 Received: by zon.cc.ncsu.edu (8.6.9/UC06jan95) id IAA01864; Tue, 31 Jan 1995 08:38:23 -0500 From: "John Bass" Message-Id: <9501310838.ZM1862@unity.ncsu.edu> Date: Tue, 31 Jan 1995 08:38:21 -0500 X-Face: 'j%:+CDhUJN(]H_i,;q^R(MG76>Sqqw4Eo_iCP\6b.|;c-e_ACu^7zRxw[:WC&Qe9 BkKQFq'<@.aUcnmWYMQJ\x:H+;cgY/D\J3FE^ X-Mailer: Z-Mail (3.2.0 06sep94) To: mbone Subject: mrouted 2.2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, I'm running mrouted 2.2 on a Sparc5 and the only way I could begin to receive multicast routing information was to change my ip subnet mask to 255.255.255.192. This netmask creates extra traffic on our network. I really need a mask of 255.255.0.0 or at least 255.255.255.0. Does anyone else have this problem, or have I goofed up my configuration? I've looked for mrouted documentation but couldn't find any. Any help would be appreciated. Thanks, -- John Bass NCSU Computing Center R&D and Communications email: John_Bass@ncsu.edu phone: 919.515.5490 Suffering is inevitable, but misery is only an option. Joy is a choice. From list-mgr@ISI.EDU Tue Jan 31 18:54:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 09:55:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 09:54:40 -0800 Received: from cedre.ft.net by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 09:54:36 -0800 Received: by cedre.ft.net (4.1/SMI-4.1) id AA03463; Tue, 31 Jan 95 18:54:18 GMT Date: Tue, 31 Jan 95 18:54:18 GMT From: chaillot@ft.net (Christophe CHAILLOT) Message-Id: <9501311854.AA03463@cedre.ft.net> To: mbone Please suscribe From list-mgr@ISI.EDU Wed Feb 1 00:01:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 12:03:24 -0800 Received: from rkw-risc.cs.up.ac.za by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 12:03:17 -0800 Received: by rkw-risc.cs.up.ac.za (AIX 3.2/UCB 5.64/4.03) id AA23587; Tue, 31 Jan 1995 22:02:00 +0200 Date: Tue, 31 Jan 1995 22:01:59 +0200 (EET) From: Waldi Leonhardt Subject: unsubscribe To: mbone-na Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dit was lekker, maar dit is nou klaar. From list-mgr@ISI.EDU Tue Jan 31 08:04:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 12:02:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 12:02:23 -0800 Received: from rsip.lsu.edu (sun-ra.rsip.lsu.edu) by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 12:02:21 -0800 Received: from ready.rsip.lsu.edu by rsip.lsu.edu (4.1/SMI-4.1) id AA03004; Tue, 31 Jan 95 14:04:46 CST Date: Tue, 31 Jan 95 14:04:46 CST From: tom@rsip.lsu.edu (Tom Smailus) Message-Id: <9501312004.AA03004@rsip.lsu.edu> To: jbass@unity.ncsu.edu, mbone Subject: Re: mrouted problems In-Reply-To: Mail from '"John Bass" ' dated: Tue, 31 Jan 1995 08:38:21 -0500 => =>Hi, => =>I'm running mrouted 2.2 on a Sparc5 and the only way I could begin to receive =>multicast routing information was to change my ip subnet mask to =>255.255.255.192. This netmask creates extra traffic on our network. I really =>need a mask of 255.255.0.0 or at least 255.255.255.0. Does anyone else have =>this problem, or have I goofed up my configuration? I've looked for mrouted =>documentation but couldn't find any. Any help would be appreciated. => =>Thanks, => =>-- =>John Bass Hm. I wonder if that is the same problem I'm having. I'm running 3.3 on a Sparc2 under 4.1.3_U1 and the software installed and mrouted runs, and messages come out when in diagnostic mode, but no sessions ever appear in sd, no mater how long I wait. Is this the same problem you had (and then changed your netmask) or do I have a different problem? Thanks. Tom ----------------------------------------------------------------------------- Thomas 'The Tom-Meister' Smailus E-mail:tom@ready.rsip.lsu.edu Phone: (504) 388-5248 tom@sun-ra.rsip.lsu.edu ----------------------------------------------------------------------------- READY +TECHNOLOGIES+ Remote Sensing and Robotics Research Hardware & Software Systems Image Processing Lab Laboratory (RLL) Imaging & Systems Consulting 3221 CEBA Building 298 Coates Hall PO Box 17578 Louisiana State University LSU Baton Rouge, LA 70893 Baton Rouge, LA 70803 Baton Rouge, LA ----------------------------------------------------------------------------- From list-mgr@ISI.EDU Tue Jan 31 08:22:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 12:24:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 12:23:44 -0800 Received: from fnal.fnal.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 31 Jan 1995 12:23:43 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HMHZNDW60W004EDF@FNAL.FNAL.GOV>; Tue, 31 Jan 1995 14:23:31 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA25412; Tue, 31 Jan 95 14:22:40 CST Date: Tue, 31 Jan 1995 14:22:39 -0600 From: Matt Crawford Subject: Re: mrouted 2.2 In-Reply-To: Your message of Tue, 31 Jan 95 08:38:21 EST. <9501310838.ZM1862@unity.ncsu.edu> Sender: crawdad@munin.fnal.gov To: John Bass Cc: mbone Message-Id: <9501312022.AA25412@munin.fnal.gov> Content-Transfer-Encoding: 7BIT You do need to keep your netmask set to a long enough value that all your tunnels and multicast interfaces appear to be to/on separate subnets. It seems that the 26 bit mask is the value you need. You can avoid this "extra traffic" on your net by adding unicast routes to point to the other subnets. In the most extreme case, you can pretty nearly restore the previous behavior for unicast traffic by configuring your default route as: route add default (your ip address) 0 The less drastic choice is to do individual subnets: route add net (subnet1-addr) (your ip address) 0 route add net (subnet2-addr) (your ip address) 0 . . . _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From list-mgr@ISI.EDU Wed Feb 1 17:30:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 1 Feb 1995 09:35:50 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 1 Feb 1995 09:31:01 -0800 Received: from lust.mrrl.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 1 Feb 1995 09:30:52 -0800 Received: from localhost (martin@localhost) by lust.mrrl.lut.ac.uk (8.6.9/8.6.9) with SMTP id RAA07738; Wed, 1 Feb 1995 17:30:36 GMT Message-Id: <199502011730.RAA07738@lust.mrrl.lut.ac.uk> X-Mailer: exmh version 1.5.3 12/28/94 To: mbone, rem-conf@es.net X-Uri: Subject: searchable archives Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 Feb 1995 17:30:30 +0000 From: Martin Hamilton Hi, I was just wondering whether there are searchable (e.g. via WAIS) and/or browsable (e.g. via WWW/hypermail) versions of the rem-conf and mbone list archives. I know they're FTPable... Thanks, Martin From list-mgr@ISI.EDU Wed Feb 1 19:07:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 1 Feb 1995 11:10:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 1 Feb 1995 11:09:16 -0800 Received: from v6.ph.gla.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 1 Feb 1995 11:08:43 -0800 Date: Wed, 1 Feb 1995 19:07:56 GMT From: "Alan J. Flavell" To: mbone Cc: FLAVELL@v2.ph.gla.ac.uk Message-Id: <950201190756.23c02cbb@v2.ph.gla.ac.uk> Subject: Starting up Mosaic from sd On 28 Aug, William C. Fenner circulated a neat modification to .sd.tcl that allows sd to start up Mosaic against any URL included in the conference description. Nice idea, and works well, thanks. Unfortunately I just stumbled on a URL that was at the end of a sentence - it ended with .html. because of the full stop (OK, 'period') at the end of the sentence. It didn't work, but when I opened the URL (without the trailing '.') then it worked. Not to get too excited, but I am no TCL expert, is there any chance of handling this (and any other punctuation - I don't suppose a comma or semicolon would help either). regards, and thanks From list-mgr@ISI.EDU Wed Feb 1 10:40:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 1 Feb 1995 12:58:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 1 Feb 1995 12:58:03 -0800 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 1 Feb 1995 12:58:02 -0800 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA11051; Wed, 1 Feb 1995 15:40:52 +0500 Message-Id: <9502012040.AA11051@msf.psi.net.> To: mbone Subject: latest multicast and SunOS 4.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <11049.791671251.1@msf.psi.net> Date: Wed, 01 Feb 1995 15:40:51 -0500 From: "Mark S. Fedor" Content-Length: 0 Is there a version of the lastest multicast stuff (3.3) that runs on SunOS 4.1.2? I only found a version of IP multicast for 4.1.3. Is it finally time for me to be forced into upgrading this lonesome 4.1.2 machine on our LAN? :^) Thanks. Mark From list-mgr@ISI.EDU Wed Feb 1 11:37:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 1 Feb 1995 19:33:56 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 1 Feb 1995 19:33:54 -0800 Received: by rx7.ee.lbl.gov for mbone-na@isi.edu (5.65/1.44r) id AA26256; Wed, 1 Feb 95 19:37:41 -0800 Message-Id: <9502020337.AA26256@rx7.ee.lbl.gov> To: clapp@zero.engr.orst.edu Cc: mbone-na Subject: you are sending video at too high a rate Date: Wed, 01 Feb 95 19:37:39 PST From: Van Jacobson You are sending video at more than 200kb/s to the GraphicsNet'95 mbone session. The total bandwdith available on the mbone is only 500kb/s and you are using almost half of it to send video of a dark, empty room. This is interfering with sessions that many people are trying to watch like the Shuttle launch & the CERN LEP workshop. The mbone is shared by about 10,000 people in 30 countries. The mbone policy is to limit video to at most 128kb/s, less if possible, and to avoid sending pointless video since it's a large load on very limited bandwidth resources. Please shut off your video or reduce the bandwidth. Thanks. - Van Jacobson From list-mgr@ISI.EDU Thu Feb 2 10:19:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 00:20:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 00:19:18 -0800 Received: from nikhefh.nikhef.nl by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 00:19:15 -0800 Received: by nikhefh.nikhef.nl; Thu, 2 Feb 1995 09:19:03 +0100 Message-Id: <9502020819.JA01675@nikhefh.nikhef.nl> Date: Thu, 2 Feb 1995 09:19:03 +0100 From: a61@nikhef.nl (Herman van Dompseler) To: FLAVELL@v2.ph.gla.ac.uk Subject: Re: Starting up Mosaic from sd Cc: mbone In-Reply-To: Your message of "Wed, 1 Feb 1995 19:07:56 GMT" > On 28 Aug, William C. Fenner circulated a neat modification to .sd.tcl > that allows sd to start up Mosaic against any URL included in the > conference description. Nice idea, and works well, thanks. > > Unfortunately I just stumbled on a URL that was at the end of a > sentence - it ended with .html. because of the full stop (OK, 'period') > at the end of the sentence. It didn't work, but when I opened the > URL (without the trailing '.') then it worked. Not to get too excited, > but I am no TCL expert, is there any chance of handling this (and any > other punctuation - I don't suppose a comma or semicolon would help > either). > After the URL is detected I use regsub {\.html[^ ]*} $url .html url to remove everything that comes immediately after ".html". Herman. From list-mgr@ISI.EDU Thu Feb 2 04:29:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 06:30:08 -0800 Received: from burdell.cc.gatech.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 06:30:05 -0800 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id JAA20585; Thu, 2 Feb 1995 09:29:51 -0500 Received: (from kevin@localhost) by flora.cc.gatech.edu (8.6.9/8.6.9) id JAA16242; Thu, 2 Feb 1995 09:29:33 -0500 Date: Thu, 2 Feb 1995 09:29:33 -0500 From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199502021429.JAA16242@flora.cc.gatech.edu> To: van@ee.lbl.gov Subject: Re: you are sending video at too high a rate Cc: mbone-na >>You are sending video at more than 200kb/s to the GraphicsNet'95 >>mbone session. The total bandwdith available on the mbone is >>only 500kb/s and you are using almost half of it to send video >>of a dark, empty room. This is interfering with sessions that >>many people are trying to watch like the Shuttle launch & the >>CERN LEP workshop. The mbone is shared by about 10,000 people >>in 30 countries. The mbone policy is to limit video to at most >>128kb/s, less if possible, and to avoid sending pointless video >>since it's a large load on very limited bandwidth resources. >>Please shut off your video or reduce the bandwidth. Thanks. I am not sending video as is everyone else on the list except maybe one person. Please amend the subject to say WHO is sending at too high a rate. -Kevin Almeroth From list-mgr@ISI.EDU Thu Feb 2 05:16:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 07:18:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 07:17:16 -0800 Received: from PO6.ANDREW.CMU.EDU by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 07:17:14 -0800 Received: (from postman@localhost) by po6.andrew.cmu.edu (8.6.9/8.6.9) id KAA06168 for mbone@isi.edu; Thu, 2 Feb 1995 10:17:06 -0500 Received: via switchmail; Thu, 2 Feb 1995 10:17:05 -0500 (EST) Received: from island.weh.andrew.cmu.edu via qmail ID ; Thu, 2 Feb 1995 10:16:49 -0500 (EST) Received: from island.weh.andrew.cmu.edu via qmail ID ; Thu, 2 Feb 1995 10:16:47 -0500 (EST) Received: from mms.4.60.Nov..4.1993.10.47.44.sun4c.411.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.island.weh.andrew.cmu.edu.sun4c.411 via MS.5.6.island.weh.andrew.cmu.edu.sun4c_411; Thu, 2 Feb 1995 10:16:47 -0500 (EST) Message-Id: Date: Thu, 2 Feb 1995 10:16:47 -0500 (EST) From: Matthew G Newcomb To: mbone Subject: CuSeeMe Reflector Cc: G'day, I would like to setup video conferencing between a group of machines at two different points. The machines include pc's, macs, and workstations. The pc's would be running CuSeeme, the workstations nv, vat, etc. I was thinking of setting up a CuSeeMe Reflector at both ends of the link and starting a unicast feed between the two reflectors. Each reflector would then broadcast via multicast at a low ttl to allow the unix machines to pick it up. The only problem I have is the link is not always there. It is a satellite link, and goes up and down on a regular schedule. Will the reflector complain about this? Is there a better way to do this? Suggestions would be great! Thanks alot.. Matthew Newcomb From list-mgr@ISI.EDU Thu Feb 2 04:57:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 09:00:16 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 08:58:32 -0800 Received: from fnal.fnal.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 08:58:32 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HMKL2H8ABK004FAA@FNAL.FNAL.GOV>; Thu, 02 Feb 1995 10:58:11 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA10463; Thu, 2 Feb 95 10:57:22 CST Date: Thu, 02 Feb 1995 10:57:22 -0600 From: Matt Crawford Subject: IGMP membership reports with high TTL Sender: crawdad@munin.fnal.gov To: meessen@marina.in2p3.fr Cc: mbone Message-Id: <9502021657.AA10463@munin.fnal.gov> Content-Transfer-Encoding: 7BIT marina.in2p3.fr [134.158.16.67] is sending IGMP membership reports with TTL > 1. This is usually a symptom of an unclean build of the multicast kernel. "make clean; make" might fix it. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From list-mgr@ISI.EDU Thu Feb 2 01:20:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 09:23:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 09:20:44 -0800 Received: from osi-east.es.net by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 09:20:43 -0800 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <17718-0@osi-east.es.net>; Thu, 2 Feb 1995 09:20:37 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA28053; Thu, 2 Feb 95 09:20:34 PST Date: Thu, 2 Feb 95 09:20:34 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9502021720.AA28053@viipuri.nersc.gov> To: mbone Subject: send help Reply-To: rons@mill2.millcomm.com ----- Begin Included Message ----- From rons@millcomm.com Wed Feb 1 00:10:10 1995 Date: Wed, 1 Feb 1995 02:09:47 -0600 (CST) From: Ron Stoberg Subject: send help To: rem-conf-request@es.net Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 62 please send information on participating in mbone thanks ron ----- End Included Message ----- From list-mgr@ISI.EDU Thu Feb 2 01:26:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 09:29:32 -0800 Received: from ENGR.ORST.EDU by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 09:29:23 -0800 Received: from zero (zero-atm.ENGR.ORST.EDU) by ENGR.ORST.EDU (4.1/1.30) id AA06265; Thu, 2 Feb 95 09:29:19 PST Received: by zero (5.0/ENGR-Client) id AA04036; Thu, 2 Feb 1995 09:26:42 +0800 Message-Id: <9502021726.AA04036@zero> To: Van Jacobson Cc: clapp@ENGR.ORST.EDU, mbone-na Subject: Re: you are sending video at too high a rate From: Andrew S. Clapp Date: Thu, 02 Feb 1995 09:26:41 -0800 Sender: clapp@ENGR.ORST.EDU Content-Length: 1131 > You are sending video at more than 200kb/s to the GraphicsNet'95 > mbone session. The total bandwdith available on the mbone is > only 500kb/s and you are using almost half of it to send video > of a dark, empty room. This is interfering with sessions that > many people are trying to watch like the Shuttle launch & the > CERN LEP workshop. The mbone is shared by about 10,000 people > in 30 countries. The mbone policy is to limit video to at most > 128kb/s, less if possible, and to avoid sending pointless video > since it's a large load on very limited bandwidth resources. > Please shut off your video or reduce the bandwidth. Thanks. > > - Van Jacobson I apologize for my error. I was unaware of what I was doing and have since been informed of how to correctly use this tool. -ASC Andrew S. Clapp : _&,_ _______ ^ ^ /\ /\ /\ ______\ The biwild romantic frobuals! @/7-\@ v v \/ \/ \/ \/ / Network for Education and Research in Oregon Computer Science Outreach Services From list-mgr@ISI.EDU Thu Feb 2 12:12:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 14:38:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 14:34:31 -0800 Received: from Princeton.EDU by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 14:34:30 -0800 Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.115/princeton) id AA25389; Thu, 2 Feb 95 17:12:17 -0500 Received: from deepthought.Princeton.EDU by ponyexpress.princeton.edu (8.6.9/1.7/newPE) id RAA07089; Thu, 2 Feb 1995 17:12:15 -0500 Received: by deepthought.Princeton.EDU (4.1/Phoenix_Cluster_Client) id AA11150; Thu, 2 Feb 95 17:12:13 EST Message-Id: <9502022212.AA11150@deepthought.Princeton.EDU> X-Mailer: exmh version 1.5.3 12/28/94 To: mbone Cc: tengi@Princeton.EDU Subject: Q: Local-only IP multicast addresses X-Face: Bf#x_s+*GOjDqAJ)5qI'fpm&Y2OF`RgiD2w\&Qr7ly@(yzUB)zSw#@Bj)A"3sIEwTwdBY&} #v`i+!@m"7yGc;*@Gqk_LZW4l;q8jsoEKRHL'eC|($Jc wWNl X-Uri: http://www.Princeton.EDU/~tengi/ Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 Feb 1995 17:12:12 EST From: "Christopher J. Tengi" I would like to make use of a number of multicast addresses on campus for segregating SGI Object Brokers that share subnets but not organizations (along the lines of AppleTalk zones). I looked in RFC1700 (Assigned Numbers) but saw no block of addresses that were reserved for local use. Are there any conventions in this area? Should I just pick 225.something and hope nothing gets assigned there? Is this even a valid place to be asking questions like this? Thanks, /Chris From list-mgr@ISI.EDU Thu Feb 2 10:41:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 19:05:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 18:41:54 -0800 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 18:41:52 -0800 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA00110 (5.65c/IDA-1.4.4nsd for ); Thu, 2 Feb 1995 18:41:50 -0800 Received: by jaspar.NSD.3Com.COM id AA27170 (5.65c/IDA-1.4.4-910730 for mbone@isi.edu); Thu, 2 Feb 1995 18:41:48 -0800 Date: Thu, 2 Feb 1995 18:41:48 -0800 From: "Cyndi M. Jung" Message-Id: <199502030241.AA27170@jaspar.NSD.3Com.COM> To: mbone Subject: starting mrouted I've just put a Sparc up with a rebuilt multicast kernel and have run into a small snag. I want this machine to be the only multicast receiver with just the tunnel for now, but the mrouted won't start if it doesn't have another interface - just as it says in the faq. Is there any way around this? I don't want to enable multicast back onto the same interface that the tunnel is coming through, and I don't have another ethernet card for the Sparc right now. Is there anything I can do to get this running before I get the second ethernet interface? Cyndi Jung 3Com Corporation From list-mgr@ISI.EDU Sat Feb 4 00:08:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 19:19:46 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 19:04:14 -0800 Received: from christ.acu.EDU.AU by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 19:02:35 -0800 Received: from [192.148.227.72] (P_Mul_LC.mercy.acu.EDU.AU) by christ.acu.edu.au with SMTP id AA17223 (5.65c/IDA-1.3.5/LTU-1.0 for mbone@ISI.EDU); Fri, 3 Feb 1995 14:04:02 -0400 Message-Id: <199502031804.AA17223@christ.acu.edu.au> X-Sender: mul400@christ.acu.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Feb 1995 14:08:42 +1000 To: mbone From: chaillot@ft.net (Christophe CHAILLOT) (by way of P.Mulready@mercy.acu.edu.au (Pam Mulready)) Please suscribe From list-mgr@ISI.EDU Thu Feb 2 13:43:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 21:39:19 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Feb 1995 21:39:17 -0800 Received: by rx7.ee.lbl.gov for mbone-na@isi.edu (5.65/1.44r) id AA27731; Thu, 2 Feb 95 21:43:07 -0800 Message-Id: <9502030543.AA27731@rx7.ee.lbl.gov> To: mbone-na Subject: multicast routing loop at seattleu.edu Date: Thu, 02 Feb 95 21:43:07 PST From: Van Jacobson There seems to be a multicast routing loop for packets originating at seattleu.edu (192.333.32 & 199.237.224 - see below). Their entry mrouter (192.222.32.190, spiff.seattleu.edu) seems to be running a version of mrouted that doesn't respond to mrinfo so it's hard to check out the internal topology. - Van 20:55:49.655 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 119, id 65121) 20:55:49.660 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 117, id 65121) 20:55:49.673 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 115, id 65121) 20:55:49.674 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 113, id 65121) 20:55:49.677 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 111, id 65121) 20:55:49.683 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 109, id 65121) 20:55:49.700 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 107, id 65121) 20:55:49.703 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 105, id 65121) 20:55:49.712 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 103, id 65121) 20:55:49.714 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 101, id 65121) 20:55:49.722 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 99, id 65121) 20:55:49.723 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 97, id 65121) 20:55:49.726 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 95, id 65121) 20:55:49.732 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 93, id 65121) 20:55:49.747 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 91, id 65121) 20:55:49.749 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 89, id 65121) 20:55:49.752 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 87, id 65121) 20:55:49.754 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 85, id 65121) 20:55:49.757 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 83, id 65121) 20:55:49.761 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 81, id 65121) 20:55:49.770 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 79, id 65121) 20:55:49.775 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 77, id 65121) 20:55:49.783 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 75, id 65121) 20:55:49.785 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 73, id 65121) 20:55:49.789 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 71, id 65121) 20:55:49.796 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 69, id 65121) 20:55:49.802 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 67, id 65121) 20:55:49.805 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 65, id 65121) 20:55:49.807 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 63, id 65121) 20:55:49.818 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 61, id 65121) 20:55:59.746 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 119, id 65407) 20:55:59.752 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 117, id 65407) 20:55:59.757 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 115, id 65407) 20:55:59.764 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 113, id 65407) 20:55:59.772 199.237.224.14 > 224.2.172.156.54041: udp 80 (ttl 111, id 65407) From list-mgr@ISI.EDU Thu Feb 2 22:25:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 00:29:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 00:25:43 -0800 Received: from alterdial.UU.NET by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 00:25:40 -0800 Received: from [198.4.181.158] by alterdial.UU.NET with SMTP id QQyblp06439; Fri, 3 Feb 1995 03:25:34 -0500 X-Sender: mail00821@alterdial.uu.net (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Feb 1995 03:25:07 -0500 To: mbone From: adamgood@voices.com (Adam Goodman) Subject: PIM and interoperability with MOSPF/DVMRP Hello all, I was wondering if someone could please point me towards some information on PIM. Cisco has very little about it on their Web site, and I can't find any anywhere else. I am specifically interested in its interoperability with other routers (mrouted/DVMRP/MOSPF). I am setting up a T-1 connection for the primary purpose of receiving an MBONE feed, and I am not sure what the best equipment to buy is. Is a SPARC configured to run mrouted the best way to go? Or is a Proteon supporting MOSPF? Or is Cisco's PIM going to supercede these? I assume that if I use a SPARC running mrouted, I still have to buy a separate router to route IP, or an SBus card for the SPARC to handle this. This would seem more expensive. . . Or am I completely off base and ignorant? If that is the case then I apologize profusely. Hey, I've never done this before. Any help is greatly appreciated. TIA, Adam Adam M. Goodman Mulsanne Communications 19 W. 44th St. Ste. 1217 New York, NY 10036 ph# (212) 221-7065 fx# (212) 221-1413 From list-mgr@ISI.EDU Fri Feb 3 12:22:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 02:25:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 02:23:51 -0800 Received: from mailgzrz.TU-Berlin.DE by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 02:23:09 -0800 Received: from tubkom.prz.tu-berlin.de by mailgzrz.TU-Berlin.DE with SMTP (PP); Fri, 3 Feb 1995 11:22:12 +0100 Received: from bluemoon.prz.tu-berlin.de (bluemoon.prz.tu-berlin.de [130.149.62.17]) by tubkom.prz.tu-berlin.de (8.6.9/8.6.9) with SMTP id LAA29721; Fri, 3 Feb 1995 11:22:06 +0100 Message-Id: <199502031022.LAA29721@tubkom.prz.tu-berlin.de> Received: by bluemoon.prz.tu-berlin.de (1.37.109.4/15.6) id AA28384; Fri, 3 Feb 95 11:22:05 +0100 From: wolf@prz.tu-berlin.de Subject: Re: PIM and interoperability with MOSPF/DVMRP To: adamgood@voices.com (Adam Goodman) Date: Fri, 3 Feb 1995 11:22:05 +0100 (MEZ) Cc: mbone In-Reply-To: from "Adam Goodman" at Feb 3, 95 03:25:07 am Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1782 Hi, I'm sorry I cannot help you because I'm not familiar with Cisco's PIM either. But we have a similar problem (concerning the use of PIM or DVMRP). So if you receive any useful responses could you please forward them to me? Thank you in advance, Thomas Adam Goodman wrote: > > Hello all, > > I was wondering if someone could please point me towards some information > on PIM. Cisco has very little about it on their Web site, and I can't find > any anywhere else. > > I am specifically interested in its interoperability with other routers > (mrouted/DVMRP/MOSPF). > > I am setting up a T-1 connection for the primary purpose of receiving an > MBONE feed, and I am not sure what the best equipment to buy is. Is a > SPARC configured to run mrouted the best way to go? Or is a Proteon > supporting MOSPF? Or is Cisco's PIM going to supercede these? I assume > that if I use a SPARC running mrouted, I still have to buy a separate > router to route IP, or an SBus card for the SPARC to handle this. This > would seem more expensive. . . > > Or am I completely off base and ignorant? If that is the case then I > apologize profusely. Hey, I've never done this before. > > Any help is greatly appreciated. > > TIA, > > Adam > > Adam M. Goodman > Mulsanne Communications > 19 W. 44th St. Ste. 1217 > New York, NY 10036 > ph# (212) 221-7065 > fx# (212) 221-1413 > > -- Thomas Wolfram Germany: 0 30 31421171 PRZ TU Berlin abroad: +49 30 31421171 EANTC WWW: http://www.prz.tu-berlin.de:/~wolf _____________________________________________________________________________ _____S__I__C____T__R__A__N__S__I__T____G__L__O__R__I__A____M__U__N__D__I_____ From list-mgr@ISI.EDU Sat Feb 4 47:46:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 05:54:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 05:50:49 -0800 Received: from phibes.dartmouth.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 05:50:45 -0800 Received: from phibes.dartmouth.edu (localhost [127.0.0.1]) by phibes.dartmouth.edu (8.6.9/8.6.6) with ESMTP id IAA13136 for ; Fri, 3 Feb 1995 08:50:43 -0500 Message-Id: <199502031350.IAA13136@phibes.dartmouth.edu> To: mbone Subject: NASA broadcast? Date: Fri, 03 Feb 1995 08:50:43 +22306256 From: Pat Wilson I'm getting virtually nothing on the NASA Shuttle audio channel today, and am unable to get vic to run to see the video. Is anyone (a) getting consistent audio from NASA or (b) getting "shmget: Invalid argument" from vic (SPARCclassic, SunOS 4.1.3_U1 - I'm running the binary provided, since I don't grok C++)? Is there any hope of getting the shuttle video back on nv? Thanks. Pat Wilson paw@northstar.dartmouth.edu From list-mgr@ISI.EDU Fri Feb 3 05:54:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 07:55:47 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 07:54:29 -0800 Received: from intrepid.ecn.purdue.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 07:54:27 -0800 Received: from localhost (davy@localhost [127.0.0.1]) by intrepid.ecn.purdue.edu (8.6.9/3.5davy) with ESMTP id KAA25475; Fri, 3 Feb 1995 10:54:26 -0500 Message-Id: <199502031554.KAA25475@intrepid.ecn.purdue.edu> To: mbone Subject: Anybody know what these are? Date: Fri, 03 Feb 1995 10:54:19 EST From: "David A. Curry" Hi, I'm working on an ethernet monitoring program that classifies traffic by protocol. I've encountered some multicast packets to addresses that I cannot find listed in the IANA's list of official addresses on isi.edu. Does anyone know what these are being used for? 228.1.25.70 (traffic is coming from magritte.cc.gatech.edu, among others) 224.8.8.8 (traffic is coming from stargate.acs.ohio-state.edu) 224.3.25.66 (traffic is coming from some unregistered address in trw.com domain; 192.4.4.35) Any clues folks could provide would be appreciated. Thanks, Dave Curry Purdue University From list-mgr@ISI.EDU Fri Feb 3 01:15:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 09:24:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 09:15:46 -0800 Received: from fram.apl.washington.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 09:15:43 -0800 Received: from localhost by fram.apl.washington.edu (8.6.4/UW-NDC Revision: 2.21 ) id JAA09368; Fri, 3 Feb 1995 09:15:53 -0800 From: "axel schweiger" Message-Id: <9502030915.ZM9366@fram.apl.washington.edu> Date: Fri, 3 Feb 1995 09:15:53 -0800 X-Mailer: Z-Mail (3.2.0 06sep94) To: mbone Subject: Please unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Please unsubscribe me from the list. I tried the request alias twice before. Axel From list-mgr@ISI.EDU Fri Feb 3 07:36:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 09:41:29 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 09:39:20 -0800 Received: from burdell.cc.gatech.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 09:39:16 -0800 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id MAA22141; Fri, 3 Feb 1995 12:38:52 -0500 Received: (from kevin@localhost) by flora.cc.gatech.edu (8.6.9/8.6.9) id MAA20026; Fri, 3 Feb 1995 12:36:57 -0500 Date: Fri, 3 Feb 1995 12:36:57 -0500 From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199502031736.MAA20026@flora.cc.gatech.edu> To: davy@ecn.purdue.edu, mbone Subject: Re: Anybody know what these are? >>I'm working on an ethernet monitoring program that classifies traffic >>by protocol. I've encountered some multicast packets to addresses >>that I cannot find listed in the IANA's list of official addresses on >>isi.edu. >> >>Does anyone know what these are being used for? >> >> 228.1.25.70 (traffic is coming from magritte.cc.gatech.edu, among >> others) >> >> 224.8.8.8 (traffic is coming from stargate.acs.ohio-state.edu) >> >> 224.3.25.66 (traffic is coming from some unregistered address in >> trw.com domain; 192.4.4.35) >> >>Any clues folks could provide would be appreciated. Someone on the ethernet must be listening to a vat session. In this case you will be receiving packets from all other people who are also connected to that session. This information is used by vat to list the people participating in the conference. Kevin Almeroth (kevin@cc.gatech.edu) Networking and Telecommunications Research Group College of Computing, Georgia Institute of Technology http://www.cc.gatech.edu/computing/Telecomm/people/Phd/kevin/kevin.html From list-mgr@ISI.EDU Fri Feb 3 02:45:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 10:46:46 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 10:45:16 -0800 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 10:45:14 -0800 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA17135 (5.65c/IDA-1.4.4nsd for ); Fri, 3 Feb 1995 10:45:13 -0800 Received: by jaspar.NSD.3Com.COM id AA28860 (5.65c/IDA-1.4.4-910730 for mbone@isi.edu); Fri, 3 Feb 1995 10:45:11 -0800 Date: Fri, 3 Feb 1995 10:45:11 -0800 From: "Cyndi M. Jung" Message-Id: <199502031845.AA28860@jaspar.NSD.3Com.COM> To: mbone Subject: starting mrouted - thanks Several people have responded to me, and have been quite helpful. I've been reasured that no unwanted traffic will be sent out the single physical interface if I enable it for mrouted's use - only if there are apps on that segment (or presumably another multicast router) will any multicast traffic be sent there. This is really good news, as the interface in question is my firewall, and I didn't want to add unnecessarily to it's current load. Thanks to you all, Cyndi > > > I've just put a Sparc up with a rebuilt multicast kernel > and have run into a small snag. I want this machine to > be the only multicast receiver with just the tunnel for > now, but the mrouted won't start if it doesn't have another > interface - just as it says in the faq. Is there any way > around this? I don't want to enable multicast back onto > the same interface that the tunnel is coming through, and > I don't have another ethernet card for the Sparc right now. > Is there anything I can do to get this running before I > get the second ethernet interface? > > Cyndi Jung > 3Com Corporation From list-mgr@ISI.EDU Fri Feb 3 18:54:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 10:56:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 10:55:03 -0800 Received: from v6.ph.gla.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 10:54:56 -0800 Date: Fri, 3 Feb 1995 18:54:21 GMT From: "Alan J. Flavell" To: mbone Cc: FLAVELL@v2.ph.gla.ac.uk Message-Id: <950203185421.23c02fb9@v2.ph.gla.ac.uk> Subject: Starting Mosaic from sd So many different people have emailed me in response to my recent reference to this topic, asking me for a copy of the code, that I am taking the liberty of distributing it here. Unfortunately I do not have William C. Fenner's original mail in electronic form (I lost that, and only have it on paper), so I cannot include it verbatim, but I stress that this work is his and NOT mine, I take no credit for it and am only repeating it at others' request. As was mentioned also, it needs a tad of extra code to deal with the situation of a URL followed immediately by punctuation. That being said, I enclose the relevant part of a diff -c3 of the original sd 1.4 sd_start.tcl and the ~/.sd.tcl that I am using. *** ipmulti/sd_start.tcl Thu Mar 17 18:06:25 1994 --- ./.sd.tcl Tue Jan 31 20:37:42 1995 *************** *** 41,49 **** # sd_priv(video) (= 0 if video disabled with -v) # sd_priv(whiteboard) (= 0 if wb disabled with -w) proc start_session {} { ! global sd_sess sd_priv # invoke the appropriate start proc for each of the media # if such a proc exists and that media is enabled. foreach m $sd_sess(media) { --- 41,56 ---- # sd_priv(video) (= 0 if video disabled with -v) # sd_priv(whiteboard) (= 0 if wb disabled with -w) + set mosaic Mosaic + proc start_session {} { ! global sd_sess sd_priv mosaic + # start up Mosaic if there is a URL in the description + if {[regexp {[a-zA-Z]+://[^ ]+} $sd_sess(description) url]} { + exec $mosaic $url & + } + # invoke the appropriate start proc for each of the media # if such a proc exists and that media is enabled. foreach m $sd_sess(media) { From list-mgr@ISI.EDU Fri Feb 3 09:39:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 11:41:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 11:40:04 -0800 Received: from intrepid.ecn.purdue.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 11:40:02 -0800 Received: from localhost (davy@localhost [127.0.0.1]) by intrepid.ecn.purdue.edu (8.6.9/3.5davy) with ESMTP id OAA25976; Fri, 3 Feb 1995 14:39:59 -0500 Message-Id: <199502031939.OAA25976@intrepid.ecn.purdue.edu> To: mbone Subject: Re: Anybody know what these are? In-Reply-To: Message from Thomas Pusateri of "Fri, 03 Feb 1995 13:24:47 -0500" Date: Fri, 03 Feb 1995 14:39:55 EST From: "David A. Curry" Earlier today, I asked what these were: > 228.1.25.70 (traffic is coming from magritte.cc.gatech.edu, among > others) > > 224.8.8.8 (traffic is coming from stargate.acs.ohio-state.edu) > > 224.3.25.66 (traffic is coming from some unregistered address in > trw.com domain; 192.4.4.35) The consensus appears to be that they're nothing in particular. Tom Pusateri summarized it best: Multicast addresses are assigned dynamically by the Session Directory tool, sd. Different types of traffic will be on these addresses at different times. Your only clue would be to look further into the packet. Most likely it will be UDP traffic and the port numbers are also assigned dynamically so you would have to look into the stream to see if it is vic video, nv video, vat audio, ivs audio, etc. Thanks to all who responded. Dave Curry Purdue University From list-mgr@ISI.EDU Fri Feb 3 09:37:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 11:40:15 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 11:38:49 -0800 Received: from PO3.ANDREW.CMU.EDU by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 11:38:46 -0800 Received: (from postman@localhost) by po3.andrew.cmu.edu (8.6.9/8.6.9) id OAA03378 for mbone@isi.edu; Fri, 3 Feb 1995 14:38:38 -0500 Received: via switchmail; Fri, 3 Feb 1995 14:38:37 -0500 (EST) Received: from pcs17.andrew.cmu.edu via qmail ID ; Fri, 3 Feb 1995 14:37:22 -0500 (EST) Received: from pcs17.andrew.cmu.edu via qmail ID ; Fri, 3 Feb 1995 14:37:21 -0500 (EST) Received: from mms.4.60.Nov..4.1993.10.47.44.sun4c.411.EzMail.Client.2.0.CUILIB.3.45.SNAP.NOT.LINKED.pcs17.andrew.cmu.edu.sun4c.411 via MS.5.6.pcs17.andrew.cmu.edu.sun4c_411; Fri, 3 Feb 1995 14:37:20 -0500 (EST) Message-Id: Date: Fri, 3 Feb 1995 14:37:20 -0500 (EST) From: Matthew G Newcomb To: mbone Subject: CuSeeMe Reflectors with a Unicast Link Cc: G'day, I apologize if this is the wrong place. I am trying to get the CuSeeMe reflector 3.0b3 to run on a dec alpha. I got the reflector to compile, and its seems to run okay by itself. I have the same version of reflector compiled on a sun 3/60. The configuration files look like this: ;sun 3/60 DEBUG UNICAST-REF 128.2.24.63 LOG /usr/custom2/reflector.log LOG-LIMIT 10000 MOTD Welcome to a test cuseeme reflector running from Donner // and it prints this out on console: sending unicast server keep alive sending to 128.2.24.63 ;dec alpha DEBUG LOG /usr/users/mn2g/reflector.log LOG-LIMIT 10000 MOTD Welcome to a test cuseeme reflector running from Weh Hall // REFMON 128.2.93.131 and it prints this out on console: client not found client not found and initial message is not Open video packet len 26 network src 128.2.93.131 content src 0.26.0.0 family 2 seq 0 msg 0 dtype 0 The log file on the sun 3/60 look are just empty except for the startup/shutdown messages. The alpha has this in its log: open_log file: /usr/users/mn2g/reflector.log client not found and initial message is not Open ..... (etc etc etc) Kill Signal received : Interrupted system call: FATAL ERROR: EXITING If anyone can give me some suggestions I would appreciate it! thanks alot, Matthew Newcomb From list-mgr@ISI.EDU Fri Feb 3 09:42:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 11:44:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 11:43:04 -0800 Received: from PO5.ANDREW.CMU.EDU by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 11:43:03 -0800 Received: (from postman@localhost) by po5.andrew.cmu.edu (8.6.9/8.6.9) id OAA22682 for mbone@isi.edu; Fri, 3 Feb 1995 14:42:52 -0500 Received: via switchmail; Fri, 3 Feb 1995 14:42:50 -0500 (EST) Received: from pcs25.andrew.cmu.edu via qmail ID ; Fri, 3 Feb 1995 14:42:39 -0500 (EST) Received: from pcs25.andrew.cmu.edu via qmail ID ; Fri, 3 Feb 1995 14:42:35 -0500 (EST) Received: from mms.4.60.Nov..4.1993.10.47.44.sun4c.411.EzMail.Client.2.0.CUILIB.3.45.SNAP.NOT.LINKED.pcs25.andrew.cmu.edu.sun4c.411 via MS.5.6.pcs25.andrew.cmu.edu.sun4c_411; Fri, 3 Feb 1995 14:42:34 -0500 (EST) Message-Id: Date: Fri, 3 Feb 1995 14:42:34 -0500 (EST) From: Matthew G Newcomb To: mbone Subject: CuSeeMe Reflector #2 Cc: G'day, Sorry. I gave you the wrong configuration file for the alpha: DEBUG LOG /usr/users/mn2g/reflector.log LOG-LIMIT 10000 MOTD Welcome to a test cuseeme reflector running from Weh Hall // REFMON 128.2.93.131 UNICAST-REF 128.2.93.131 Then it prints this error on console: REF unicast group server at 128.2.93.131 is opening a connection sendto error 49 client Group Uni REF Matthew Newcomb From list-mgr@ISI.EDU Fri Feb 3 05:15:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 13:19:32 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 13:16:06 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 13:16:03 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14537(3)>; Fri, 3 Feb 1995 13:15:44 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Fri, 3 Feb 1995 13:15:34 -0800 X-Mailer: exmh version 1.5.3 12/28/94 To: "Alan J. Flavell" Cc: mbone, fenner@parc.xerox.com Subject: Re: Starting Mosaic from sd In-Reply-To: Your message of "Fri, 03 Feb 95 10:54:21 PST." <950203185421.23c02fb9@v2.ph.gla.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Feb 1995 13:15:25 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <95Feb3.131534pst.49859@crevenia.parc.xerox.com> Actually, Alan, you had an earlier version; I posted a second one that checks for an already-running Mosaic and tells it to go to the URL. Here is the beginning of my current start_session() (My .sd.tcl is sufficiently modified that diff's would be more trouble than it's worth), modified to remove dots from the end of URL's. set mosaic Mosaic proc start_session {} { global sd_sess sd_priv mosaic # start up Mosaic if there is a URL in the description. if {[regexp {[a-zA-Z]+://[^ ]+} $sd_sess(description) url]} { set url [string trimright $url .] foreach process [split [exec ps -g] "\n" ] { if {[regexp "(\[0-9]+).*$mosaic" $process junk pid]} { break } } if {[info exists pid]} { set mctrl [open "/tmp/Mosaic.$pid" w] puts $mctrl goto puts $mctrl $url close $mctrl exec kill -30 $pid sleep 1 exec rm /tmp/Mosaic.$pid } else { exec $mosaic $url & } } # invoke the appropriate start proc for each of the media # if such a proc exists and that media is enabled. foreach m $sd_sess(media) { if { [llength [info proc start_$m]] && $sd_priv($m) } { start_$m } } } From list-mgr@ISI.EDU Sat Feb 4 18:28:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 18:38:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 18:35:56 -0800 Received: from csp.ee.ntu.edu.tw by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 18:34:59 -0800 Received: by csp.ee.ntu.edu.tw (4.1/SMI-4.1) id AA01422; Sat, 4 Feb 95 10:28:41 CST From: yrchen@csp.ee.ntu.edu.tw (Ying-Ruey Chen (\3\/\?o\:\M)) Message-Id: <9502040228.AA01422@csp.ee.ntu.edu.tw> Subject: Please unsubscribe To: mbone Date: Sat, 4 Feb 1995 10:28:40 +0800 (CST) Return-Receipt-To: yrchen@csp.ee.ntu.edu.tw X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 430 > Please unsubscribe me from the list. > I tried the request alias twice before. > > Axel > Me too! Please unsubscribe me from the list! Thanks! -- -= Regards =- Ying-Ruey Chen ( 3/ ?o :M ) Tel: (02) 363-5251 ext 530 E-Mail : yrchen@csp.ee.ntu.edu.tw // b9503094@cc.ntu.edu.tw Home Dept. of Electrical Engineering, National Taiwan Univ. ### You always know how to find me on the Internet! ### From list-mgr@ISI.EDU Fri Feb 3 17:38:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 19:41:29 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 19:38:54 -0800 Received: from media.mit.edu (media-lab.media.mit.edu) by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 19:38:52 -0800 Received: by media.mit.edu (5.57/DA1.0.4.amt) id AA10838; Fri, 3 Feb 95 22:38:46 -0500 Date: Fri, 3 Feb 95 22:38:46 -0500 From: Harvie H. Branscomb Message-Id: <9502040338.AA10838@media.mit.edu> To: mbone, mbone@netcom.com Subject: mbone configuration help needed... I have configured ipmulti3.3 provisions at Sun Micro Aspen Smallworks on a SS10 with SunOS4.1.3. I am having problems with missing packets resulting in the usual breakup of audio and video. The failure seems likely due to bottlenecks upstream of my router, but netstat -Ms reports some very embarassing comments about my configuration. Is there an obvious problem here? Do I need a static route for my mbone tunnel? Do I need my mbone tunnel moved to a less busy route? Comments from knowledgeable persons would be appreciated if directed to harvie@media.mit.edu. I am reading this mailing list from archives. Thanks! configuration details follow: -> -> ->variety# uname -a ->SunOS variety 4.1.3_U1 6 sun4m -> ->mrouted.dump: -> ->Virtual Interface Table ->Vif Name Local-Address M Thr Rate Flags -> 0 le0 199.182.80.17 subnet: 199.182.80 1 1 0 querier -> groups: 224.2.172.156 -> 224.2.248.153 -> 224.2.127.255 -> 224.0.0.4 -> pkts in : 12922 -> pkts out: 833250 -> -> 1 le0 199.182.80.17 tunnel: 204.31.1.2 1 1 500 -> peers: 204.31.1.2 (3.3) -> pkts in : 1411615 -> pkts out: 12906 -> -> ->Multicast Routing Table (374 entries) [condensed] -> Origin-Subnet From-Gateway Metric In-Vif Out-Vifs -> 131.188 204.31.1.2 15 1 0* -> 150.166.56 204.31.1.2 20 1 0* -> 150.166.57 204.31.1.2 19 1 0* -> 150.166.61 204.31.1.2 15 1 0* -> 150.166.63 204.31.1.2 16 1 0* -> 150.166.65 204.31.1.2 19 1 0* -> ... -> 199.77.193 204.31.1.2 9 1 0* -> 199.182.80 1 0 1 -> 202.13.180 204.31.1.2 16 1 0* -> ... -> 203.5.73 204.31.1.2 13 1 0* -> 204.31.1 204.31.1.2 2 1 0* -> 204.46.19 204.31.1.2 11 1 0* -> -> -> -> ->Multicast Routing Cache Table (70 entries) [condensed] -> Origin-Subnet Mcast-group CTmr IVif Prcv# Psnt Forwvifs -> 192.67.226 224.2.172.156 415 1 0 0 -> 158.125.110 224.2.248.153 545 1 0 0 -> 131.188 224.2.0.1 514 1 0 P -> ... -> 171.69 224.2.248.153 139 1 0 0 -> 128.3.112 224.2.248.153 415 1 0 0 -> 128.102.84.128 224.2.172.156 192 1 0 0 -> 204.62.246.64 224.2.143.24 139 1 0 P -> 199.35.154 224.0.1.2 179 1 0 P -> 199.182.80 224.2.172.156 38 0 0 1 -> 199.182.80 224.2.248.153 68 0 0 1 -> -> -> ->variety# netstat -Ms ->multicast routing: -> 122338 datagrams with no route for origin -> 121827 upcalls made to mrouted -> 0 datagrams with malformed tunnel options -> 0 datagrams with no room for tunnel options -> 808455 datagrams arrived on wrong interface -> 29 datagrams dropped due to upcall Q overflow -> 0 datagrams cleaned up by the cache -> 0 datagrams dropped selectively by ratelimiter -> 0 datagrams dropped - bucket Q overflow -> 0 datagrams dropped - larger than bkt size -> -> ->variety# mrinfo mbone-west.noc.netcom.com ->204.31.1.2 (mbone-west.noc.netcom.net) [version 3.3]: -> 204.31.1.2 -> 0.0.0.0 (?) [1/16/querier] -> 204.31.1.2 -> 144.228.1.39 (dc-mbone-1.sprintlink.net) [1/1/tunnel/down] -> 204.31.1.2 -> 199.35.154.203 (sva.edu) [1/1/tunnel] -> 204.31.1.2 -> 199.182.80.17 (variety) [1/1/tunnel] -> -> ->variety# mrinfo variety ->199.182.80.17 (variety) [version 3.3]: -> 199.182.80.17 -> 0.0.0.0 (?) [1/1/querier] -> 199.182.80.17 -> 204.31.1.2 (mbone-west.noc.netcom.net) [1/1/tunnel] -> -> ->variety# mrinfo dc-mbone-1.sprintlink.net ->mrinfo: got reply from 204.31.1.2 instead of 144.228.1.39 ->144.228.1.39 (dc-mbone-1.sprintlink.net) [version 2.2]: -> 144.228.1.39 -> 0.0.0.0 (?) [1/1/disabled] -> 144.228.1.39 -> 144.228.26.1 (sl-dc-6.sprintlink.net) [1/1/tunnel] -> 144.228.1.39 -> 144.228.24.1 (sl-dc-4.sprintlink.net) [1/1/tunnel/down] -> 144.228.1.39 -> 192.80.214.224 (ICM2.icp.net) [1/64/tunnel] -> 144.228.1.39 -> 144.228.8.227 (ns2.sprintlink.net) [1/64/tunnel] -> 144.228.1.39 -> 199.0.55.3 (ns3.sprintlink.net) [1/64/tunnel/down] -> 144.228.1.39 -> 128.205.3.220 (otto.cit.buffalo.edu) [6/64/tunnel/down] -> 144.228.1.39 -> 199.72.1.6 (enterprise.interpath.net) [6/64/tunnel] -> 144.228.1.39 -> 199.3.12.3 (starcore.cris.com) [6/64/tunnel/down] -> 144.228.1.39 -> 192.246.16.163 (fs.wb.com) [6/64/tunnel] -> 144.228.1.39 -> 199.18.96.225 (oeb4-e1/0.columbus.oar.net) [6/64/tunnel/down] -> 144.228.1.39 -> 128.252.169.15 (sakhi.ccrc.wustl.edu) [6/64/tunnel/down] -> 144.228.1.39 -> 166.90.1.18 (?) [6/64/tunnel/down] -> 144.228.1.39 -> 166.90.1.203 (?) [6/64/tunnel/down] -> 144.228.1.39 -> 199.0.94.1 (elaine.crcg.edu) [6/64/tunnel/down] -> 144.228.1.39 -> 192.153.117.162 (NS.FLSIG.ORG) [6/128/tunnel/down] -> 144.228.1.39 -> 204.31.1.2 (mbone-west.noc.netcom.net) [6/64/tunnel] -> 144.228.1.39 -> 198.17.99.1 (dolphin.sb.grci.com) [6/64/tunnel] ->variety# -> ->ping -slRv results: -> ->(ping to the other end of our T-1 connection to netcom's denver router) ->PING t1-1.den-gw1.netcom.net: 56 data bytes ->64 bytes from variety (199.182.80.17): icmp_seq=0. time=11. ms -> IP options: den-gw1.netcom.net (163.179.16.1) den-gw1.netcom.net (163.179.16.1), is-router (199.182.80.1), variety (199.182.80.17), 0.0.0.0(Current), 0.0.0.0, 0.0.0.0, 0.0.0.0 ->64 bytes from variety (199.182.80.17): icmp_seq=1. time=11. ms ->... ->64 bytes from variety (199.182.80.17): icmp_seq=14. time=11. ms ->... ->----variety PING Statistics---- ->15 packets transmitted, 15 packets received, 0% packet loss ->round-trip (ms) min/avg/max = 11/12/29 -> -> ->(ping to the other end of our mbone tunnel at netcom noc) ->PING mbone-west.noc.netcom.net: 56 data bytes ->... ->64 bytes from variety (199.182.80.17): icmp_seq=115. time=9009. ms -> IP options: nocgw.noc.netcom.net (204.31.1.254) t1-1.den-gw1.netcom.net (163.179.111.2), nocgw.noc.netcom.net (204.31.1.254), mbone-west.noc.netcom.net (204.31.1.2), nocgw.netcom.net (163.179.203.2), t1-1.netcomgw.netcom.net (163.179.111.1), den-gw1.netcom.net (163.179.16.1), 0.0.0.0(Current) ->64 bytes from variety (199.182.80.17): icmp_seq=119. time=4975. ms ->64 bytes from variety (199.182.80.17): icmp_seq=123. time=941. ms ->64 bytes from variety (199.182.80.17): icmp_seq=124. time=72. ms ->64 bytes from variety (199.182.80.17): icmp_seq=125. time=76. ms ->64 bytes from variety (199.182.80.17): icmp_seq=126. time=54. ms -> ->----1 PING Statistics---- ->127 packets transmitted, 46 packets received, 63% packet loss ->round-trip (ms) min/avg/max = 47/7356/13131 ->variety% -> -> ->vic stats (NASA shuttle) 2/3/95 ->kilobits: 117000 frames: 13400 packets: 22500 missing: 5900 delay:~200.00 -> ->vat stats (NASA shuttle) 2/3/95: ->(typically 10-20 % missing packets 5-10% mis-ordered) ->packets:1100 missing: 340 misordered: 140 playout: 1.3s -> END OF CONFIGURATION INFO Thanks! Harvie Branscomb harvie@media.mit.edu tel: 1 303 963 1369 fax: 1 303 963 0401 Sun Aspen Smallworks is publishing to the internet via domain infosphere.com , servers located in Aspen Colorado. From list-mgr@ISI.EDU Fri Feb 3 15:26:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 23:25:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 23:23:16 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 3 Feb 1995 23:23:12 -0800 Received: by rx7.ee.lbl.gov for mbone@isi.edu (5.65/1.44r) id AA29444; Fri, 3 Feb 95 23:27:00 -0800 Message-Id: <9502040727.AA29444@rx7.ee.lbl.gov> To: "David A. Curry" Cc: mbone Subject: Re: Anybody know what these are? In-Reply-To: Your message of Fri, 03 Feb 95 14:39:55 EST. Date: Fri, 03 Feb 95 23:26:59 PST From: Van Jacobson > The consensus appears to be that they're nothing in particular. > Tom Pusateri summarized it best: > Multicast addresses are assigned dynamically by the Session > Directory tool, sd. None of the address listed (228.1.25.70, 224.8.8.8, 224.3.25.66) were assigned by sd. There is one 64K block of addresses designated by IANA for multimedia conferencing: 224.2.0.0 - 224.2.255.255. All addresses assigned by sd are in this range. 224.8.8.8 is an illegal address that Inria decided to use as the IVS default. When you see this it might mean that someone is running IVS. But Ohio State also tends to run a lot of vat sessions on funny addresses. Possibly they think this makes them private. Whenever I've looked at packet source addresses, all the partcipants in these sessions are at Ohio State & I've never understood why they don't simply create sessions with local scope which really would be private & wouldn't gunk up the global mbone with purely local chatter. But there appears to be some deep human need to spread one's packets over as much of the earth as possible. The other addresses aren't familiar but illegal multicast addresses usually represent people trying to hide "private" conversations and/or doing local testing at inappropriately large ttl. - Van From list-mgr@ISI.EDU Sun Feb 5 12:46:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 5 Feb 1995 04:50:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 5 Feb 1995 04:46:59 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 5 Feb 1995 04:46:57 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Sun, 5 Feb 1995 04:46:49 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 5 Feb 1995 12:46:32 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: "David A. Curry" Cc: mbone Subject: Re: Anybody know what these are? In-Reply-To: Your message of "Fri, 03 Feb 95 14:39:55 EST." <199502031939.OAA25976@intrepid.ecn.purdue.edu> Date: Sun, 05 Feb 95 12:46:03 +0000 Message-Id: <730.791988363@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >Earlier today, I asked what these were: > > > 228.1.25.70 (traffic is coming from magritte.cc.gatech.edu, among > > others) > > > > 224.8.8.8 (traffic is coming from stargate.acs.ohio-state.edu) > > > > 224.3.25.66 (traffic is coming from some unregistered address in > > trw.com domain; 192.4.4.35) > >The consensus appears to be that they're nothing in particular. Tom Pusateri >summarized it best: > > Multicast addresses are assigned dynamically by the Session > Directory tool, sd. Different types of traffic will be on these > addresses at different times. Your only clue would be to look > further into the packet. Most likely it will be UDP traffic and > the port numbers are also assigned dynamically so you would have > to look into the stream to see if it is vic video, nv video, vat > audio, ivs audio, etc. Actually, this is correct, but not for these addresses. sd only allocates addresses of the form 224.2.*.*. so these addresses cannot be allocated randomly by sd. 224.8.8.8 was the default address for IVS. At a guess, the other two addresses look like someone using their date of birth as multicast addresses (25th Mar 1966 and 25 Jan 1970). Probably they're vat traffic (maybe with wb and/or nv/vic) that someone didn't want to be public. It's pretty obvious from a tcpdump which media is which. If the data rate's low, don't worry about it. If it's high (>200Kbps at ttl 127), and you see this clashing with something else, scream again. Those of us at the end of pruned links don't get to monitor this sort of thing anymore. Mark From list-mgr@ISI.EDU Sun Feb 5 11:46:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 5 Feb 1995 13:52:40 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 5 Feb 1995 13:47:12 -0800 Received: from mailer.psc.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 5 Feb 1995 13:47:05 -0800 Received: from zippy.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA13173; Sun, 5 Feb 1995 16:46:59 -0500 Message-Id: <9502052146.AA13173@mailer.psc.edu> To: mbone Cc: mathis@psc.edu Subject: MBone Contacts Date: Sun, 05 Feb 1995 16:46:58 -0500 From: "Matt Mathis" I have updated the MBone contact list such that I can easily generate both text and html versions. In the future I will only post short notices of updates to the entire Mbone list. There have been many changes since the last update. Sorry about the long delay. The MBone contact database at http://www.psc.edu/~mathis/contacts.html and in ftp://ftp.psc.edu/pub/mbone/contacts.txt have been updated. If you wish to receive text versions of the entire document (as a subscription) please drop me a note. Also, I will now accept URL's for providers. (But not as a substitute for other contact information.) Thanks, --MM-- From list-mgr@ISI.EDU Sun Feb 5 20:18:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 5 Feb 1995 22:20:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 5 Feb 1995 22:18:53 -0800 Received: from alterdial.UU.NET by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 5 Feb 1995 22:18:51 -0800 Received: from [198.4.181.158] by alterdial.UU.NET with SMTP id QQybwj20359; Mon, 6 Feb 1995 01:18:46 -0500 X-Sender: mail00821@alterdial.uu.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 6 Feb 1995 01:18:21 -0500 To: mbone From: adamgood@voices.com (Adam Goodman) Subject: MRouted on a SPARC Hello all. I am setting up a site that will primarily be used in conjunction with the MBONE. I am currently in the process of selecting the harware we will need to operate this site and I was hoping someone could help me with this question. Could someone please tell me what the advantage is to configuring a SPARC to run mrouted x.x vs. buying a multicast equipped router such as the Proteon or a Cisco? Are there other companies building such routers? If there are, could someone please tell me who and which models? Will updates to mrouted be crucial for future participation in the MBONE and require a SPARC in order to take advantage of them? Or will updates be constantly released for commercial routing software that keep pace with the development on mrouted? Will it be necessary to buy these updates (if they are available), or will the router companies provide free updates? Isn't it more expensive to dedicate a separate SPARC just to handle multicast routing when a separate IP router is still required? Or is multicast routing such a processor intensive application that it really needs its own separate router no matter what? In other words; is one Proteon or Cisco router that can handle plain IP routing and multicast routing up to the task of doing both simultaneously? Or are two needed to do this well? Also, it is my understanding that if a SPARC is used with mrouted, that a dedicated machine is recommended due to the neccesity of recompiling kernels and modifying the OS for every update. Is this more cost effective (or more effective in an absolute sense) than using commercial routers? I apologize for the long question, but any experiences or assistance here are greatly appreciated, and I will be happy to foward this information to anyone else who needs it. TIA, -Adam Adam M. Goodman Mulsanne Communications 19 W. 44th St. Ste. 1217 New York, NY 10036 ph# (212) 221-7065 fx# (212) 221-1413 From list-mgr@ISI.EDU Mon Feb 6 01:07:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 01:11:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 01:07:56 -0800 Received: from uucp0.iij.ad.jp by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 01:07:48 -0800 Received: from mewgate.mew.co.jp (mewgate.mew.co.jp [133.254.5.10]) by uucp0.iij.ad.jp (8.6.9+2.4Wb/3.3Wb-UUCP) with ESMTP id LAA05629 for <@uucp0.iij.ad.jp:mbone@isi.edu>; Mon, 6 Feb 1995 11:35:12 +0900 Received: from mewserv2.mew.co.jp ([133.254.7.11]) by mewgate.mew.co.jp (8.6.8+2.4Wb2/3.3W-mewgate-940715) with ESMTP id LAA06540 for ; Mon, 6 Feb 1995 11:35:09 +0900 Received: from gripen.ai.mew.co.jp (gripen.ai.mew.co.jp [133.254.10.74]) by mewserv2.mew.co.jp (8.6.8+2.4Wb2/3.3W-mewserv2) with SMTP id LAA18907 for ; Mon, 6 Feb 1995 11:35:08 +0900 Received: by gripen.ai.mew.co.jp (4.1/6.4J.6-ai_940425) id AA05390; Mon, 6 Feb 95 11:22:48 JST Date: Mon, 6 Feb 95 11:22:48 JST From: tomio@ai.mew.co.jp (Steve Madsen) Message-Id: <9502060222.AA05390@gripen.ai.mew.co.jp> To: mbone Subject: Where's the faq? Folks: Sorry to post this, but I learned about MBone from IEEE Computer magazine and not off the net, so while I know where the mailing list is, and am subscribed, I don't know where (or if) the usenet mbone group exists, nor the location of the faq. Could someone could please send me a quick e-mail with ftp or http address for the mbone FAQ? -- Steve Madsen, Research Engineer Tel: 011-81-6-908-6835 Virtual Reality R&D Lab, IS Center Fax: 011-81-6-900-2766 Matsushita Electric Works, Ltd. e-mail: tomio@ai.mew.co.jp 1048, Kadoma, Osaka 571 JAPAN From list-mgr@ISI.EDU Sun Feb 5 17:58:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 02:05:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 02:02:02 -0800 Received: from mx4.u.washington.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 02:02:01 -0800 Received: from hitl-new.hitl.washington.edu by mx4.u.washington.edu (5.65+UW94.10/UW-NDC Revision: 2.31 ) id AA08061; Mon, 6 Feb 95 02:02:01 -0800 Received: by hitl.hitl.washington.edu; id AA27261; Mon, 6 Feb 1995 01:58:02 -0800 Message-Id: <9502060958.AA27261@hitl.hitl.washington.edu> To: tomio@ai.mew.co.jp (Steve Madsen) Cc: mbone Subject: Re: Where's the faq? In-Reply-To: Your message of Mon, 06 Feb 95 11:22:48 +0200. <9502060222.AA05390@gripen.ai.mew.co.jp> Date: Mon, 06 Feb 95 01:58:01 -0800 From: pdanset@hitl.washington.edu X-Mts: smtp Steve, This is a good place to start: http://www.eit.com/techinfo/mbone/mbone.html I believe there is a separate mailing list for Japan, and I got some MBONE maps from Japan, although I can't remember where (sorry). Regards, -- Paul -------------------------------------------------------------------------- Paul Danset Email: pdanset@hitl.washington.edu Tel: +1-206-616-1476 URL: http://www.hitl.washington.edu/people/pdanset FAX: +1-206-543-5380 Human Interface Technology Lab, FJ-15, U. of Washington, Seattle, WA 98195 > Folks: > > Sorry to post this, but I learned about MBone from IEEE Computer magazine > and not off the net, so while I know where the mailing list is, and am > subscribed, I don't know where (or if) the usenet mbone group exists, nor the > location of the faq. > > Could someone could please send me a quick e-mail with ftp or http address fo r > the mbone FAQ? > > -- > Steve Madsen, Research Engineer Tel: 011-81-6-908-6835 > Virtual Reality R&D Lab, IS Center Fax: 011-81-6-900-2766 > Matsushita Electric Works, Ltd. e-mail: tomio@ai.mew.co.jp > 1048, Kadoma, Osaka 571 JAPAN > From list-mgr@ISI.EDU Mon Feb 6 11:44:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 03:48:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 03:45:48 -0800 Received: from swan.cl.cam.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 03:45:36 -0800 Received: from labes.cl.cam.ac.uk (user pb (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Mon, 6 Feb 1995 11:45:07 +0000 X-Mailer: exmh version 1.5.3+cl+pgp 94/12/28 To: rem-conf@net.es, mbone Cc: Ross.Anderson@cl.cam.ac.uk Subject: JIPS Mbone transmission 95/02/07 16:15-17:15UTC (cl.cam.ac.uk Security) X-Uri: X-Face: &@N3QE9h|>f`igFCkZ'a1`z=nNLXb}k>H(79G"V?@!&*yn)uhPBctF1vc}LD'{OA%$bsX+l [wN,I^G8kKj2NFxQrr@1C4QBC]hq5-%ZkV,^Zl/qE<0`zCQ1nM+]-N<^WG[H)]?d)A:L9AFgOU[Bjb aY)uBAMz}h!fm^O0# Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Feb 1995 11:44:59 +0000 From: Piete Brooks Message-Id: <"swan.cl.cam.:216790:950206114510"@cl.cam.ac.uk> We hope to be transmitting the Security Group's seminar. The expected audience is UK sites interested in Security, so the TTL is being set low. It's meant as a "low key" transmission (without anyone manning the camera, etc) but if anyone outside JIPS wants the TTL raised, please let me know. [[ We shall be using nv, as I haven't yet heard of a way for vic to work on a mono screen, and anyway, we're not geared up for vic recording yet ]] SPEAKER: Peter Sommer, LSE DATE: 7th February 1995 at 4.15pm (16:15 UTC) TITLE: INSURANCE AS AN ENFORCER/PERSUADER FOR COMPUTER SECURITY The speaker will consider enforcement and persuasive mechansisms in general - - risk analysis, law, regulation, contractual requirements, etc - and then show the role of insurance in these. He will then discuss how insurers make their commercial decisions, and argue that perhaps one should not expect too much of a lead from them. Finally, and if there is time and interest, he can look at the possibilities of new forms of computer-related insurance. This seminar will be multicast (audio and video) on the mbone as part of our multimedia test programme. Further information is available at http://www.cl.cam.ac.uk/mbone/#cl. From list-mgr@ISI.EDU Mon Feb 6 12:51:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 20:47:11 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 20:47:09 -0800 Received: by rx7.ee.lbl.gov for mbone-na@isi.edu (5.65/1.44r) id AA02563; Mon, 6 Feb 95 20:51:01 -0800 Message-Id: <9502070451.AA02563@rx7.ee.lbl.gov> To: mbone-na Subject: why is UDel trashing the MBone? Date: Mon, 06 Feb 95 20:51:00 PST From: Van Jacobson Did UDel just give mbone access to a bunch of 10 year olds? clem@ossifrage.rayst.udel.edu is sending 400kb/s nv video. scott@degenerate.ee.udel.edu is sending pcm vat (50p/s) with silence suppression turned off. golden@xenomancer.rayst.udel.edu is doing the same from two workstations simulatanously. A bunch of sd sessions like "Clem's Cool Group (video)", "doke's trial" and "Ed's Trial". All the participants in this deluge appear to be at UDel but they're all using at ttl of 127. Could some adult please ask them to stop? Thanks. - Van From list-mgr@ISI.EDU Mon Feb 6 13:15:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 21:11:17 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 21:11:15 -0800 Received: by rx7.ee.lbl.gov for mbone-na@isi.edu (5.65/1.44r) id AA02566; Mon, 6 Feb 95 21:15:07 -0800 Message-Id: <9502070515.AA02566@rx7.ee.lbl.gov> To: mbone-na Subject: UDel continues to trash mbone Date: Mon, 06 Feb 95 21:15:06 PST From: Van Jacobson This is actually quite impressive. They're now sending 1.4Mb/s, almost all of it nv X screendumps (Ron Frederick putting that X grabber in nv has to stand out as one of the most antisocial things ever done to the Internet). I think they've now saturated the UDel's T1 links so it probably can't get any worse. From the mrouted route change messages I'm seeing, it appears that routers are falling over all over the world. Ah well, I guess the MBone needed a stress test. - Van From list-mgr@ISI.EDU Mon Feb 6 16:38:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 22:41:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 22:38:14 -0800 Received: from ece.arizona.edu (ece1.ece.arizona.edu) by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Feb 1995 22:38:13 -0800 Received: from wynken.ece.arizona.edu.ece.arizona.edu by ece.arizona.edu (5.0/SMI-SVR4) id AA23761; Mon, 6 Feb 1995 23:38:12 -0700 Date: Mon, 6 Feb 1995 23:38:12 -0700 From: gmoon@ece.arizona.edu (Gwi Moon) Message-Id: <9502070638.AA23761@ece.arizona.edu> To: mbone Subject: Number of MBONE participants. Content-Length: 215 Hi, I am wondering about the current number of MBONE participants over the whole world. Could anyone tell me the number of MBONE routers and countries connected to the MBONE? Thanks, Moon, Gwi Moon@Arizona.EDU From list-mgr@ISI.EDU Tue Feb 7 15:40:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 03:41:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 03:40:34 -0800 Received: from mits.mdata.fi by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 03:40:31 -0800 Received: from localhost (setala@localhost) by mits.mdata.fi (8.6.5/8.6.5) id NAA08724 for mbone@isi.edu; Tue, 7 Feb 1995 13:40:29 +0200 From: Saku Setala Message-Id: <199502071140.NAA08724@mits.mdata.fi> Subject: Vic problems To: mbone Date: Tue, 7 Feb 1995 13:40:29 +0200 (EET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 177 Hi, does anyone have the same problems with vic 2.6 on SunOS 4.1.3_u1 Vic often dies with message: shmget: Invalid argument What could be the problem? Thanks. --Saku From list-mgr@ISI.EDU Tue Feb 7 13:09:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 05:12:24 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 05:10:12 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 05:10:10 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id NAA01906; Tue, 7 Feb 1995 13:09:49 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id NAA07753; Tue, 7 Feb 1995 13:09:46 GMT Date: Tue, 7 Feb 1995 13:09:45 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Saku Setala Cc: mbone Subject: Re: Vic problems In-Reply-To: <199502071140.NAA08724@mits.mdata.fi> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 7 Feb 1995, Saku Setala wrote: > Hi, > > does anyone have the same problems with vic 2.6 on SunOS 4.1.3_u1 > Vic often dies with message: shmget: Invalid argument > > What could be the problem? You need to increase the size of the shared memory segments supported by the kernel. I also noticed this problem when trying to display large images. To do this add the following to your kernel configuration file and rebuild: options SHMSIZE=2048 Alternatively, if rebuilding your kernel is not an option you can tell vic not to use shared memory. You will get a performance hit, though, if you do this. The -s option will tell vic not to use shared memory. You will need to edit your .sd.tcl file to get sd to startup vic with the -s option. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Wed Feb 8 47:37:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 05:42:26 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 05:41:29 -0800 Received: from phibes.dartmouth.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 05:41:26 -0800 Received: from phibes.dartmouth.edu (localhost [127.0.0.1]) by phibes.dartmouth.edu (8.6.9/8.6.6) with ESMTP id IAA12867; Tue, 7 Feb 1995 08:41:10 -0500 Message-Id: <199502071341.IAA12867@phibes.dartmouth.edu> To: Saku Setala Cc: mbone Subject: Re: Vic problems In-Reply-To: (Your message of Tue, 07 Feb 1995 13:40:29 EST.) <199502071140.NAA08724@mits.mdata.fi> Date: Tue, 07 Feb 1995 08:41:10 +22306256 From: Pat Wilson > Hi, > > does anyone have the same problems with vic 2.6 on SunOS 4.1.3_u1 > Vic often dies with message: shmget: Invalid argument > > What could be the problem? > > Thanks. > > --Saku > It could be (a) you don't have IPCSHMEM enabled in your kernel (it's not turned on in the GENERIC_SMALL configuration) or (b) the max segment size is too small (also kernel tunable - use "options SHMSIZE=2048"). Another tack is to run vic without shared membory support - use the '-s' flag when you call it (i.e. "vic -s"). Pat Wilson paw@northstar.dartmouth.edu From list-mgr@ISI.EDU Tue Feb 7 18:24:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 08:27:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 08:26:16 -0800 Received: from chx400.switch.ch by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 08:26:11 -0800 X400-Received: by mta chx400.switch.ch in /PRMD=Switch/ADMD=Arcom/C=Ch/; Relayed; Tue, 7 Feb 1995 17:24:34 +0100 X400-Received: by /PRMD=UBS/ADMD=ARCOM/C=CH/; Relayed; Tue, 7 Feb 1995 17:24:04 +0100 Date: Tue, 7 Feb 1995 17:24:04 +0100 X400-Originator: Markus.Vetterli@zh004.ubs.ubs.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=ubs/ADMD=arcom/C=ch/;svplatin.z.618:07.01.95.16.24.04] X400-Content-Type: P2-1984 (2) Content-Identifier: ISIS Multicast Alternate-Recipient: Allowed From: Markus.Vetterli@zh004.ubs.ubs.ch Message-Id: <"20621 Tue Feb 7 17:24:08 1995"@zh004.ubs.ubs.ch> To: mbone Subject: ISIS Multicast Hi together, I have a user which ask me for ISIS from RFC 1054 and now my question. Is there a any knowledge about this ISIS and also together with Cisco routers. Have there anybody experience with ISIS and/or Cisco's Multicast Features? In which SW Release is this implemented? Thanks G'Day Markus Vetterli UBS Network Services Tel: +41/1/236 76 62 P.O.Box Fax: +41/1/236 69 30 CH-8021 Zuerich Switzerland E-mail: Markus.Vetterli@zh004.ubs.ubs.ch X.400 : /S=Markus/G=Vetterli/OU=zh004/O=ubs/PRMD=ubs/ADMD=arcom/C=CH From list-mgr@ISI.EDU Tue Feb 7 10:34:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 18:38:18 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 18:35:12 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Feb 1995 18:34:46 -0800 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14643(6)>; Tue, 7 Feb 1995 18:34:40 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Tue, 7 Feb 1995 18:34:36 -0800 To: mbone Cc: raub@alder.circa.ufl.edu, jkrey Subject: mrouted for Untrix 4.2 Date: Tue, 7 Feb 1995 18:34:32 PST Sender: Steve Deering From: Steve Deering Message-Id: <95Feb7.183436pst.12174@skylark.parc.xerox.com> Can someone on the mbone list help this fellow out?... ------- Forwarded Message From: raub@alder.circa.ufl.edu Subject: mrouted binary for Ultrix 4.2 To: deering@pescadero.stanford.edu Date: Tue, 7 Feb 1995 18:07:31 -0800 Cc: jkrey@venera.isi.edu Does any of you know where I can get a binary of the mrouted program for Ultrix 4.2? I have been trying to get it to compile here but am having some interesting problems. Such problems are interesting enough so to make me forget about them and simply try to get a binary version of mrouted. ------- End of Forwarded Message From list-mgr@ISI.EDU Wed Feb 8 12:08:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 8 Feb 1995 16:22:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 8 Feb 1995 16:08:55 -0800 Received: from primus.cstp.umkc.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 8 Feb 1995 16:08:52 -0800 Received: by CSTP.UMKC.EDU (MX V4.1 AXP) id 30; Wed, 08 Feb 1995 18:08:42 CST Date: Wed, 08 Feb 1995 18:08:41 CST From: dvenkat@CSTP.UMKC.EDU To: mbone Cc: dvenkat@CSTP.UMKC.EDU Message-Id: <0098BB07.77F6435C.30@CSTP.UMKC.EDU> Subject: subscribe subscribe Internet: DVENKAT@CSTP.UMKC.EDU University of Missouri - Kansas City Computer Science Telecommunications Program From list-mgr@ISI.EDU Wed Feb 8 19:37:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 8 Feb 1995 21:40:40 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 8 Feb 1995 21:39:50 -0800 Received: from portal.netedge.com by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 8 Feb 1995 21:39:48 -0800 Received: from NetEdge.COM by portal.netedge.com id AA13872; Thu, 9 Feb 95 00:37:45 EST Received: from floyd.NetEdge.COM by NetEdge.COM id AA10132; Thu, 9 Feb 95 00:39:17 EST Return-Path: Received: from localhost by floyd.NetEdge.COM (4.1/NECL-6.14) id AA10989; Thu, 9 Feb 95 00:37:43 EST Message-Id: <9502090537.AA10989@NetEdge.COM> To: mbone Subject: high TTL IGMP messages Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <10986.792308262.1@floyd.netedge.com> Date: Thu, 09 Feb 1995 00:37:43 -0500 From: Thomas Pusateri I fired up multicast gated for the first time tonight on a network connected to the mbone and got this log message: Feb 8 21:12:02 igmp_recv: ignoring igmp msg from remote source: 146.169.2.33 Looks like swan.doc.ic.ac.uk has a bad kernel (maybe the RSVP_ISI make clean problem) Tom From list-mgr@ISI.EDU Wed Feb 8 20:30:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 8 Feb 1995 22:35:01 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 8 Feb 1995 22:34:21 -0800 Received: from portal.netedge.com by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 8 Feb 1995 22:34:19 -0800 Received: from NetEdge.COM by portal.netedge.com id AA13899; Thu, 9 Feb 95 01:32:17 EST Received: from suicidesix.NetEdge.COM by NetEdge.COM id AA10248; Thu, 9 Feb 95 01:33:49 EST Return-Path: Received: from localhost by suicidesix.NetEdge.COM (4.1/NECL-6.14) id AA07245; Thu, 9 Feb 95 01:30:45 EST Message-Id: <9502090630.AA07245@NetEdge.COM> To: mbone Subject: Re: high TTL IGMP messages Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <7242.792311443.1@suicidesix> Date: Thu, 09 Feb 1995 01:30:44 -0500 From: Thomas Pusateri >I fired up multicast gated for the first time tonight on a network >connected to the mbone and got this log message: >Feb 8 21:12:02 igmp_recv: ignoring igmp msg from remote source: 146.169.2.33 >Looks like swan.doc.ic.ac.uk has a bad kernel >(maybe the RSVP_ISI make clean problem) Oops I meant sticky.doc.ic.ac.uk not swan. I also see some from miler.ucs.ualberta.ca (129.128.10.126) Tom From list-mgr@ISI.EDU Thu Feb 9 14:53:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 06:55:34 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 06:54:49 -0800 Received: from lust.mrrl.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 06:54:30 -0800 Received: from localhost (martin@localhost) by lust.mrrl.lut.ac.uk (8.6.9/8.6.9) with SMTP id OAA15630; Thu, 9 Feb 1995 14:53:20 GMT Message-Id: <199502091453.OAA15630@lust.mrrl.lut.ac.uk> To: mbone, rem-conf@es.net X-Uri: Subject: searchable archives Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <15622.792341595.1@mrrl.lut.ac.uk> Date: Thu, 09 Feb 1995 14:53:15 +0000 From: Martin Hamilton I said: | I was just wondering whether there are searchable (e.g. via WAIS) | and/or browsable (e.g. via WWW/hypermail) versions of the rem-conf | and mbone list archives. I know they're FTPable... Found some bits and bobs at... Martin From list-mgr@ISI.EDU Wed Feb 8 23:57:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 07:58:54 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 07:58:11 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 07:58:10 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14700(3)>; Thu, 9 Feb 1995 07:57:58 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Thu, 9 Feb 1995 07:57:48 -0800 X-Mailer: exmh version 1.5.3 12/28/94 To: Thomas Pusateri Cc: mbone, fenner@parc.xerox.com Subject: Re: high TTL IGMP messages In-Reply-To: Your message of "Wed, 08 Feb 95 22:30:44 PST." <9502090630.AA07245@NetEdge.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Feb 1995 07:57:39 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <95Feb9.075748pst.49859@crevenia.parc.xerox.com> In message <9502090630.AA07245@NetEdge.COM> you write: >>Looks like swan.doc.ic.ac.uk has a bad kernel >>(maybe the RSVP_ISI make clean problem) > >Oops I meant sticky.doc.ic.ac.uk not swan. > >I also see some from miler.ucs.ualberta.ca (129.128.10.126) I already contacted sticky.doc.ic.ac.uk, miler.ucs.ualberta.ca, frodo.csg.lbl.gov, ka.ee.pdx.edu. LBL is the only one that I haven't gotten a reply back from yet. I have a form letter that I send out to hosts sending out high-TTL IGMP's, describing the RSVP_ISI problem and how to rebuild your kernel. Bill From list-mgr@ISI.EDU Thu Feb 9 01:35:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 09:37:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 09:36:57 -0800 Received: from eitech.eit.COM by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 09:36:56 -0800 Received: from collage (collage.eit.COM) by eitech.eit.com (4.1/SMI-4.1) id AA11793; Thu, 9 Feb 95 09:35:26 PST Date: Thu, 9 Feb 95 09:35:26 PST From: vinay@eit.COM (Vinay Kumar) Message-Id: <9502091735.AA11793@eitech.eit.com> To: martin@mrrl.lut.ac.uk Subject: Re: searchable archives Cc: mbone, rem-conf@es.net As soon as i find time i will put the HTML'ized "hypermail'ed" version of mail-archive's on the MBone Home Page. Fair ? --- Vinay Kumar vinay@eit.com "Sucker for MBone...." > From list-mgr@ISI.EDU Thu Feb 9 08:06:07 1995 > To: mbone@ISI.EDU, rem-conf@es.net > X-Uri: > Subject: searchable archives > Mime-Version: 1.0 > Content-Type> : > text/plain> ; > charset="us-ascii"> > Content-Id: <15622.792341595.1@mrrl.lut.ac.uk> > Date: Thu, 09 Feb 1995 14:53:15 +0000 > From: Martin Hamilton > Content-Length: 304 > > I said: > > | I was just wondering whether there are searchable (e.g. via WAIS) > | and/or browsable (e.g. via WWW/hypermail) versions of the rem-conf > | and mbone list archives. I know they're FTPable... > > Found some bits and bobs at... > > > > Martin > > From list-mgr@ISI.EDU Thu Feb 9 03:09:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 11:11:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 11:09:57 -0800 Received: from osi-east.es.net by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 11:09:56 -0800 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <21340-0@osi-east.es.net>; Thu, 9 Feb 1995 11:09:37 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA07906; Thu, 9 Feb 95 11:09:31 PST Date: Thu, 9 Feb 95 11:09:31 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9502091909.AA07906@viipuri.nersc.gov> To: mbone, rem-conf@es.net Subject: Re: searchable archives > From: Martin Hamilton > Status: RO > > I said: > > | I was just wondering whether there are searchable (e.g. via WAIS) > | and/or browsable (e.g. via WWW/hypermail) versions of the rem-conf > | and mbone list archives. I know they're FTPable... > > Found some bits and bobs at... > > > The rem-conf archives are WAIS searchable and Web browsable: http//:www.es.net/pub/mailing-lists/mail-archive/rem-conf/ at least *my* browser (Netscape on my home Mac) is capable of finding arbitrary text strings in the archived files... Ari@ES.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 ~~RECOM Technologies Inc.~~ From list-mgr@ISI.EDU Thu Feb 9 03:26:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 11:27:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 11:26:26 -0800 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 11:26:25 -0800 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA26736 (5.65c/IDA-1.4.4nsd for ); Thu, 9 Feb 1995 11:26:24 -0800 Received: by jaspar.NSD.3Com.COM id AA14221 (5.65c/IDA-1.4.4-910730 for mbone@isi.edu); Thu, 9 Feb 1995 11:26:20 -0800 From: "Cyndi M. Jung" Message-Id: <199502091926.AA14221@jaspar.NSD.3Com.COM> Subject: Re: starting mrouted - thanks (fwd) To: mbone Date: Thu, 9 Feb 1995 11:26:19 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2177 I had received conflicting reports on this question, so I put a monitoring tool on the firewall as I started the applications, and it turned out that the multicast data received on the tunnel was indeed forwarded back out the ethernet interface, even though there were no receivers. Is it that mrouted considers the local application to be a receiver located on the physical interface? Or is it more subtle than that. This is v3.3 - will configuring a non-existent tunnel do the trick (a couple of people have suggested this - it's a little more expedient than putting another ethernet card in the system)? Cyndi > > > > > Several people have responded to me, and have been quite > > helpful. I've been reasured that no unwanted traffic > > will be sent out the single physical interface if I > > enable it for mrouted's use - only if there are apps > > on that segment (or presumably another multicast router) > > will any multicast traffic be sent there. This is really > > good news, as the interface in question is my firewall, > > and I didn't want to add unnecessarily to it's current load. > > Are you sure? At least on my decstation, running v3.1 the traffic did go on > to the ethernet. If an app was run on the mrouter then the traffic was > ethernet multicast on the physical interface. > > This caused all sorts of problems here on old dec bridges and terminal > servers. For this reason I have been unable to re-connect to the mbone for 4 > months. > > > > > > > > > > > > I've just put a Sparc up with a rebuilt multicast kernel > > > and have run into a small snag. I want this machine to > > > be the only multicast receiver with just the tunnel for > > > now, but the mrouted won't start if it doesn't have another > > > interface - just as it says in the faq. Is there any way > > > around this? I don't want to enable multicast back onto > > > the same interface that the tunnel is coming through, and > > > I don't have another ethernet card for the Sparc right now. > > > Is there anything I can do to get this running before I > > > get the second ethernet interface? > > > > > > Cyndi Jung > > > 3Com Corporation > > > > > From list-mgr@ISI.EDU Thu Feb 9 21:28:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 13:36:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 13:35:25 -0800 Received: from louie.udel.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 13:35:23 -0800 Received: from snow-white-fddi.udel.edu by louie.udel.edu id aa09104; 9 Feb 95 16:31 EST Received: from louie.udel.edu by snow-white.ee.udel.edu id aa16559; 9 Feb 95 16:31 EST Received: from snow-white.ee.udel.edu by beauregard.udel.edu id aa16907; 9 Feb 95 21:28 GMT To: "Cyndi M. Jung" Cc: mbone Subject: Re: starting mrouted - thanks (fwd) In-Reply-To: Your message of "Thu, 09 Feb 1995 11:26:19 PST." <199502091926.AA14221@jaspar.NSD.3Com.COM> Date: Thu, 09 Feb 1995 21:28:22 +0000 From: Ajit Thyagarajan Message-Id: <9502092128.aa16907@beauregard.udel.edu> In message <199502091926.AA14221@jaspar.NSD.3Com.COM>you wrote: >I had received conflicting reports on this question, so I >put a monitoring tool on the firewall as I started the >applications, and it turned out that the multicast data >received on the tunnel was indeed forwarded back out the >ethernet interface, even though there were no receivers. >Is it that mrouted considers the local application to be >a receiver located on the physical interface? Or is it >more subtle than that. This is v3.3 - will configuring a >non-existent tunnel do the trick (a couple of people have >suggested this - it's a little more expedient than putting >another ethernet card in the system)? No - if you are going to run an application on the machine which you are tunnelling from, then the traffic belonging to that application will appear on the corresponding interface. There is a proposal to include support for a configuration where a tunneling machine acting as a host does not have to forward traffic onto the interface. We'll see if it can come out in the next release. Ajit From list-mgr@ISI.EDU Thu Feb 9 10:02:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 18:03:10 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 18:02:21 -0800 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Feb 1995 18:02:20 -0800 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA12804 (5.65c/IDA-1.4.4nsd for ); Thu, 9 Feb 1995 18:02:18 -0800 Received: by jaspar.NSD.3Com.COM id AA15290 (5.65c/IDA-1.4.4-910730 for mbone@isi.edu); Thu, 9 Feb 1995 18:02:15 -0800 Date: Thu, 9 Feb 1995 18:02:15 -0800 From: "Cyndi M. Jung" Message-Id: <199502100202.AA15290@jaspar.NSD.3Com.COM> To: mbone Subject: Audio problems - need help Hi - me again, I must be doing something wrong. The audio on my SPARC5 that I am using for my MBONE connection is really strange - it only comes out when I wiggle the volume control (via the slider on the tool). And then, I have to wiggle it at just the right rate to get anything intelligible - which seems to vary with the speaker! I'm sure it isn't supposed to work that way. The kernel was built using the SUN GENERIC kernel for 4.1.3_U1, with a minor modification to allow more users. We used the MCAST_INSTALL script, and the 3.3 release for sunos413x. So far so good. Then we ftp'd the tar.Z files for sd, nv, vat, wb, and the vic (haven't touched that yet). I got sd up - no problem - ran an audio session and realized that the audio patch for the SPARC5 was required. Did that. Then the funny thing with the volume control. The audio buffer size is 160, as stated in the faq - I thought I had broken that with the SPARC5 audio patch, but that does not appear to be the problem. Is it because I'm running this under OpenWindows? I'll be truly mystified if this is the problem. It doesn't smell like packet loss - it's as if the audio buffer isn't flushed to the device unless triggered by activity on the volume control. Any help will be very much appreciated, Thanks, Cyndi From list-mgr@ISI.EDU Fri Feb 10 09:22:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 01:23:16 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 01:22:42 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 01:22:29 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id JAA01284; Fri, 10 Feb 1995 09:22:24 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id JAA01655; Fri, 10 Feb 1995 09:22:21 GMT Date: Fri, 10 Feb 1995 09:22:18 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: "Cyndi M. Jung" Cc: mbone Subject: Re: Audio problems - need help In-Reply-To: <199502100202.AA15290@jaspar.NSD.3Com.COM> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 9 Feb 1995, Cyndi M. Jung wrote: > I must be doing something wrong. The audio on my No, you are not. > SPARC5 that I am using for my MBONE connection is really > strange - it only comes out when I wiggle the volume control > (via the slider on the tool). And then, I have to wiggle > it at just the right rate to get anything intelligible - > which seems to vary with the speaker! I'm sure it isn't > supposed to work that way. That is how Sun shipped their audio driver though. > The kernel was built using the SUN GENERIC kernel > for 4.1.3_U1, with a minor modification to allow more users. > We used the MCAST_INSTALL script, and the 3.3 release for > sunos413x. So far so good. Then we ftp'd the tar.Z files > for sd, nv, vat, wb, and the vic (haven't touched that yet). > I got sd up - no problem - ran an audio session and realized > that the audio patch for the SPARC5 was required. Did that. > Then the funny thing with the volume control. The audio buffer > size is 160, as stated in the faq - I thought I had broken that > with the SPARC5 audio patch, but that does not appear to be > the problem. > > Is it because I'm running this under OpenWindows? I'll No. It is caused by the broken audio driver shipped on the SPARC 5 systems. > be truly mystified if this is the problem. It doesn't smell > like packet loss - it's as if the audio buffer isn't flushed > to the device unless triggered by activity on the volume > control. This problem surely must be in the FAQ by now. The audio device on the SPARC 5 is different from that shipped on the other SPARCstations. The driver code is therefore different and Sun made a real mess of it. There are currently some patches available which go some way top fixing it and I have detailed them below. There is a patch which will completely fix the problem and it was produced by Van Jacobson shortly after the Xmas vacation. Van sent his fixes back to Sun but I have not heard of any official patch release since then, perhaps someone can correct me if I am wrong. Anyway here is the officially available patches (The version numbers of these patches may have changed. It is a couple of months since I wrote this.): You don't say which operating system is being used so I will list everything I know: For SunOS 4.1.3U1B: You need to apply the following patches: 102161-01 and 101508-07. Once you have done that I have found that setting the kernel variable audio_4231_bsize to 1200 will make the audio device work tolerably (you do hear a slight clicking sound about once per second if there is any playout time above a few hundred ms). To patch the kernel you need to: adb -k -w /vmunix /dev/mem audio_4231_bsize/W 0t1200 (to patch the running kernel) audio_4231_bsize?W 0t1200 (to patch kernel file on disk) $q For Solaris 2.3: Apply patch 101836-02. If you have previously applied the ms2 patch you will find it will not install (Sun cocked up the version numbering), so you need to do it manually by copying the audiocs driver file in the patch into the /kernel/drv directory. For Solaris 2.4: I don't know if there any patches available (I suspect that there ought to be). PS I will add that if you do not have ready access to the patches mentioned above, then you can pick them up from ftp://ftp.ed.ac.uk/pub/sun-fixes/. There are many patches in that directory so I do not recommend running 'dir'. The patches are named .tar.Z. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Fri Feb 10 13:42:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 01:39:49 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 01:39:26 -0800 Received: from cs.tut.fi by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 01:39:23 -0800 Received: from isosotka.cs.tut.fi (mit@isosotka.cs.tut.fi [130.230.17.14]) by cs.tut.fi (8.6.9/8.6.4) with ESMTP id LAA11820; Fri, 10 Feb 1995 11:42:27 +0200 From: Tsokkinen Mikko Received: (mit@localhost) by isosotka.cs.tut.fi (8.6.8/8.6.4) id LAA25334; Fri, 10 Feb 1995 11:42:37 +0200 Date: Fri, 10 Feb 1995 11:42:37 +0200 Message-Id: <199502100942.LAA25334@isosotka.cs.tut.fi> To: Ajit Thyagarajan Cc: mbone Subject: Re: starting mrouted - thanks (fwd) In-Reply-To: <9502092128.aa16907@beauregard.udel.edu> References: <199502091926.AA14221@jaspar.NSD.3Com.COM> <9502092128.aa16907@beauregard.udel.edu> Ajit Thyagarajan writes: > > No - if you are going to run an application on the machine which you > are tunnelling from, then the traffic belonging to that application > will appear on the corresponding interface. There is a proposal to > include support for a configuration where a tunneling machine acting > as a host does not have to forward traffic onto the interface. We'll > see if it can come out in the next release. I would love to see this feature implemented. It would also been lovely if this feature could be used with workstations wihout multicast capable interface (e.g. Workstation with only ATM Interface without multicast). I am no expert on this issue, but could some sort of pseudo-device (similar to loopback) be implemented in the kernel for multicast reflection? I have suggested this before, but no solution was found at that time. Today solution I have succesfully used in situations like this is a transceiver connected to a 1 feet Ethernet cable acting as a multicast "antenna" ;) Cheers Mikko Tsokkinen xxxxx Mit mit@cs.tut.fi "Duct tape is like the force... It has a light side, and a dark side, and it holds the universe together..." From list-mgr@ISI.EDU Fri Feb 10 02:51:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 02:51:40 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 02:51:21 -0800 Received: from uucp0.iij.ad.jp by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 02:51:18 -0800 Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.244.176.33]) by uucp0.iij.ad.jp (8.6.9+2.4Wb/3.3Wb-UUCP) with ESMTP id TAA12166 for <@uucp0.iij.ad.jp:mbone@isi.edu>; Fri, 10 Feb 1995 19:51:16 +0900 Received: from mewgate.mew.co.jp (mewgate.mew.co.jp [133.254.5.10]) by ns.iij.ad.jp (8.6.9+2.4Wb/3.3Wb-NS) with ESMTP id TAA28603 for <@uucp0.iij.ad.jp:mbone@isi.edu>; Fri, 10 Feb 1995 19:44:08 +0900 Received: from mewserv2.mew.co.jp ([133.254.7.11]) by mewgate.mew.co.jp (8.6.8+2.4Wb2/3.3W-mewgate-940715) with ESMTP id TAA29996 for ; Fri, 10 Feb 1995 19:44:06 +0900 Received: from gripen.ai.mew.co.jp (gripen.ai.mew.co.jp [133.254.10.74]) by mewserv2.mew.co.jp (8.6.8+2.4Wb2/3.3W-mewserv2) with SMTP id TAA23815 for ; Fri, 10 Feb 1995 19:44:05 +0900 Received: by gripen.ai.mew.co.jp (4.1/6.4J.6-ai_940425) id AA12547; Fri, 10 Feb 95 15:22:54 JST Date: Fri, 10 Feb 95 15:22:54 JST From: tomio@ai.mew.co.jp (Steve Madsen) Message-Id: <9502100622.AA12547@gripen.ai.mew.co.jp> To: mbone Subject: Thank you all for MBone FAQ information Everyone: Thanks to all who responded to my requests for MBone FAQ locations. Some of the people who responded include: James E. (Jed) Donnelley Masaki Hirabaru Paul Danset (responded more than once) Pavlin Ivanov Radoslavov (fellow gaijin) Gordon Joly Philip A. Jarvis (another fellow gaijin) There were other people who responded as well; thank you all again!! -- Steve Madsen, Research Engineer Tel: 011-81-6-908-6835 Virtual Reality R&D Lab, IS Center Fax: 011-81-6-900-2766 Matsushita Electric Works, Ltd. e-mail: tomio@ai.mew.co.jp 1048, Kadoma, Osaka 571 JAPAN $B$b$7$b!$$3$NJ8$rFI$a$J$+$C$?$i!$$"$s$^$j9q:]E*$J$d$D$8$c$J$$$@$m$&!%!%!%(B P.S. If anyone is interested, I will be happy to post the http and ftp url's which were given to me by the above helpful folks. Just send me e-mail directly. From list-mgr@ISI.EDU Thu Feb 9 22:18:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 06:18:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 06:18:38 -0800 Received: from frostbite-falls.uoregon.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 06:18:37 -0800 Received: (meyer@localhost) by frostbite-falls.uoregon.edu (8.6.9/8.6.5.Beta7) id GAA03932; Fri, 10 Feb 1995 06:18:33 -0800 Message-Id: <199502101418.GAA03932@frostbite-falls.uoregon.edu> X-Mailer: exmh version 1.5.3 12/28/94 To: "Cyndi M. Jung" Cc: mbone Subject: Re: Audio problems - need help In-Reply-To: cmj@nsd.3com.com's message of Thu, 09 Feb 1995 18:02:15 -0800. <199502100202.AA15290@jaspar.NSD.3Com.COM> X-Btw: ns.uoregon.edu is phloem.uoregon.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Feb 1995 06:18:33 -0800 From: "David M. Meyer 503/346-1747" Cyndi, I believe that what you are experiencing are the long lamented Sparc 5 audiocs driver problems. There is most likely no problem with any of the applications code that you have (e.g., vat, vic, etc). Sun has had a real hard time understanding what the problem was/is. Sun finally supplied Van with a SS5 and source enough to fix it. The code he returned to them was for the SunOS audiocs driver. I'm currently testing a Solaris 2.4 audiocs driver "derrived" from the code that Van supplied to Sun. I must say, the audiocs driver finally almost works right (thanks Van), and I am very encouraged. I know that Graeme Wood was working Sun from the SunOS side, so perhaps he can comment on that. Please let me know if you need additional information. Dave David M. Meyer Voice: +1-503-346-1747 Senior Network Engineer Pager: +1-503-342-9458 Office of University Computing Cellular: +1-503-954-1103 Computing Center FAX: +1-503-346-4397 University of Oregon Internet: meyer@ns.uoregon.edu 1225 Kincaid Eugene, OR 97403 From list-mgr@ISI.EDU Fri Feb 10 02:17:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 06:18:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 06:17:27 -0800 Received: from plains.NoDak.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 06:17:25 -0800 Received: by plains.NoDak.edu; Fri, 10 Feb 1995 08:17:22 -0600 From: "Dr. Ronald J. Vetter" Message-Id: <199502101417.AA21293@plains.NoDak.edu> Subject: Virtual Classrooms & MBone To: mbone Date: Fri, 10 Feb 1995 08:17:21 -0600 (CST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 771 Is anyone using MBone in the form of a virtual classroom? That is, using it to teach a course (or courses) over the Internet? The requirements of this setting force certain contraints on applications (see IEEE COMPTUER, Hot Topics, Jan 1995 for a brief discussion of what I am interested in). Send all replies directly to me. I will post if there is sufficient interest and response. Thanks, Ron -- Dr. Ronald J. Vetter, rvetter@plains.nodak.edu Computer Science Department Phone: (701) 231-7084 IACC Building, Room 258 Fax: (701) 231-8255 North Dakota State University Fargo, North Dakota 58105-5164 Personal WWW URL - http://www.cs.ndsu.nodak.edu/faculty/rvetter/index.html From list-mgr@ISI.EDU Fri Feb 10 02:02:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 07:02:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 07:02:22 -0800 Received: from sgigate.SGI.COM by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 07:02:20 -0800 Received: from mistral.detroit.sgi.com (mistral.detroit.sgi.com [192.48.202.44]) by sgigate.sgi.com (940519.SGI.8.6.9/8.6.4) with ESMTP id HAA28431; Fri, 10 Feb 1995 07:02:19 -0800 Received: by mistral.detroit.sgi.com (940816.SGI.8.6.9/930416.SGI) for mbone@ISI.EDU id KAA09318; Fri, 10 Feb 1995 10:02:13 -0800 From: "Jeffrey M. Feierfeil" Message-Id: <9502101002.ZM9316@mistral.detroit.sgi.com> Date: Fri, 10 Feb 1995 10:02:13 -0800 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: mbone Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Please Unsubscribe me from the MBONE distribution. firefly@mistral.detroit.sgi.com Thank you. Jeff From list-mgr@ISI.EDU Fri Feb 10 00:02:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 08:02:54 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 08:02:43 -0800 Received: from frostbite-falls.uoregon.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 08:02:42 -0800 Received: (meyer@localhost) by frostbite-falls.uoregon.edu (8.6.9/8.6.5.Beta7) id IAA04259; Fri, 10 Feb 1995 08:02:36 -0800 Message-Id: <199502101602.IAA04259@frostbite-falls.uoregon.edu> X-Mailer: exmh version 1.5.3 12/28/94 To: "Dr. Ronald J. Vetter" Cc: mbone Subject: Re: Virtual Classrooms & MBone In-Reply-To: rvetter@plains.nodak.edu's message of Fri, 10 Feb 1995 08:17:21 -0600. <199502101417.AA21293@plains.NoDak.edu> X-Btw: ns.uoregon.edu is phloem.uoregon.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Feb 1995 08:02:35 -0800 From: "David M. Meyer 503/346-1747" Ack. Seems to be my day. We've used MBONE extensively to teach an astronomy class here at the UO (obligatory web comment: in conjunction with materials accessiable via the web). Dave From list-mgr@ISI.EDU Fri Feb 10 16:08:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 08:09:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 08:08:41 -0800 Received: from fenris.hiof.no by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 08:08:36 -0800 Received: from abdallah.hiof.no by fenris.hiof.no with SMTP (PP) id <10059-0@fenris.hiof.no>; Fri, 10 Feb 1995 17:08:20 +0100 Received: by abdallah.hiof.no (5.0/SMI-SVR4) id AA02958; Fri, 10 Feb 1995 16:08:07 +0000 Date: Fri, 10 Feb 1995 16:08:06 +0000 (GMT) From: Borre Ludvigsen Subject: Re: Virtual Classrooms & MBone To: "Dr. Ronald J. Vetter" Cc: mbone In-Reply-To: <199502101417.AA21293@plains.NoDak.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1060 Yes, here i Norway regular courses are being offered over the Mbone - see http://munin.uio.no./ with some inglish text on http://mice.uio.no/ - questions to munin@usit.uio.no. - Barre Ludvigsen On Fri, 10 Feb 1995, Dr. Ronald J. Vetter wrote: > Is anyone using MBone in the form of a virtual classroom? > That is, using it to teach a course (or courses) over the > Internet? The requirements of this setting force certain > contraints on applications (see IEEE COMPTUER, Hot Topics, > Jan 1995 for a brief discussion of what I am interested in). > > Send all replies directly to me. I will post if there is > sufficient interest and response. Thanks, Ron > -- > Dr. Ronald J. Vetter, rvetter@plains.nodak.edu > Computer Science Department Phone: (701) 231-7084 > IACC Building, Room 258 Fax: (701) 231-8255 > North Dakota State University > Fargo, North Dakota 58105-5164 > > Personal WWW URL - http://www.cs.ndsu.nodak.edu/faculty/rvetter/index.html > > From list-mgr@ISI.EDU Fri Feb 10 07:19:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 09:23:20 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 09:22:55 -0800 Received: from home.merit.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 09:22:53 -0800 Received: from localhost (ljb@localhost) by home.merit.edu (8.6.9/merit-2.0) with SMTP id MAA11924; Fri, 10 Feb 1995 12:19:53 -0500 Message-Id: <199502101719.MAA11924@home.merit.edu> To: Graeme.Wood@ucs.ed.ac.uk Cc: "Cyndi M. Jung" , mbone Subject: Re: Audio problems - need help In-Reply-To: Your message of "Fri, 10 Feb 1995 09:22:18 GMT." Date: Fri, 10 Feb 1995 12:19:53 -0500 From: "Larry J. Blunk" > You need to apply the following patches: 102161-01 and 101508-07. Once > you have done that I have found that setting the kernel variable > audio_4231_bsize to 1200 will make the audio device work tolerably (you > do hear a slight clicking sound about once per second if there is any > playout time above a few hundred ms). To patch the kernel you need to: > > adb -k -w /vmunix /dev/mem > audio_4231_bsize/W 0t1200 (to patch the running kernel) > audio_4231_bsize?W 0t1200 (to patch kernel file on disk) > $q > Just for the record, there is now a 102161-02 patch out. Although it just seems to add a fix for some esoteric problem with ShowMe. I'd recommend ftp.cs.columbia.edu for those looking for a good up-to-date patch site. -Larry Blunk Merit Network, Inc. From list-mgr@ISI.EDU Fri Feb 10 04:47:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 12:50:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 12:50:13 -0800 Received: from python.CS.ORST.EDU by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 12:50:09 -0800 Received: from trillium.CS.ORST.EDU (trillium.CS.ORST.EDU [128.193.36.2]) by python.CS.ORST.EDU (8.6.9/8.6.9) with SMTP id MAA29486; Fri, 10 Feb 1995 12:49:54 -0800 Message-Id: <199502102049.MAA29486@python.CS.ORST.EDU> X-Authentication-Warning: python.CS.ORST.EDU: Host trillium.CS.ORST.EDU didn't use HELO protocol To: "David M. Meyer 503/346-1747" Cc: "Dr. Ronald J. Vetter" , mbone Subject: Re: Virtual Classrooms & MBone In-Reply-To: Your message of Fri, 10 Feb 1995 08:02:35 PST. <199502101602.IAA04259@frostbite-falls.uoregon.edu> Date: Fri, 10 Feb 1995 12:47:40 -0800 From: (John Sechrest) -------- "David M. Meyer 503/346-1747" writes: % Ack. Seems to be my day. We've used MBONE extensively to % teach an astronomy class here at the UO (obligatory web comment: % in conjunction with materials accessiable via the web). And to follow up on some of UofO's work, there is the NERO project that UofO, OSU, PSU, OHSU, OCATE and OGI are part of which is focused on that specific task Desktop to desktop instruction See our web reference at http://www.nero.net ----- John Sechrest . Helping people use Executive Director . computers and Internet Computer Science Outreach . more effectively 303 Dearborn Hall . Oregon State University . Internet: sechrest@cs.orst.edu Corvallis Oregon 97331 . (503) 737-5562 . http://www.csos.orst.edu/ From list-mgr@ISI.EDU Fri Feb 10 10:23:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 18:26:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 18:24:19 -0800 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 10 Feb 1995 18:24:18 -0800 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA01869 (5.65c/IDA-1.4.4nsd for ); Fri, 10 Feb 1995 18:24:13 -0800 Received: by jaspar.NSD.3Com.COM id AA18416 (5.65c/IDA-1.4.4-910730 for mbone@isi.edu); Fri, 10 Feb 1995 18:23:21 -0800 Date: Fri, 10 Feb 1995 18:23:21 -0800 From: "Cyndi M. Jung" Message-Id: <199502110223.AA18416@jaspar.NSD.3Com.COM> To: mbone Subject: audio problems - getting closer We got the audio patches for the SS5 (thanks for all the help, from several people), and installed only the 102161-02 patch and set the audio_4231_bsize to 1200. It is much better, but seems to lose synch(?) just after a pause in the audio stream. Like when a question is asked, when the answer is given it is garbled, or when the current speaker pauses to breathe (or think), when they continue, their voice is garbled. As before, fiddling with the window straightens it out. Fortunately, it doesn't require the careful fiddling as before the patch, only a little fiddling just as the sound picks up again (touch the corner of the window and adjust the size slightly). I've tried both 1200 and 160 byte audio buffers. Any other hot tips? Give up and get a different machine? Is anybody using the SparcStation5 without these audio problems? Thanks, Cyndi From list-mgr@ISI.EDU Mon Feb 13 05:48:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 12 Feb 1995 15:50:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 12 Feb 1995 15:48:55 -0800 Received: from octavia.anu.edu.au by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 12 Feb 1995 15:48:52 -0800 Received: by octavia.anu.edu.au (4.1/SMI-4.1) id AA10856; Mon, 13 Feb 95 10:48:47 EST Date: Mon, 13 Feb 95 10:48:47 EST From: markus@octavia.anu.edu.au (Markus Buchhorn) Message-Id: <9502122348.AA10856@octavia.anu.edu.au> To: mbone Subject: Re: Audio problems - need help > For Solaris 2.4: > > I don't know if there any patches available (I suspect that there ought > to be). There is a small audio patch related to 'pops': 102037-01. I must say that for the most part our SS5 with Solaris 2.4 has very nice audio from vat *except* after any long-ish (technical term, that :-) ) pause it briefly (<3 sec) garbles the sound somewhat, but comes good again of it's own volition - no need to resize windows or jiggle sliders. I haven't had a chance to test other audio tools yet (xcdplayer and ShowMe). Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] From list-mgr@ISI.EDU Sun Feb 12 17:22:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 12 Feb 1995 17:24:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 12 Feb 1995 17:22:50 -0800 Received: from mail0.iij.ad.jp by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 12 Feb 1995 17:22:47 -0800 Received: from uucp0.iij.ad.jp (uucp0.iij.ad.jp [192.244.176.51]) by mail0.iij.ad.jp (8.6.9+2.4Wb/3.3W9-MAIL) with ESMTP id KAA02240 for ; Mon, 13 Feb 1995 10:22:41 +0900 Received: from mewgate.mew.co.jp (mewgate.mew.co.jp [133.254.5.10]) by uucp0.iij.ad.jp (8.6.9+2.4Wb/3.3W9-UUCP) with ESMTP id KAA18000 for <@uucp0.iij.ad.jp:mbone@isi.edu>; Mon, 13 Feb 1995 10:22:40 +0900 Received: from mewserv2.mew.co.jp ([133.254.7.11]) by mewgate.mew.co.jp (8.6.8+2.4Wb2/3.3W-mewgate-940715) with ESMTP id KAA29872 for ; Mon, 13 Feb 1995 10:22:39 +0900 Received: from gripen.ai.mew.co.jp (gripen.ai.mew.co.jp [133.254.10.74]) by mewserv2.mew.co.jp (8.6.8+2.4Wb2/3.3W-mewserv2) with SMTP id KAA12406 for ; Mon, 13 Feb 1995 10:22:39 +0900 Received: by gripen.ai.mew.co.jp (4.1/6.4J.6-ai_940425) id AA14216; Mon, 13 Feb 95 10:10:13 JST Date: Mon, 13 Feb 95 10:10:13 JST From: tomio@ai.mew.co.jp (Steve Madsen) Message-Id: <9502130110.AA14216@gripen.ai.mew.co.jp> To: mbone Subject: The FAQ locations Everyone: I received several requests for all the MBone FAQ and other goodies that I received, so I decided to post them that all may benefit. Vendors http://www.eit.com/techinfo/mbone/vendors.html">http://www.eit.com/ techinfo/mbone/vendors.html rem-conf archives are WAIS http//:www.es.net/pub/mailing-lists/mail-archive/rem-conf/">http//: www.es.net/pub/mailing-lists/mail-archive/rem-conf/ rem-conf and mbone list archives gopher://nic.es.net/11/pub/mailing-lists/mail-archive">gopher://nic .es.net/11/pub/mailing-lists/mail-archive Anne Marie Fleming, an mbone user http://www.psy.gla.ac.uk/staff/annemari.html">http://www.psy.gla.ac .uk/staff/annemari.html Math over the internet http://www.rrz.uni-koeln.de/themen/Computeralgebra/OpenMath">http:/ /www.rrz.uni-koeln.de/themen/Computeralgebra/OpenMath Michael R. Macedonia and Donald P. Brutzman "MBone Provides Audio and Video Across the Internet" ftp://131.120.1.13/pub/i3la/mbone.ps">ftp://131.120.1.13/pub/i3la/m bone.ps ftp://131.120.1.13/pub/i3la/mbone.txt">ftp://131.120.1.13/pub/i3la/ mbone.txt ftp://131.120.1.13/pub/i3la/mbone.html">ftp://131.120.1.13/pub/i3la /mbone.html Michael R. Macedonia and Donald P. Brutzman
Pointers to additional resources ftp://131.120.1.13/pub/mosaic/mbone.html">ftp://131.120.1.13/pub/mo saic/mbone.html Alternate FAQ place (abbreviated path) http://www.eit.com/techinfo/mbone/">http://www.eit.com/techinfo/mbo ne/ MBone FAQ http://www.research.att.com/mbone-faq.html">http://www.research.att .com/mbone-faq.html There is a good page at: http://www.cl.com.ac.uk/mbone/">http://www.cl.com.ac.uk/mbone/ Some useful information, including about MBONE in Japan. http://tokuda-www.cs.titech.ac.jp/~pavlin/multicast/">http://tokuda -www.cs.titech.ac.jp/~pavlin/multicast/ FAQ and a lot more in: http://www.cs.ucl.ac.uk/mice/mice-nsc/">http://www.cs.ucl.ac.uk/mic e/mice-nsc/ The English MBone FAQ http://www.eit.com/techinfo/mbone/mbone.html">http://www.eit.com/te chinfo/mbone/mbone.html FAQ (Japanese, ftp site) ftp://ftp.nic.ad.jp/pub/jepg-ip/mbone-jp-intro.txt">ftp.nic.ad.jp:p ub/jepg-ip/mbone-jp-intro.txt MBone contact database http://www.psc.edu/~mathis/contacts.html">http://www.psc.edu/~mathi s/contacts.html MBone contact database (FTP site) ftp://ftp.psc.edu/pub/mbone/contacts.txt">ftp://ftp.psc.edu/pub/mbo ne/contacts.txt First International Workshop on Intelligence and Multimodality in Multimedia Interfaces, Edinburgh, July 13-14, 1995. http://www.cogsci.ed.ac.uk/~john/IMMI_call/index.html">http://www.c ogsci.ed.ac.uk/~john/IMMI_call/index.html hipparch project (INRIA, SICS, UCL, UTS) http://www.cs.ucl.ac.uk/people/jon/hipparch/hipparch.html">http://w ww.cs.ucl.ac.uk/people/jon/hipparch/hipparch.html rebroadcast of the Energy Research Supercomputing Users Group http://www.nersc.gov/doc/Quick_Help/ERSUG/ersug.html">http://www.ne rsc.gov/doc/Quick_Help/ERSUG/ersug.html SuperJANET Video Conferencing http://strat.ucs.ed.ac.uk/bookpage.html">http://strat.ucs.ed.ac.uk/ bookpage.html the MBone online diary http://www.uq.oz.au/mbone/diary/diary.html">http://www.uq.oz.au/mbo ne/diary/diary.html MBone Global Agenda http://www.cilea.it/MBone/agenda.html">http://www.cilea.it/MBone/ag enda.html Stuff for vat audio record/playback ftp://ftp.ucs.ed.ac.uk/pub/videoconference/vat/vat_nv_record.tar.Z" >ftp://ftp.ucs.ed.ac.uk/pub/videoconference/vat/vat_nv_record.tar.Z -- Steve Madsen, Research Engineer Tel: 011-81-6-908-6835 Virtual Reality R&D Lab, IS Center Fax: 011-81-6-900-2766 Matsushita Electric Works, Ltd. e-mail: tomio@ai.mew.co.jp 1048, Kadoma, Osaka 571 JAPAN $B$b$7$b!$$3$NJ8$rFI$a$J$+$C$?$i!$$"$s$^$j9q:]E*$J$d$D$8$c$J$$$@$m$&!%!%!%(B From list-mgr@ISI.EDU Sun Feb 12 17:33:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 12 Feb 1995 17:35:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 12 Feb 1995 17:33:45 -0800 Received: from mail0.iij.ad.jp by venera.isi.edu (5.65c/5.61+local-20) id ; Sun, 12 Feb 1995 17:33:43 -0800 Received: from uucp0.iij.ad.jp (uucp0.iij.ad.jp [192.244.176.51]) by mail0.iij.ad.jp (8.6.9+2.4Wb/3.3W9-MAIL) with ESMTP id KAA02878 for ; Mon, 13 Feb 1995 10:33:41 +0900 Received: from mewgate.mew.co.jp (mewgate.mew.co.jp [133.254.5.10]) by uucp0.iij.ad.jp (8.6.9+2.4Wb/3.3W9-UUCP) with ESMTP id KAA18923 for <@uucp0.iij.ad.jp:mbone@isi.edu>; Mon, 13 Feb 1995 10:33:37 +0900 Received: from mewserv2.mew.co.jp ([133.254.7.11]) by mewgate.mew.co.jp (8.6.8+2.4Wb2/3.3W-mewgate-940715) with ESMTP id KAA00175 for ; Mon, 13 Feb 1995 10:33:36 +0900 Received: from gripen.ai.mew.co.jp (gripen.ai.mew.co.jp [133.254.10.74]) by mewserv2.mew.co.jp (8.6.8+2.4Wb2/3.3W-mewserv2) with SMTP id KAA12663 for ; Mon, 13 Feb 1995 10:33:35 +0900 Received: by gripen.ai.mew.co.jp (4.1/6.4J.6-ai_940425) id AA14241; Mon, 13 Feb 95 10:21:09 JST Date: Mon, 13 Feb 95 10:21:09 JST From: tomio@ai.mew.co.jp (Steve Madsen) Message-Id: <9502130121.AA14241@gripen.ai.mew.co.jp> To: mbone Subject: The FAQ locations (this replaces the previous accidental post) (Whoops, sorry about that last post--wasn't quite finished editing the list, and hit the wrong control sequence) Everyone: I received several requests for all the MBone FAQ and other goodies that I received, so I decided to post them that all may benefit. I culled most of the blantantly non-MBone stuff from the original source, so most of this should be fairly useful. MBONE RELATED FAQ AND OTHER INFORMATION SOURCES ----------------------------------------------- Vendors http://www.eit.com/techinfo/mbone/vendors.html rem-conf archives are WAIS http//:www.es.net/pub/mailing-lists/mail-archive/rem-conf/ rem-conf and mbone list archives gopher://nic.es.net/11/pub/mailing-lists/mail-archive Michael R. Macedonia and Donald P. Brutzman "MBone Provides Audio and Video Across the Internet" ftp://131.120.1.13/pub/i3la/mbone.ps ftp://131.120.1.13/pub/i3la/mbone.txt ftp://131.120.1.13/pub/i3la/mbone.html Pointers to additional resources ftp://131.120.1.13/pub/mosaic/mbone.html Alternate FAQ place (abbreviated path) http://www.eit.com/techinfo/mbone/ MBone FAQ http://www.research.att.com/mbone-faq.html There is a good page at: http://www.cl.com.ac.uk/mbone/ Some useful information, including about MBONE in Japan. http://tokuda-www.cs.titech.ac.jp/~pavlin/multicast/ FAQ and a lot more in: http://www.cs.ucl.ac.uk/mice/mice-nsc/ The English MBone FAQ http://www.eit.com/techinfo/mbone/mbone.html FAQ (Japanese, ftp site) ftp://ftp.nic.ad.jp/pub/jepg-ip/mbone-jp-intro.txt MBone contact database http://www.psc.edu/~mathis/contacts.html MBone contact database (FTP site) ftp://ftp.psc.edu/pub/mbone/contacts.txt hipparch project (INRIA, SICS, UCL, UTS) http://www.cs.ucl.ac.uk/people/jon/hipparch/hipparch.html SuperJANET Video Conferencing http://strat.ucs.ed.ac.uk/bookpage.html the MBone online diary http://www.uq.oz.au/mbone/diary/diary.html MBone Global Agenda http://www.cilea.it/MBone/agenda.html Stuff for vat audio record/playback ftp://ftp.ucs.ed.ac.uk/pub/videoconference/vat/vat_nv_record.tar.Z -- Steve Madsen, Research Engineer Tel: 011-81-6-908-6835 Virtual Reality R&D Lab, IS Center Fax: 011-81-6-900-2766 Matsushita Electric Works, Ltd. e-mail: tomio@ai.mew.co.jp 1048, Kadoma, Osaka 571 JAPAN $B$b$7$b!$$3$NJ8$rFI$a$J$+$C$?$i!$$"$s$^$j9q:]E*$J$d$D$8$c$J$$$@$m$&!%!%!%(B From list-mgr@ISI.EDU Mon Feb 13 13:49:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 01:48:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 01:46:20 -0800 Received: from cs.tut.fi by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 01:46:18 -0800 Received: from isosotka.cs.tut.fi (mit@isosotka.cs.tut.fi [130.230.17.14]) by cs.tut.fi (8.6.9/8.6.4) with ESMTP id LAA16047; Mon, 13 Feb 1995 11:49:41 +0200 From: Tsokkinen Mikko Received: (mit@localhost) by isosotka.cs.tut.fi (8.6.8/8.6.4) id LAA09816; Mon, 13 Feb 1995 11:49:52 +0200 Date: Mon, 13 Feb 1995 11:49:52 +0200 Message-Id: <199502130949.LAA09816@isosotka.cs.tut.fi> To: Ajit Thyagarajan Cc: mbone Subject: Re: Upgrading to mrouted V3.3 In-Reply-To: <9501270140.aa05140@malarky.udel.edu> References: <9501270140.aa05140@malarky.udel.edu> Ajit Thyagarajan writes: >Please look int ftp.udel.edu:/pub/people/ajit/ for ipmulticast distribution >and installation instructions. I applied the patches for 3.3 today, a found a little bug from installation script. The MCAST_INSTALL script is bit broken, if it cannot find patch from "regular" place and it asks for it, the echo -n on line 83 dies and script stops because \"patch\" escape is not understood, perhaps single quotes 'patch' would suffice and could be fixed for next release? uname -a SunOS esello 4.1.3_U1 2 sun4m Cheers Mikko Tsokkinen xxxxx Mit mit@cs.tut.fi "Duct tape is like the force... It has a light side, and a dark side, and it holds the universe together..." From list-mgr@ISI.EDU Mon Feb 13 14:54:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 05:20:54 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 05:20:15 -0800 Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 05:20:13 -0800 Received: from ursa (actually ursa.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Mon, 13 Feb 1995 14:14:34 +0100 Date: Mon, 13 Feb 1995 13:54:48 +0100 (MET) From: Bernd Deffner Sender: deffner@fokus.gmd.de Reply-To: Bernd Deffner Subject: Announcement: TUBKOM Kolloquium over MBONE To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hello to everybody! On Wed Feb 15 14.15 MET we transmit the following presentation over MBONE: "High Performance Scalable Video Servers and Their Impact on the Network" by Prof. Dr. E. Biersack, Institute Eurecom, Sophia Antipolis Cedex, France. You can retrieve further information about this presentation at: http://www.prz.tu-berlin.de/~rainer/tubkom/kolloquium/tubkom-colloqium.html We transmit audio with NeVoT and video with vic. If you are interested in this presentation please send mail to deffner@fokus.gmd.de and include some information about your geographical location so that we can set the ttl of our session accordingly. Bernd Deffner From list-mgr@ISI.EDU Mon Feb 13 02:42:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 06:43:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 06:42:39 -0800 Received: from phoebus (phoebus.aps.anl.gov) by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 06:42:35 -0800 Received: from medusa.aps.anl.gov.anl.gov by phoebus (5.0/SMI-SVR4) id AA11393; Mon, 13 Feb 1995 08:42:34 -0600 Date: Mon, 13 Feb 1995 08:42:34 -0600 From: hoffberg@aps.anl.gov (Mike Hoffberg) Message-Id: <9502131442.AA11393@phoebus> Received: by medusa.aps.anl.gov.anl.gov (4.1/SMI-4.1) id AA02299; Mon, 13 Feb 95 08:42:29 CST To: mbone In-Reply-To: "Cyndi M. Jung"'s message of Fri, 10 Feb 1995 18:23:21 -0800 <199502110223.AA18416@jaspar.NSD.3Com.COM> Subject: audio problems - getting closer Content-Length: 482 I just saw in the Chicago Tribune that the Grammies will be broadcast over the Internet, is that going to take place over the MBONE? Will the commercials be cut? Can I but commercial time during the broadcast? MIKE Michael Hoffberg /.\ Argonne ELEC ENGR, 3 yrs exp, hoffberg@phebos.aps.anl.gov // \\ National BSEE (5/92), MSEE (8/95) mike@anl.gov //_O_\\ Lab Resume and references Standard Disclaimer Applies /__| |__\ on request From list-mgr@ISI.EDU Mon Feb 13 16:58:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 09:00:54 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 08:59:59 -0800 Received: from swan.cl.cam.ac.uk by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 08:59:44 -0800 Received: from labes.cl.cam.ac.uk (user pb (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Mon, 13 Feb 1995 16:59:02 +0000 X-Mailer: exmh version 1.5.3+cl+pgp 94/12/28 To: rem-conf@es.net, mbone Cc: Ross.Anderson@cl.cam.ac.uk Subject: JIPS Mbone transmission 95/2/14 16:15-17:15UTC (cl.cam.ac.uk Security) Sendbreakwidth: 85 Sendwidth: 72 X-Uri: X-Face: &@N3QE9h|>f`igFCkZ'a1`z=nNLXb}k>H(79G"V?@!&*yn)uhPBctF1vc}LD'{OA%$bsX+l [wN,I^G8kKj2NFxQrr@1C4QBC]hq5-%ZkV,^Zl/qE<0`zCQ1nM+]-N<^WG[H)]?d)A:L9AF gOU[BjbaY)uBAMz}h!fm^O0# Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Feb 1995 16:58:56 +0000 From: Piete Brooks Message-Id: <"swan.cl.cam.:010840:950213165909"@cl.cam.ac.uk> We shall be transmitting the Security Group's seminar as a "low key" transmission (without anyone manning the camera, etc) for Security groups within ac.uk, but if anyone outside JIPS wants the TTL raised, please let me know. NAME: David J C MacKay of the Mullard Radio Astronomy Observatory DATE: Tuesday 14th Feb a995 at 4.15pm (16:15 UTC) TITLE: A Free Energy Minimization Framework for Inference Problems in Modulo 2 Arithmetic This paper studies the task of inferring a binary vector s given noisy observations of the binary vector t = A s mod 2, where A is an M times N binary matrix. This task arises in correlation attack on a class of stream ciphers and in other decoding problems. The unknown binary vector is replaced by a real vector of probabilities that are optimized by variational free energy minimization. The derived algorithms converge in computational time of order between w_{A} and N w_{A}, where w_{A} is the number of 1s in the matrix A, but convergence to the correct solution is not guaranteed. Applied to error correcting codes based on sparse matrices A, these algorithms give a system with empirical performance comparable to that of BCH and Reed-Muller codes. Applied to the inference of the state of a linear feedback shift register given the noisy output sequence, the algorithms offer a principled version of Meier and Staffelbach's (1989) algorithm B, thereby resolving the open problem posed at the end of their paper. The algorithms presented here appear to give superior performance. Short version submitted to Electronic Letters: postscript (53K). Short version including pseudocode appendix: postscript (61K). Long version: (to appear in Proceedings of 1994 K.U. Leuven Workshop on Cryptographic Algorithms) postscript (101K). This seminar will be multicast (audio and video) on the mbone as part of our multimedia test programme. Further information is available at http://www.cl.cam.ac.uk/mbone/#cl. From list-mgr@ISI.EDU Mon Feb 13 02:11:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 10:13:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 10:13:32 -0800 Received: from eitech.eit.COM by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 10:13:31 -0800 Received: from collage ([192.100.58.17]) by eitech.eit.com (4.1/SMI-4.1) id AA07055; Mon, 13 Feb 95 10:11:44 PST Date: Mon, 13 Feb 95 10:11:44 PST From: vinay@eit.COM (Vinay Kumar) Message-Id: <9502131811.AA07055@eitech.eit.com> To: mit@cs.tut.fi Subject: Re: Upgrading to mrouted V3.3 Cc: mbone There are some instructions for installing multicast-3.3 distribution at, http://www.eit.com/techinfo/mbone/mbone.faq.html#25 and http://www.eit.com/techinfo/mbone/whats-new.html --- Vinay Kumar vinay@eit.com > From list-mgr@ISI.EDU Mon Feb 13 02:49:47 1995 > From: Tsokkinen Mikko > Date: Mon, 13 Feb 1995 11:49:52 +0200 > To: Ajit Thyagarajan > Cc: mbone@ISI.EDU > Subject: Re: Upgrading to mrouted V3.3 > Content-Length: 723 > > Ajit Thyagarajan writes: > >Please look int ftp.udel.edu:/pub/people/ajit/ for ipmulticast distribution > >and installation instructions. > > I applied the patches for 3.3 today, a found a little bug from > installation script. > > The MCAST_INSTALL script is bit broken, if it cannot find patch from > "regular" place and it asks for it, the echo -n on line 83 dies and > script stops because \"patch\" escape is not understood, perhaps > single quotes 'patch' would suffice and could be fixed for next > release? > > uname -a > SunOS esello 4.1.3_U1 2 sun4m > > Cheers > Mikko Tsokkinen xxxxx Mit mit@cs.tut.fi > > "Duct tape is like the force... It has a light side, and a dark side, > and it holds the universe together..." > From list-mgr@ISI.EDU Mon Feb 13 10:18:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 12:20:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 12:19:42 -0800 Received: from PO5.ANDREW.CMU.EDU by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 12:19:41 -0800 Received: (from postman@localhost) by po5.andrew.cmu.edu (8.6.9/8.6.9) id PAA25963 for mbone@isi.edu; Mon, 13 Feb 1995 15:19:35 -0500 Received: via switchmail; Mon, 13 Feb 1995 15:19:33 -0500 (EST) Received: from pcs11.andrew.cmu.edu via qmail ID ; Mon, 13 Feb 1995 15:18:09 -0500 (EST) Received: from pcs11.andrew.cmu.edu via qmail ID ; Mon, 13 Feb 1995 15:18:08 -0500 (EST) Received: from mms.4.60.Jan.26.1995.18.43.47.sun4c.411.EzMail.Client.2.0.CUILIB.3.45.SNAP.NOT.LINKED.pcs11.andrew.cmu.edu.sun4c.411 via MS.5.6.pcs11.andrew.cmu.edu.sun4c_411; Mon, 13 Feb 1995 15:18:07 -0500 (EST) Message-Id: <0jDvtzm00iUxM6ZV5e@andrew.cmu.edu> Date: Mon, 13 Feb 1995 15:18:07 -0500 (EST) From: Matthew G Newcomb To: mbone Subject: PC video conferencing Cc: G'day, Can anyone point me towards a video conferencing system that runs on the PC? (Not CuSeeMe for windows as it really doesn't fit the bill as it doesn't yet include audio support) Or would it be best to install something like linux/netbsd/freebsd and go from there? Thanks. Matt Newcomb From list-mgr@ISI.EDU Mon Feb 13 10:44:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 12:44:47 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 12:44:24 -0800 Received: from pern.cc.purdue.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 12:44:22 -0800 Received: from localhost (localhost [127.0.0.1]) by pern.cc.purdue.edu (8.6.9/8.6.9) with SMTP id PAA27441; Mon, 13 Feb 1995 15:44:20 -0500 Message-Id: <199502132044.PAA27441@pern.cc.purdue.edu> X-Authentication-Warning: pern.cc.purdue.edu: Host localhost didn't use HELO protocol To: mbone Cc: "Scott M. Ballew" Reply-To: smb@pern.cc.purdue.edu Subject: Out-of-range metrics Date: Mon, 13 Feb 1995 15:44:20 -0500 From: smb@pern.cc.purdue.edu ("Scott M. Ballew") Good afternoon! I'm hoping someone out there can help me. Our current campus MBONE tunnel is coming into a version 2.2 mrouter. I have been experimenting with having our lead Cisco 7000 router, running IOS 10.2(2), take over this tunnel, and then use PIM where possible to propagate the MBONE on our campus network. My test setup is a tunnel from the mrouter (named Rukbat) to the 7000, and I have that working. However, my logs on the the mrouter are showing messages like: Feb 13 15:13:08 rukbat mrouted[3455]: warning - 128.210.253.6 reports out-of-range metric 64 for origin 150.166.46 Feb 13 15:15:27 rukbat mrouted[3455]: warning - 128.210.253.6 reports out-of-range metric 64 for origin 130.54.8 These are complaining about the 7000 (128.210.253.6). I want to resolve these messages before I rehome the campus tunnel to the 7000, because I'd like to be a good neighbor to my tunnel provider and not fill his logs with these messages. Does anyone know why I am getting these and how I might resolve this? Thanks, Scott M. Ballew Purdue Data Network From list-mgr@ISI.EDU Wed Feb 15 01:57:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 15:58:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 15:57:40 -0800 Received: from grace.waikato.ac.nz by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 15:57:38 -0800 Message-Id: <199502132357.AA07369@venera.isi.edu> Date: Tue, 14 Feb 95 12:57 +1300 From: Hamish Marson Subject: MBone tools for AIX 4.1 To: mbone X-Vms-To: in%"mbone@isi.edu" Greetings all... I have a copy of AIX 4.1 (With multicast built in) on my desk for a trial period, and want to get hold of some mbone tools to try it out (I have it currently running on my Sparc2, and want to compare the two). Can someone point me at sd/vic/vat etc for AIX 4.1 please? Do they exist? I can't find them on the WWW, for any flavour of AIX at all. TIA... hamish Marson. From list-mgr@ISI.EDU Mon Feb 13 08:30:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 16:33:09 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 16:30:59 -0800 Received: from gangrene.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 16:30:25 -0800 Received: from localhost.Berkeley.EDU by gangrene.berkeley.edu (8.6.8.1/1.33) id QAA05765; Mon, 13 Feb 1995 16:30:14 -0800 Message-Id: <199502140030.QAA05765@gangrene.berkeley.edu> To: mbone Subject: ultrix 4.4 / ipmulti3.3 patches Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=mysteryboxofun Date: Mon, 13 Feb 1995 16:30:14 -0800 From: Rob Robertson --mysteryboxofun Content-Type: text/plain Content-Description: Cover Letter Enclosed are source patches to the Ultrix 4.4 kernel to support ip multicast 3.3. This should be everything to enable the kernel. The user programs, such as mrouted, et al are not included, you need to get the ipmulti3.3-sunos413x.tar.Z distribution from the standard places. I'll make a binary distribution if people are interested, and someone tells me how to do it under uglix [what the hell is that data/*_data.c stuff?] Please let me know if it works for you, and any bugs or fixes you might stumble across. thanx, rob william robertson datakommunication&netwerkzervices uc berkeley rob@agate.berkeley.edu --mysteryboxofun Content-Type: text/plain Content-Description: Ultrix 4.4 Kernel / IP Multicast patch *** sys/io/netif/if_ln.c.orig Mon Feb 13 15:20:45 1995 --- sys/io/netif/if_ln.c Sat Feb 4 21:11:37 1995 *************** *** 1,5 **** --- 1,6 ---- #ifndef lint static char *sccsid = "@(#)if_ln.c 8.5 (ULTRIX) 11/17/93"; + /* plus MULTICAST 1.2 */ #endif lint /* *************** *** 173,178 **** --- 174,182 ---- * 6/2/89 Uttam Shikarpur * Add support for Ethernet packet filter * + * April 1989 Tony Mason Stanford + * Added IP Multicast support. + * * 9/21/88 U. Sinkewicz * Added locks for SMP. * *************** *** 576,582 **** ifp->lk_softc = &sc->lk_ln_softc; ifp->if_mtu = ETHERMTU; ifp->if_type = IFT_ETHER; ! ifp->if_flags |= IFF_BROADCAST | IFF_DYNPROTO | IFF_NOTRAILERS; ((struct arpcom *)ifp)->ac_ipaddr.s_addr = 0; /* --- 580,591 ---- ifp->lk_softc = &sc->lk_ln_softc; ifp->if_mtu = ETHERMTU; ifp->if_type = IFT_ETHER; ! #ifdef MULTICAST ! ifp->if_flags |= IFF_BROADCAST | IFF_DYNPROTO | IFF_NOTRAILERS ! | IFF_MULTICAST; ! #else ! ifp->if_flags |= IFF_BROADCAST | IFF_DYNPROTO | IFF_NOTRAILERS; ! #endif ((struct arpcom *)ifp)->ac_ipaddr.s_addr = 0; /* *************** *** 1289,1296 **** --- 1298,1307 ---- struct ctrreq *ctr = (struct ctrreq *)data; struct protosw *pr; struct ifaddr *ifa = (struct ifaddr *)data; + #ifndef MULTICAST int bitpos; /* top 6 bits of crc = bit in multicast mask */ u_short newmask[4]; /* new value of multicast address mask */ + #endif MULTICAST int j = -1, s, error=0; s = splimp(); *************** *** 1366,1374 **** --- 1377,1418 ---- } break; + #ifdef MULTICAST case SIOCDELMULTI: case SIOCADDMULTI: + /* + * Update our multicast list. + * (When compiled with "MULTICAST" defined, the higher-level + * multicast list routines in if_ether.c are used, instead + * of the original DEC code, below.) + */ + if(cmd == SIOCADDMULTI) { + if (lndebug>1) printf("SIOCADDMULTI "); + error = ether_addmulti(ifr, &sc->is_ac); + } + else { + if (lndebug>1) printf("SIOCDELMULTI "); + error = ether_delmulti(ifr, &sc->is_ac); + } + if (error == ENETRESET) { + /* + * Multicast list has changed; set the hardware + * filter accordingly. + */ + if (ifp->if_flags & IFF_RUNNING) { + lnrestart(ifp); + lninit(ifp->if_unit); + } else { + lnrestart(ifp); + } + error = 0; + } + break; + + #else + case SIOCDELMULTI: + case SIOCADDMULTI: smp_lock(&sc->lk_ln_softc, LK_RETRY); if (cmd == SIOCDELMULTI) { if (lndebug>1) printf("SIOCDELMULTI "); *************** *** 1468,1473 **** --- 1512,1518 ---- lnrestart(ifp); } break; + #endif MULTICAST case SIOCRDCTRS: case SIOCRDZCTRS: *************** *** 1502,1508 **** */ arpwhohas((struct arpcom *)ifp, &IA_SIN(ifa)->sin_addr); break; ! #endif default: if (pr=iffamily_to_proto(ifa->ifa_addr.sa_family)) { --- 1547,1553 ---- */ arpwhohas((struct arpcom *)ifp, &IA_SIN(ifa)->sin_addr); break; ! #endif INET default: if (pr=iffamily_to_proto(ifa->ifa_addr.sa_family)) { *************** *** 1655,1660 **** --- 1700,1706 ---- /* * Restart the Lance chip -- this routine is called: * - after changing the multicast address filter mask + * - after setting the if flags (in case IFF_PROMISC or IFF_ALLMULTI change) * - on any loopback mode state change * - on any error which disables the transmitter * - on all missed packet errors *************** *** 1672,1677 **** --- 1718,1727 ---- register char *initb = sc->initbaddr; register int i, pi; int s; + #ifdef MULTICAST + int bitpos; /* top 6 bits of crc = bit in multicast mask */ + u_short newmask[4]; /* new value of multicast address mask */ + #endif MULTICAST /* * stop the chip *************** *** 1722,1728 **** --- 1772,1852 ---- } } + #ifdef MULTICAST /* + * The MULTICAST option enables support for higher-level (e.g., IP) + * multicasting, and for the IFF_PROMISC and IFF_ALLMULTI interface + * flags. The code for setting the multicast hash filter has been + * moved here from lnioctl() in order to properly synchronize with + * the PROMISC and ALLMULTI flags. + */ + + sc->ln_initb.ln_mode &= ~LN_PROM; + for (i=0; i<4; i++) newmask[i] = 0x0000; + + if (ifp->if_flags & IFF_PROMISC) { + /* + * Enable promiscous reception mode. + */ + sc->ln_initb.ln_mode |= LN_PROM; + } + else if ( ifp->if_flags & IFF_ALLMULTI ) { + /* + * Turn on all 64 multicast hash bits. + */ + allmulti: for (i=0; i<4; i++) newmask[i] = 0xFFFF; + } + else { + /* + * Recalculate all current multimask crc/bits + * and reload multimask info. + * + * For each currently used multicast address, + * calculate CRC, save top 6 bits, load + * appropriate mask bit into newmask[i] + */ + struct ether_multi *enm; + struct ether_multistep step; + + ETHER_FIRST_MULTI(step, &sc->is_ac, enm); + while (enm != NULL) { + if (bcmp(enm->enm_addrlo, enm->enm_addrhi, 6) != 0) + /* + * We must listen to a range of multicast + * addresses. For now, just accept all + * multicasts, rather than trying to set + * only those filter bits needed to match + * the range. (At this time, the only use + * of address ranges is for IP multicast + * routing, for which the range is big + * enough to require all bits set.) + */ + goto allmulti; + + ln_docrc(enm->enm_addrlo, 0, sc); + bitpos = ((unsigned int)sc->ln_crc >> 26) & 0x3f; + + /* 0-15 */ + if (bitpos >= 0 && bitpos < 16) + newmask[0] |= (1 << (bitpos - 0)); + /* 16-31 */ + else if (bitpos < 32) + newmask[1] |= (1 << (bitpos - 16)); + /* 32-47 */ + else if (bitpos < 48) + newmask[2] |= (1 << (bitpos - 32)); + /* 48-63 */ + else if (bitpos < 64) + newmask[3] |= (1 << (bitpos - 48)); + + ETHER_NEXT_MULTI(step, enm); + } + } + for (i = 0; i < 4; i++) + sc->ln_initb.ln_multi_mask[i] = newmask[i] & 0xffff; + #endif MULTICAST + + /* * reload Lance with init block */ sc->lnsw->ln_cpyout(&sc->ln_initb,initb,sizeof(struct ln_initb),0); *************** *** 2141,2146 **** --- 2265,2280 ---- len -= sizeof(struct ether_header); } + #ifndef MULTICAST + /* + * I wonder if omitting this check is going to break anything? With + * the new multicast list structure, doing such a check on every + * incoming multicast packet would be quite expensive. Given that + * higher levels have to be able to recognize unwanted *broadcast* + * packets, they ought to be able to deal with unwanted *multicast* + * packets, right? + */ + if (!(sc->is_if.if_flags & IFF_PROMISC) ) { /* * Make sure our multicast address filter doesn't hand us *************** *** 2161,2166 **** --- 2295,2301 ---- } } } + #endif !MULTICAST sc->is_if.if_ipackets++; eptr->ether_type = ntohs((u_short)eptr->ether_type); *** sys/h/mbuf.h.orig Fri Sep 18 14:57:11 1992 --- sys/h/mbuf.h Sat Feb 4 21:11:38 1995 *************** *** 1,4 **** --- 1,5 ---- /* @(#)mbuf.h 8.1 (ULTRIX) 9/18/92 */ + /* plus MULTICAST 1.1 */ /************************************************************************ * * *************** *** 161,166 **** --- 162,172 ---- #define MT_OPT KM_OPT /* DECnet optional data */ #define MT_IFADDR KM_IFADDR /* interface address */ #define MT_ACCESS KM_ACCESS /* access control info */ + #define MT_IPMOPTS KM_IPMOPTS /* internet multicast options */ + #define MT_IPMADDR KM_IPMADDR /* internet multicast address */ + #define MT_IFMADDR KM_IFMADDR /* link-level multicast address */ + #define MT_MRTABLE KM_MRTABLE /* multicast routing tables */ + /* flags to m_get */ #define M_DONTWAIT KM_NOWAIT *** sys/h/kmalloc.h.orig Fri May 14 13:44:14 1993 --- sys/h/kmalloc.h Sat Feb 4 21:11:38 1995 *************** *** 1,5 **** --- 1,6 ---- /* @(#)kmalloc.h 8.3 (ULTRIX) 5/14/93 */ + /* plus MULTICAST 1.1 */ /* * Copyright (c) 1987 Regents of the University of California. * All rights reserved. The Berkeley software License Agreement *************** *** 23,28 **** --- 24,32 ---- * 31 Aug 90 paradis * Added KM_SPU * + * 91/05/29 Mark J. Steiglitz, Stanford + * IP Multicast modifications from Ultrix 3.1 to Ultrix 4.1 + * * 30 Dec 89 bp * Add state in flags specifically for internal usage * for pageout and sched. *************** *** 165,174 **** #define KM_VECTOR 41 /* vector data stuctures */ #define KM_WAN 42 /* x.25 */ #define KM_NOFILE 43 /* Overflow buffer for open file descriptors */ ! #define KM_FREE3 44 ! #define KM_FREE4 45 ! #define KM_FREE5 46 ! #define KM_FREE6 47 #define KM_FREE7 48 #define KM_FREE8 49 #define KM_FREE9 50 --- 169,178 ---- #define KM_VECTOR 41 /* vector data stuctures */ #define KM_WAN 42 /* x.25 */ #define KM_NOFILE 43 /* Overflow buffer for open file descriptors */ ! #define KM_IPMOPTS 44 /* internet multicast options */ ! #define KM_IPMADDR 45 /* internet multicast address */ ! #define KM_IFMADDR 46 /* link-level multicast address */ ! #define KM_MRTABLE 47 /* multicast routing tables */ #define KM_FREE7 48 #define KM_FREE8 49 #define KM_FREE9 50 *** sys/h/ioctl.h.orig Mon Feb 13 14:27:41 1995 --- sys/h/ioctl.h Mon Feb 13 14:33:28 1995 *************** *** 434,439 **** --- 434,447 ---- #define SIOCADDRT _IOW('r', 10, struct rtentry) /* Add route */ #define SIOCDELRT _IOW('r', 11, struct rtentry) /* Delete route */ + #define SIOCSETRTINFO _IOWR('r', 12, struct fullrtentry) /* change aux info */ + #define SIOCGETRTINFO _IOWR('r', 13, struct fullrtentry) /* read aux info */ + #define SIOCGETVIFCNT _IOWR('r', 20, struct sioc_vif_req)/* get vif pkt cnt */ + #define SIOCGETSGCNT _IOWR('r', 21, struct sioc_sg_req) /* get s,g pkt cnt */ + #ifdef RSVP_ISI + #define SIOCGETVIFINF _IOWR('r', 15, struct vif_conf) /* read m/c vifs */ + #endif RSVP_ISI + #define SIOCSIFADDR _IOW('i', 12, struct ifreq) /* Set ifnet ad.*/ #define SIOCGIFADDR _IOWR('i',13, struct ifreq) /* Get ifnet ad.*/ #define SIOCSIFDSTADDR _IOW('i', 14, struct ifreq) /* Set p-p addr.*/ *** sys/net/net/if.h.orig Tue Aug 3 08:57:00 1993 --- sys/net/net/if.h Sat Feb 4 21:11:37 1995 *************** *** 40,45 **** --- 40,52 ---- * (145) 15-Mar-92 Megan Gentry * I/O Enhancements from Chet - Increase queue size * + * * + * 91/05/29 Mark J. Steiglitz, Stanford + * IP Multicast modifications from Ultrix 3.1 to Ultrix 4.1 + * + * Tony Mason, Stanford University, 21-Mar-89 * + * Added IP Multicast changes * + * * Chran-Ham Chang 9-Nov-90 * Added structure to support FDDI read status * *************** *** 194,200 **** #define IFF_NOTRAILERS 0x20 /* avoid use of trailers */ #define IFF_RUNNING 0x40 /* resources allocated */ #define IFF_NOARP 0x80 /* no address resolution protocol */ - #define IFF_CANTCHANGE (IFF_BROADCAST | IFF_POINTOPOINT | IFF_RUNNING) #define IFF_PROMISC 0x100 /* receive all packets */ #define IFF_ALLMULTI 0x200 /* receive all multicast packets */ #define IFF_DYNPROTO 0x400 /* support dynamic proto dispatching */ --- 201,206 ---- *************** *** 203,208 **** --- 209,226 ---- #define IFF_802HDR 0x2000 /* 802 encapsulation */ #define IFF_PFCOPYALL 0x4000 /* pfilt gets packets to this host */ + #define IFF_MULTICAST 0x8000 /* supports multicast */ + /* + * The IFF_MULTICAST flag indicates that the network can support the + * transmission and reception of higher-level (e.g., IP) multicast packets. + * It is independent of hardware support for multicasting; for example, + * point-to-point links or pure broadcast networks may well support + * higher-level multicasts. + */ + + #define IFF_CANTCHANGE (IFF_BROADCAST | IFF_POINTOPOINT | IFF_RUNNING \ + | IFF_MULTICAST) + /* interface types for benefit of parsing media address headers */ #define IFT_OTHER 0x1 /* none of the following */ #define IFT_1822 0x2 /* old-style arpanet imp */ *** sys/net/net/raw_cb.h.orig Fri Sep 18 14:09:46 1992 --- sys/net/net/raw_cb.h Sat Feb 4 21:11:37 1995 *************** *** 1,4 **** --- 1,5 ---- /* static char *sccsid = "@(#)raw_cb.h 8.1 (ULTRIX) 9/18/92"; */ + /* plus MULTICAST 1.0 */ /************************************************************************ * * * Copyright (c) 1984,1988 by * *************** *** 53,58 **** --- 54,60 ---- struct mbuf *rcb_options; /* protocol specific options */ struct route rcb_route; /* routing information */ short rcb_flags; + struct mbuf *rcb_moptions; /* proto specific multicast options */ }; /* *** sys/net/net/raw_cb.c.orig Tue Feb 7 18:06:01 1995 --- sys/net/net/raw_cb.c Tue Feb 7 17:58:25 1995 *************** *** 1,5 **** --- 1,6 ---- #ifndef lint static char *sccsid = "@(#)raw_cb.c 8.1 (ULTRIX) 9/18/92"; + /* plus MULTICAST 1.1 */ #endif lint /************************************************************************ * * *************** *** 36,41 **** --- 37,45 ---- * 28-Feb-89 Ursula Sinkewicz * SMP/mips merge. (Added R. Bhanukitsiri changes 2/5/89). * + * Tony Mason, Stanford University, 21-Mar-89 * + * Added IP Multicast changes * + * * * 15-Jan-88 lp * Merge of final 43BSD changes. Use new memory allocation * scheme for mbufs. *************** *** 145,150 **** --- 149,167 ---- so->ref = 0; if(rp->rcb_options) m_freem(dtom(rp->rcb_options)); + #ifdef MULTICAST + #ifdef INET + { + #ifdef MROUTING + extern struct socket *ip_mrouter; + if (so == ip_mrouter) + ip_mrouter_done(); + #endif MROUTING + if (rp->rcb_proto.sp_family == AF_INET) + ip_freemoptions(rp->rcb_moptions); + } + #endif INET + #endif MULTICAST KM_FREE(rp, KM_PCB); sofree(so); *** sys/net/net/route.c.orig Tue Feb 7 18:02:02 1995 --- sys/net/net/route.c Tue Feb 7 18:04:38 1995 *************** *** 263,269 **** --- 263,276 ---- int retval = 0; if (cmd != SIOCADDRT && cmd != SIOCDELRT) + #ifdef MULTICAST + /* + * ioctls for multicast packet counts + */ + return (mrt_ioctl(cmd, data)); + #else return (EINVAL); + #endif MULTICAST if (!suser()) return (u.u_error); RTLOCK(); *** sys/net/net/if_loop.c.orig Tue Feb 7 22:43:49 1995 --- sys/net/net/if_loop.c Sat Feb 4 21:11:37 1995 *************** *** 1,5 **** --- 1,6 ---- #ifndef lint static char *sccsid = "@(#)if_loop.c 8.1 (ULTRIX) 9/18/92"; + /* plus MULTICAST 1.1 */ #endif lint /************************************************************************ *************** *** 44,49 **** --- 45,53 ---- * Ursula Sinkewicz 28-Feb-89 * SMP/mips. (Added changes from R. Bhanukitsiri 02/06/89) * + * Tony Mason, Stanford University, 21-Mar-89 * + * Added IP Multicast changes * + * * * Larry Palmer 15-Jan-88 * * Final 43bsd release (move from netinet) * * * *************** *** 114,120 **** --- 118,128 ---- ifp->if_name = "lo"; ifp->if_mtu = LOMTU; + #ifdef MULTICAST + ifp->if_flags = IFF_LOOPBACK | IFF_MULTICAST; + #else ifp->if_flags = IFF_LOOPBACK; + #endif MULTICAST ifp->if_init = loinit; ifp->if_ioctl = loioctl; ifp->if_output = looutput; *************** *** 228,233 **** --- 236,244 ---- int cmd; caddr_t data; { + #ifdef MULTICAST + register struct ifreq *ifr = (struct ifreq *)data; + #endif MULTICAST int error = 0, i; struct lo_softc *sc = &lo_softc; struct ifdevea *ifd = (struct ifdevea *)data; *************** *** 259,264 **** --- 270,290 ---- } break; + #ifdef MULTICAST + case SIOCADDMULTI: + case SIOCDELMULTI: + switch (ifr->ifr_addr.sa_family) { + #ifdef INET + case AF_INET: + break; + #endif INET + default: + error = EAFNOSUPPORT; + break; + } + break; + #endif MULTICAST + default: error = EINVAL; } *** sys/net/netinet/in.h.orig Mon Feb 13 15:55:59 1995 --- sys/net/netinet/in.h Tue Feb 7 18:15:25 1995 *************** *** 26,31 **** --- 26,32 ---- * of DFARS 252.227-7013, or in FAR 52.227-19, as * applicable. */ + /* plus MULTICAST 1.1 */ /************************************************************************ * Modification History * *************** *** 78,83 **** --- 79,85 ---- */ #define IPPROTO_IP 0 /* dummy for IP */ #define IPPROTO_ICMP 1 /* control message protocol */ + #define IPPROTO_IGMP 2 /* group mgmt protocol * #define IPPROTO_GGP 3 /* gateway^2 (deprecated) */ #define IPPROTO_TCP 6 /* tcp */ #define IPPROTO_EGP 8 /* exterior gateway protocol */ *************** *** 85,91 **** #define IPPROTO_UDP 17 /* user datagram protocol */ #define IPPROTO_IDP 22 /* xns idp */ #define IPPROTO_HELLO 63 /* Fuzzball HELLO protocol */ ! #define IPPROTO_RAW 255 /* raw IP packet */ #define IPPROTO_MAX 256 --- 87,95 ---- #define IPPROTO_UDP 17 /* user datagram protocol */ #define IPPROTO_IDP 22 /* xns idp */ #define IPPROTO_HELLO 63 /* Fuzzball HELLO protocol */ ! #ifdef RSVP_ISI ! #define IPPROTO_RSVP 46 /* resource reservation proto* ! #endif RSVP_ISI #define IPPROTO_RAW 255 /* raw IP packet */ #define IPPROTO_MAX 256 *************** *** 143,148 **** --- 147,155 ---- #define IN_CLASSC_MAX (256*256*256) #define IN_CLASSD(i) (((long)(i) & 0xf0000000) == 0xe0000000) + #define IN_CLASSD_NET 0xf0000000 /* These ones aren't really */ + #define IN_CLASSD_NSHIFT 28 /* net and host fields, but */ + #define IN_CLASSD_HOST 0x0fffffff /* routing needn't know. */ #define IN_MULTICAST(i) IN_CLASSD(i) #define IN_EXPERIMENTAL(i) (((long)(i) & 0xe0000000) == 0xe0000000) *************** *** 150,155 **** --- 157,167 ---- #define INADDR_ANY 0x00000000 #define INADDR_BROADCAST 0xffffffff + + #define INADDR_UNSPEC_GROUP (u_long)0xe0000000 /* 224.0.0.0 */ + #define INADDR_ALLHOSTS_GROUP (u_long)0xe0000001 /* 224.0.0.1 */ + #define INADDR_MAX_LOCAL_GROUP (u_long)0xe00000ff /* 224.0.0.255 */ + #ifndef KERNEL #define INADDR_NONE 0xffffffff /* -1 return */ #endif *************** *** 194,199 **** --- 206,233 ---- * Options for use with [gs]etsockopt at the IP level. */ #define IP_OPTIONS 1 /* set/get IP per-packet options */ + #define IP_MULTICAST_IF 2 /* set/get IP multicast interface */ + #define IP_MULTICAST_TTL 3 /* set/get IP multicast timetolive */ + #define IP_MULTICAST_LOOP 4 /* set/get IP multicast loopback */ + #define IP_ADD_MEMBERSHIP 5 /* add an IP group membership */ + #define IP_DROP_MEMBERSHIP 6 /* drop an IP group membership */ + #ifdef RSVP_ISI + #define IP_MULTICAST_VIF 7 /* set/get IP mcast vir. interface */ + #define IP_RSVP_ON 8 /* set rsvp var. in kernel */ + #define IP_RSVP_OFF 9 /* unset rsvp var in kernel */ + #endif RSVP_ISI + + #define IP_DEFAULT_MULTICAST_TTL 1 /* normally limit m'casts to 1 hop */ + #define IP_DEFAULT_MULTICAST_LOOP 1 /* normally hear sends if a member */ + #define IP_MAX_MEMBERSHIPS 20 /* per socket; must fit in one mbuf */ + + /* + * Argument structure for IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP. + */ + struct ip_mreq { + struct in_addr imr_multiaddr; /* IP multicast address of group */ + struct in_addr imr_interface; /* local IP address of interface */ + }; #ifdef __mips #ifdef KERNEL *** sys/net/netinet/ip_var.h.orig Fri May 14 13:41:27 1993 --- sys/net/netinet/ip_var.h Wed Feb 8 00:06:27 1995 *************** *** 24,29 **** --- 24,30 ---- * of DFARS 252.227-7013, or in FAR 52.227-19, as * applicable. */ + /* plus MULTICAST 1.0 */ /************************************************************************ * Modification History * *************** *** 46,51 **** --- 47,55 ---- * 3-Mar-89 U. Sinkewicz * Added new directory layout, pmax to smp file. * + * Tony Mason, Stanford University, 21-Mar-89 * + * Added IP Multicast changes * + * * * 15-Jan-88 lp * Merge of final 43BSD changes. * *************** *** 142,147 **** --- 146,166 ---- char ipopt_list[MAX_IPOPTLEN]; /* options proper */ }; + /* + * Structure stored in an mbuf attached to inpcb.ip_moptions and + * passed to ip_output when IP multicast options are in use. + */ + struct ip_moptions { + struct ifnet *imo_multicast_ifp; /* ifp for outgoing multicasts */ + #ifdef RSVP_ISI + u_long imo_multicast_vif; /* vif num outgoing multicasts */ + #endif RSVP_ISI + u_char imo_multicast_ttl; /* TTL for outgoing multicasts */ + u_char imo_multicast_loop; /* 1 => hear sends if a member */ + u_short imo_num_memberships;/* no. memberships this socket */ + struct in_multi *imo_membership[IP_MAX_MEMBERSHIPS]; + }; + struct ipstat { long ips_total; /* total packets received */ long ips_badsum; /* checksum bad */ *************** *** 180,185 **** --- 199,205 ---- #ifdef KERNEL /* flags passed to ip_output as last parameter */ #define IP_FORWARDING 0x1 /* most of ip header exists */ + #define IP_MULTICASTOPTS 0x2 /* multicast opts present */ #define IP_ROUTETOIF SO_DONTROUTE /* bypass routing tables */ #define IP_ALLOWBROADCAST SO_BROADCAST /* can send broadcast packets */ *** sys/net/netinet/in_var.h.orig Fri Sep 18 14:18:11 1992 --- sys/net/netinet/in_var.h Tue Feb 7 22:16:53 1995 *************** *** 1,4 **** --- 1,5 ---- /* sccsid = @(#)in_var.h 8.1 ULTRIX 9/18/92 */ + /* plus MULTICAST 1.0 */ /************************************************************************ * * *************** *** 68,73 **** --- 69,75 ---- struct in_addr ia_netbroadcast; /* broadcast addr for (logical) net */ int ia_flags; struct in_ifaddr *ia_next; /* next in list of internet addresses */ + struct in_multi *ia_multiaddrs /* list of multicast addresses */ }; /* * Given a pointer to an in_ifaddr (ifaddr), *************** *** 84,86 **** --- 86,216 ---- extern struct in_ifaddr *in_iaonnetof(); extern struct lock_t lk_in_ifaddr; /* SMP: in_ifaddr lock */ #endif + + #ifdef KERNEL + /* + * Macro for finding the interface (ifnet structure) corresponding to one + * of our IP addresses. + */ + #define INADDR_TO_IFP(addr, ifp) \ + /* struct in_addr addr; */ \ + /* struct ifnet *ifp; */ \ + { \ + register struct in_ifaddr *ia; \ + \ + for (ia = in_ifaddr; \ + ia != NULL && IA_SIN(ia)->sin_addr.s_addr != (addr).s_addr; \ + ia = ia->ia_next); \ + (ifp) = (ia == NULL) ? NULL : ia->ia_ifp; \ + } + + /* + * Macro for finding the internet address structure (in_ifaddr) corresponding + * to a given interface (ifnet structure). + */ + #define IFP_TO_IA(ifp, ia) \ + /* struct ifnet *ifp; */ \ + /* struct in_ifaddr *ia; */ \ + { \ + for ((ia) = in_ifaddr; \ + (ia) != NULL && (ia)->ia_ifp != (ifp); \ + (ia) = (ia)->ia_next); \ + } + #endif KERNEL + + /* + * Internet multicast address structure. There is one of these for each IP + * multicast group to which this host belongs on a given network interface. + * They are kept in a linked list, rooted in the interface's in_ifaddr + * structure. + */ + + /* + * This information should be part of the ifnet structure but we don't wish + * to change that - as it might break a number of things + */ + + struct router_info { + struct ifnet *ifp; + int type; /* type of router which is querier on this interface */ + int time; /* # of slow timeouts since last old query */ + struct router_info *next; + }; + + + struct in_multi { + struct in_addr inm_addr; /* IP multicast address */ + struct ifnet *inm_ifp; /* back pointer to ifnet */ + struct in_ifaddr *inm_ia; /* back pointer to in_ifaddr */ + u_int inm_refcount; /* no. membership claims by sockets */ + u_int inm_timer; /* IGMP membership report timer */ + struct in_multi *inm_next; /* ptr to next multicast address */ + u_int inm_state; /* state of the membership */ + struct router_info *inm_rti; /* router info*/ + }; + + #ifdef KERNEL + /* + * Structure used by macros below to remember position when stepping through + * all of the in_multi records. + */ + struct in_multistep { + struct in_ifaddr *i_ia; + struct in_multi *i_inm; + }; + + /* + * Macro for looking up the in_multi record for a given IP multicast address + * on a given interface. If no matching record is found, "inm" returns NULL. + */ + #define IN_LOOKUP_MULTI(addr, ifp, inm) \ + /* struct in_addr addr; */ \ + /* struct ifnet *ifp; */ \ + /* struct in_multi *inm; */ \ + { \ + register struct in_ifaddr *ia; \ + \ + IFP_TO_IA((ifp), ia); \ + if (ia == NULL) \ + (inm) = NULL; \ + else \ + for ((inm) = ia->ia_multiaddrs; \ + (inm) != NULL && (inm)->inm_addr.s_addr != (addr).s_addr; \ + (inm) = inm->inm_next); \ + } + + /* + * Macro to step through all of the in_multi records, one at a time. + * The current position is remembered in "step", which the caller must + * provide. IN_FIRST_MULTI(), below, must be called to initialize "step" + * and get the first record. Both macros return a NULL "inm" when there + * are no remaining records. + */ + #define IN_NEXT_MULTI(step, inm) \ + /* struct in_multistep step; */ \ + /* struct in_multi *inm; */ \ + { \ + if (((inm) = (step).i_inm) != NULL) { \ + (step).i_inm = (inm)->inm_next; \ + } \ + else while ((step).i_ia != NULL) { \ + (inm) = (step).i_ia->ia_multiaddrs; \ + (step).i_ia = (step).i_ia->ia_next; \ + if ((inm) != NULL) { \ + (step).i_inm = (inm)->inm_next; \ + break; \ + } \ + } \ + } + + #define IN_FIRST_MULTI(step, inm) \ + /* struct in_multistep step; */ \ + /* struct in_multi *inm; */ \ + { \ + (step).i_ia = in_ifaddr; \ + (step).i_inm = NULL; \ + IN_NEXT_MULTI((step), (inm)); \ + } + + struct in_multi *in_addmulti(); + #endif KERNEL *** sys/net/netinet/in_proto.c.orig Fri Sep 18 14:18:14 1992 --- sys/net/netinet/in_proto.c Tue Feb 7 19:29:35 1995 *************** *** 1,5 **** --- 1,6 ---- #ifndef lint static char *sccsid = "@(#)in_proto.c 8.1 (ULTRIX) 9/18/92"; + /* plus MULTICAST 1.0 */ #endif lint /************************************************************************ *************** *** 39,44 **** --- 40,48 ---- * 05-May-89 Michael G. Mc Menemy * Add XTI Support. * + * Tony Mason, Stanford University, 21-Mar-89 * + * Added IP Multicast changes * + * * * 15-Jan-88 lp * Merge of final 43BSD changes. * *************** *** 75,80 **** --- 79,87 ---- int ip_init(),ip_slowtimo(),ip_drain(); int ip_ifoutput(), ip_ifinput(), ip_ifioctl(); int icmp_input(); + #ifdef MULTICAST + int igmp_init(),igmp_input(),igmp_fasttimo(); + #endif MULTICAST int udp_input(),udp_ctlinput(); int udp_usrreq(); #ifdef XTI *************** *** 145,150 **** --- 152,171 ---- 0, 0, 0, 0, 0, 0, 0, }, + #ifdef MULTICAST + { SOCK_RAW, &inetdomain, IPPROTO_IGMP, PR_ATOMIC|PR_ADDR, + igmp_input, rip_output, 0, rip_ctloutput, + raw_usrreq, + igmp_init, igmp_fasttimo, 0, 0, + }, + #endif MULTICAST + #ifdef RSVP_ISI + { SOCK_RAW, &inetdomain, IPPROTO_RSVP, PR_ATOMIC|PR_ADDR, + rip_input, rip_output, 0, rip_ctloutput, + raw_usrreq, + 0, 0, 0, 0, + }, + #endif RSVP_ISI #ifdef NSIP { SOCK_RAW, &inetdomain, IPPROTO_IDP, PR_ATOMIC|PR_ADDR, idpip_input, rip_output, nsip_ctlinput, 0, *** sys/net/netinet/if_ether.h.orig Fri Sep 18 14:18:43 1992 --- sys/net/netinet/if_ether.h Sat Feb 4 21:11:37 1995 *************** *** 1,4 **** --- 1,5 ---- /* static char *sccsid = "@(#)if_ether.h 8.1 (ULTRIX) 9/18/92"; */ + /* plus MULTICAST 1.0 */ /************************************************************************ * * *************** *** 31,36 **** --- 32,39 ---- /************************************************************************ * Modification History * * * + * 20-Mar-89 Tony Mason, Stanford University + * Added IP Multicast support * * 15-Jan-88 lp * Merge of final 43BSD changes. *************** *** 86,92 **** --- 89,114 ---- #define ETHERMTU 1500 #define ETHERMIN (60-14) + #ifdef KERNEL /* + * Macro to map an IP multicast address to an Ethernet multicast address. + * The high-order 25 bits of the Ethernet address are statically assigned, + * and the low-order 23 bits are taken from the low end of the IP address. + */ + #define ETHER_MAP_IP_MULTICAST(ipaddr, enaddr) \ + /* struct in_addr *ipaddr; */ \ + /* u_char enaddr[6]; */ \ + { \ + (enaddr)[0] = 0x01; \ + (enaddr)[1] = 0x00; \ + (enaddr)[2] = 0x5e; \ + (enaddr)[3] = ((u_char *)ipaddr)[1] & 0x7f; \ + (enaddr)[4] = ((u_char *)ipaddr)[2]; \ + (enaddr)[5] = ((u_char *)ipaddr)[3]; \ + } + #endif KERNEL + + /* * Ethernet Address Resolution Protocol. * * See RFC 826 for protocol description. Structure below is adapted *************** *** 119,124 **** --- 141,147 ---- struct ifnet ac_if; /* network-visible interface */ u_char ac_enaddr[6]; /* ethernet hardware address */ struct in_addr ac_ipaddr; /* copy of ip address- XXX */ + struct ether_multi *ac_multiaddrs; /* list of ether multicast addrs */ }; /* *************** *** 139,141 **** --- 162,232 ---- extern int nFDDI; /* defined conf.c */ char *ether_sprintf(); #endif + + /* + * Ethernet multicast address structure. There is one of these for each + * multicast address or range of multicast addresses that we are supposed + * to listen to on a particular interface. They are kept in a linked list, + * rooted in the interface's arpcom structure. (This really has nothing to + * do with ARP, or with the Internet address family, but this appears to be + * the minimally-disrupting place to put it.) + */ + struct ether_multi { + u_char enm_addrlo[6];/* low or only address of range */ + u_char enm_addrhi[6];/* high or only address of range */ + struct arpcom *enm_ac; /* back pointer to arpcom */ + u_int enm_refcount; /* no. claims to this addr/range */ + struct ether_multi *enm_next; /* ptr to next ether_multi */ + }; + + #ifdef KERNEL + /* + * Structure used by macros below to remember position when stepping through + * all of the ether_multi records. + */ + struct ether_multistep { + struct ether_multi *e_enm; + }; + + /* + * Macro for looking up the ether_multi record for a given range of Ethernet + * multicast addresses connected to a given arpcom structure. If no matching + * record is found, "enm" returns NULL. + */ + #define ETHER_LOOKUP_MULTI(addrlo, addrhi, ac, enm) \ + /* u_char addrlo[6]; */ \ + /* u_char addrhi[6]; */ \ + /* struct arpcom *ac; */ \ + /* struct ether_multi *enm; */ \ + { \ + for ((enm) = (ac)->ac_multiaddrs; \ + (enm) != NULL && \ + (bcmp((enm)->enm_addrlo, (addrlo), 6) != 0 || \ + bcmp((enm)->enm_addrhi, (addrhi), 6) != 0); \ + (enm) = (enm)->enm_next); \ + } + + /* + * Macro to step through all of the ether_multi records, one at a time. + * The current position is remembered in "step", which the caller must + * provide. ETHER_FIRST_MULTI(), below, must be called to initialize "step" + * and get the first record. Both macros return a NULL "enm" when there + * are no remaining records. + */ + #define ETHER_NEXT_MULTI(step, enm) \ + /* struct ether_multistep step; */ \ + /* struct ether_multi *enm; */ \ + { \ + if (((enm) = (step).e_enm) != NULL) \ + (step).e_enm = (enm)->enm_next; \ + } + + #define ETHER_FIRST_MULTI(step, ac, enm) \ + /* struct ether_multistep step; */ \ + /* struct arpcom *ac; */ \ + /* struct ether_multi *enm; */ \ + { \ + (step).e_enm = (ac)->ac_multiaddrs; \ + ETHER_NEXT_MULTI((step), (enm)); \ + } + #endif KERNEL *** sys/net/netinet/in_pcb.h.orig Fri Sep 18 14:19:18 1992 --- sys/net/netinet/in_pcb.h Sat Feb 4 21:11:37 1995 *************** *** 1,4 **** --- 1,5 ---- /* static char *sccsid = "@(#)in_pcb.h 8.1 (ULTRIX) 9/18/92"; */ + /* plus MULTICAST 1.0 */ /************************************************************************ * * *************** *** 66,71 **** --- 67,73 ---- caddr_t inp_ppcb; /* pointer to per-protocol pcb */ struct route inp_route; /* placeholder for routing entry */ struct mbuf *inp_options; /* IP options */ + struct mbuf *inp_moptions; /* IP multicast options */ }; #define INPLOOKUP_WILDCARD 1 *** sys/net/netinet/in.c.orig Tue Feb 7 18:09:23 1995 --- sys/net/netinet/in.c Sat Feb 4 21:11:37 1995 *************** *** 1,5 **** --- 1,6 ---- #ifndef lint static char *sccsid = "@(#)in.c 8.2 (ULTRIX) 3/19/93"; + /* plus MULTICAST 1.2 */ #endif lint /************************************************************************ *************** *** 55,60 **** --- 56,64 ---- * Changed kmalloc flag to nowait. Added assertions of * lk_in_ifaddr and lk_ifnet. * + * Tony Mason, Stanford University, 21-Mar-89 * + * Added IP Multicast changes * + * * * 15-Jan-88 lp * Merge of final 43BSD changes. * *************** *** 175,180 **** --- 179,188 ---- net = i & IN_CLASSB_NET; else if (IN_CLASSC(i)) net = i & IN_CLASSC_NET; + #ifdef MULTICAST + else if (IN_CLASSD(i)) + net = i & IN_CLASSD_NET; + #endif MULTICAST else return (0); *************** *** 210,215 **** --- 218,228 ---- } else if (IN_CLASSC(i)) { net = i & IN_CLASSC_NET; host = i & IN_CLASSC_HOST; + #ifdef MULTICAST + } else if (IN_CLASSD(i)) { + net = i & IN_CLASSD_NET; + host = i & IN_CLASSD_HOST; + #endif MULTICAST } else return (i); *************** *** 549,554 **** --- 562,579 ---- (int)SIOCADDRT, RTF_UP); } ia->ia_flags |= IFA_ROUTE; + #ifdef MULTICAST + /* + * If the interface supports multicast, join the "all hosts" + * multicast group on that interface. + */ + if (ifp->if_flags & IFF_MULTICAST) { + struct in_addr addr; + + addr.s_addr = htonl(INADDR_ALLHOSTS_GROUP); + in_addmulti(addr, ifp); + } + #endif MULTICAST return (0); } *************** *** 622,626 **** --- 647,757 ---- lia = ia; } } + + #ifdef MULTICAST + /* + * Add an address to the list of IP multicast addresses for a given interface. + */ + struct in_multi * + in_addmulti(addr, ifp) + register struct in_addr addr; + register struct ifnet *ifp; + { + register struct in_multi *inm; + struct ifreq ifr; + struct in_ifaddr *ia; + struct mbuf *m; + int s = splnet(); + + /* + * See if address already in list. + */ + IN_LOOKUP_MULTI(addr, ifp, inm); + if (inm != NULL) { + /* + * Found it; just increment the reference count. + */ + ++inm->inm_refcount; + } + else { + /* + * New address; get an mbuf for a new multicast record + * and link it into the interface's multicast list. + */ + if ((m = m_getclr(M_DONTWAIT, MT_IPMADDR)) == NULL) { + splx(s); + return(NULL); + } + inm = mtod(m, struct in_multi *); + inm->inm_addr = addr; + inm->inm_ifp = ifp; + inm->inm_refcount = 1; + IFP_TO_IA(ifp, ia); + if (ia == NULL) { + m_free(m); + splx(s); + return(NULL); + } + inm->inm_ia = ia; + inm->inm_next = ia->ia_multiaddrs; + ia->ia_multiaddrs = inm; + /* + * Ask the network driver to update its multicast reception + * filter appropriately for the new address. + */ + ((struct sockaddr_in *)&(ifr.ifr_addr))->sin_family = AF_INET; + ((struct sockaddr_in *)&(ifr.ifr_addr))->sin_addr = addr; + if (ifp->if_ioctl == NULL || + (*ifp->if_ioctl)(ifp, SIOCADDMULTI,(caddr_t)&ifr) != 0) { + m_free(m); + splx(s); + return(NULL); + } + /* + * Let IGMP know that we have joined a new IP multicast group. + */ + igmp_joingroup(inm); + } + splx(s); + return(inm); + } + + /* + * Delete a multicast address record. + */ + in_delmulti(inm) + register struct in_multi *inm; + { + register struct in_multi **p; + struct ifreq ifr; + int s = splnet(); + + if (--inm->inm_refcount == 0) { + /* + * No remaining claims to this record; let IGMP know that + * we are leaving the multicast group. + */ + igmp_leavegroup(inm); + /* + * Unlink from list. + */ + for (p = &inm->inm_ia->ia_multiaddrs; + *p != inm; + p = &((*p)->inm_next)); + *p = (*p)->inm_next; + /* + * Notify the network driver to update its multicast reception + * filter. + */ + ((struct sockaddr_in *)&(ifr.ifr_addr))->sin_family = AF_INET; + ((struct sockaddr_in *)&(ifr.ifr_addr))->sin_addr = + inm->inm_addr; + (*inm->inm_ifp->if_ioctl)(inm->inm_ifp, SIOCDELMULTI, + (caddr_t)&ifr); + m_free(dtom(inm)); + } + splx(s); + } + #endif MULTICAST #endif INET *** sys/net/netinet/in_pcb.c.orig Tue Feb 7 18:16:03 1995 --- sys/net/netinet/in_pcb.c Mon Feb 13 14:20:41 1995 *************** *** 90,95 **** --- 90,99 ---- #include "../net/netinet/tcp_timer.h" /* SMP */ #include "../net/netinet/tcp_var.h" /* SMP */ #include "../h/protosw.h" + #ifdef MULTICAST + #include + #include + #endif MULTICAST struct in_addr zeroin_addr; extern struct lock_t lk_udb; *************** *** 119,124 **** --- 123,202 ---- so->so_pcb = (caddr_t)inp; return (0); } + + /* + * return 1 if there's a pcb whose addresses 'confict' with the + * supplied addresses. Only exact matches (address with address + * or wildcard with wildcard) are considered to be in conflict + * since in_pcblookup will resolve anything else via 'best match'. + */ + int + in_pcbconflict(head, faddr, laddr, fport, lport) + register struct inpcb *head; + register u_long faddr, laddr; + register u_short fport, lport; + { + register struct inpcb *inp = head; + + while ((inp = inp->inp_next) != head) + if (inp->inp_lport == lport && + (fport == 0 || inp->inp_fport == fport) && + (faddr == 0 || inp->inp_faddr.s_addr == faddr) && + (laddr == 0 || inp->inp_laddr.s_addr == laddr)) + return (1); + return (0); + } + + /* + * return 1 if there is a local clash on port numbers. This code is needed + * for two reasons: + * - to prevent a request for port 0 (i.e. for the kernel to allocate a + * port number at random) on a particular address from getting a port + * already allocated to someone else who is using INADDR_ANY as their + * address. In particular this fixes the NFS "lock-up" problem. + * - the other usage is to do with a wierdness in yp which is nothing + * to do with me and is described below in in_pcbbind. + * RJB 13/June/94 + */ + int + in_pcbconflict_any_local(head, laddr, lport) + register struct inpcb *head; + register u_long laddr; + register u_short lport; + { + register struct inpcb *inp = head; + + while ((inp = inp->inp_next) != head) + if (inp->inp_lport == lport && + (laddr == 0 || inp->inp_laddr.s_addr == 0 || + inp->inp_laddr.s_addr == laddr)) + return (1); + return (0); + } + + /* + * Chose a unique (non-conflicting) local port for the inpcb list + * starting at 'head'. (A 'rover' is kept in the lport field of + * the list head to make N calls to this routine O(N^2) instead of + * O(N^3)). The port will always be + * IPPORT_RESERVED <= lport <= IPPORT_USERRESERVED + */ + u_short + in_uniqueport(head, faddr, laddr, fport) + register struct inpcb *head; + register u_long faddr, laddr; + register u_short fport; + { + register u_short lport = head->inp_lport; + + do { + ++lport; + if (lport < IPPORT_RESERVED || lport > IPPORT_USERRESERVED) + lport = IPPORT_RESERVED; + } while (in_pcbconflict_any_local(head, laddr, htons(lport))); + head->inp_lport = lport; + return (htons(lport)); + } /* * SMP: Enter with socket lock set. Called from tcp_usrreq, PRU_BIND, *************** *** 130,136 **** { register struct socket *so = inp->inp_socket; register struct inpcb *head = inp->inp_head; ! register struct sockaddr_in *sin; u_short lport = 0; if (smp_debug){ if (smp_owner(&so->lk_socket) == 0) --- 208,214 ---- { register struct socket *so = inp->inp_socket; register struct inpcb *head = inp->inp_head; ! u_long laddr = 0; u_short lport = 0; if (smp_debug){ if (smp_owner(&so->lk_socket) == 0) *************** *** 140,185 **** return (EADDRNOTAVAIL); if (inp->inp_lport || inp->inp_laddr.s_addr != INADDR_ANY) return (EINVAL); ! if (nam == 0) ! goto noname; ! sin = mtod(nam, struct sockaddr_in *); ! if (nam->m_len != sizeof (*sin)) ! return (EINVAL); ! if (sin->sin_addr.s_addr != INADDR_ANY) { ! int tport = sin->sin_port; ! ! sin->sin_port = 0; /* yech... */ ! if (ifa_ifwithaddr((struct sockaddr *)sin) == 0) ! return (EADDRNOTAVAIL); ! sin->sin_port = tport; } - lport = sin->sin_port; - if (lport) { - u_short aport = ntohs(lport); - int wild = 0; - - /* GROSS */ - if (aport < IPPORT_RESERVED && u.u_uid != 0) - return (EACCES); - /* even GROSSER, but this is the Internet */ - if ((so->so_options & SO_REUSEADDR) == 0 && - ((so->so_proto->pr_flags & PR_CONNREQUIRED) == 0 || - (so->so_options & SO_ACCEPTCONN) == 0)) - wild = INPLOOKUP_WILDCARD; - if (in_pcblookup(head, - zeroin_addr, 0, sin->sin_addr, lport, wild)) - return (EADDRINUSE); - } - inp->inp_laddr = sin->sin_addr; - noname: if (lport == 0) ! do { ! if (head->inp_lport++ < IPPORT_RESERVED || ! head->inp_lport > IPPORT_USERRESERVED) ! head->inp_lport = IPPORT_RESERVED; ! lport = htons(head->inp_lport); ! } while (in_pcblookup(head, ! zeroin_addr, 0, inp->inp_laddr, lport, INPLOOKUP_WILDCARD)); inp->inp_lport = lport; return (0); } --- 218,272 ---- return (EADDRNOTAVAIL); if (inp->inp_lport || inp->inp_laddr.s_addr != INADDR_ANY) return (EINVAL); ! if (nam) { ! struct sockaddr_in *sin = mtod(nam, struct sockaddr_in *); ! ! if (nam->m_len != sizeof (*sin)) ! return (EINVAL); ! laddr = sin->sin_addr.s_addr; ! lport = sin->sin_port; ! if (lport) { ! /* GROSS */ ! if (ntohs(lport) < IPPORT_RESERVED && u.u_uid != 0) ! return (EACCES); ! #ifndef sun ! if ((inp->inp_socket->so_options & SO_REUSEADDR) == 0 && ! in_pcbconflict(head, 0, laddr, 0, lport)) ! return (EADDRINUSE); ! #else ! /* ! * The code above is correct. However, to account ! * for some incredible brain damage in sun's yp ! * (most people feel that saying "brain damage" ! * is redundent when talking about yp but I add it ! * for emphasis) we have to reproduce a bug in ! * sun os: The library routine yp_bind decides ! * whether the ypbind process is alive by attempting ! * to bind to and, if the bind ! * succeeds, assumes that ypbind has died. But ! * ypbind has bound itself to <*.ypport> so the ! * bind above is perfectly legal (more specific). ! * However Sun OS contains a bug that effectively ! * ignores the address on a bind & just tests the ! * port. Rather than attempt to fix yp, we ! * break the kernel. ! */ ! { ! register struct socket *so = inp->inp_socket; ! if ((so->so_options & SO_REUSEADDR) == 0 && ! ((so->so_proto->pr_flags & PR_CONNREQUIRED) == 0 || ! (so->so_options & SO_ACCEPTCONN) == 0) && ! in_pcbconflict_any_local(head, laddr, lport)) ! return (EADDRINUSE); ! } ! #endif ! } } if (lport == 0) ! lport = in_uniqueport(head, inp->inp_faddr.s_addr, laddr, ! inp->inp_fport); ! ! inp->inp_laddr.s_addr = laddr; inp->inp_lport = lport; return (0); } *************** *** 210,222 **** struct inpcb *inp; register struct sockaddr_in *sin; { ! struct in_ifaddr *ia; ! struct sockaddr_in *ifaddr; if (sin->sin_family != AF_INET) return (EAFNOSUPPORT); ! if (sin->sin_port == 0) return (EADDRNOTAVAIL); if (in_ifaddr) { /* * If the destination address is INADDR_ANY, --- 297,313 ---- struct inpcb *inp; register struct sockaddr_in *sin; { ! register u_long faddr = sin->sin_addr.s_addr; ! register u_short fport = sin->sin_port; ! register u_long laddr; ! register u_short lport; if (sin->sin_family != AF_INET) return (EAFNOSUPPORT); ! #ifndef MULTICAST ! if (fport == 0) return (EADDRNOTAVAIL); + #endif if (in_ifaddr) { /* * If the destination address is INADDR_ANY, *************** *** 226,251 **** * choose the broadcast address for that interface. */ #define satosin(sa) ((struct sockaddr_in *)(sa)) ! if (sin->sin_addr.s_addr == INADDR_ANY) ! sin->sin_addr = IA_SIN(in_ifaddr)->sin_addr; ! else if (sin->sin_addr.s_addr == (u_long)INADDR_BROADCAST && ! (in_ifaddr->ia_ifp->if_flags & IFF_BROADCAST)) ! sin->sin_addr = satosin(&in_ifaddr->ia_broadaddr)->sin_addr; } ! if (inp->inp_laddr.s_addr == INADDR_ANY) { ! register struct route *ro; struct ifnet *ifp; - ia = (struct in_ifaddr *)0; /* * If route is known or can be allocated now, * our src addr is taken from the i/f, else punt. */ - ro = &inp->inp_route; RTLOCK(); if (ro->ro_rt && ! (satosin(&ro->ro_dst)->sin_addr.s_addr != ! sin->sin_addr.s_addr || inp->inp_socket->so_options & SO_DONTROUTE)) { rtfree(ro->ro_rt); ro->ro_rt = (struct rtentry *)0; --- 317,345 ---- * choose the broadcast address for that interface. */ #define satosin(sa) ((struct sockaddr_in *)(sa)) ! if (faddr == INADDR_ANY) { ! faddr = IA_SIN(in_ifaddr)->sin_addr.s_addr; ! sin->sin_addr.s_addr = faddr; ! } else if (faddr == (u_long)INADDR_BROADCAST && ! (in_ifaddr->ia_ifp->if_flags & IFF_BROADCAST)) { ! faddr = satosin(&in_ifaddr->ia_broadaddr)->sin_addr.s_addr; ! sin->sin_addr.s_addr = faddr; ! } } ! laddr = inp->inp_laddr.s_addr; ! lport = inp->inp_lport; ! if (laddr == INADDR_ANY) { ! register struct route *ro = &inp->inp_route; ! struct in_ifaddr *ia = 0; struct ifnet *ifp; /* * If route is known or can be allocated now, * our src addr is taken from the i/f, else punt. */ RTLOCK(); if (ro->ro_rt && ! (satosin(&ro->ro_dst)->sin_addr.s_addr != faddr || inp->inp_socket->so_options & SO_DONTROUTE)) { rtfree(ro->ro_rt); ro->ro_rt = (struct rtentry *)0; *************** *** 273,284 **** } RTUNLOCK(); if (ia == 0) { - int fport = sin->sin_port; - sin->sin_port = 0; ia = (struct in_ifaddr *) ifa_ifwithdstaddr((struct sockaddr *)sin); - sin->sin_port = fport; if (ia == 0) ia = in_iaonnetof(in_netof(sin->sin_addr)); if (ia == 0){ --- 367,375 ---- *************** *** 287,308 **** if (ia == 0) return (EADDRNOTAVAIL); } ! ifaddr = (struct sockaddr_in *)&ia->ia_addr; } ! if (in_pcblookup(inp->inp_head, ! sin->sin_addr, ! sin->sin_port, ! inp->inp_laddr.s_addr ? inp->inp_laddr : ifaddr->sin_addr, ! inp->inp_lport, ! 0)) return (EADDRINUSE); ! if (inp->inp_laddr.s_addr == INADDR_ANY) { ! if (inp->inp_lport == 0) ! (void)in_pcbbind(inp, (struct mbuf *)0); ! inp->inp_laddr = ifaddr->sin_addr; ! } ! inp->inp_faddr = sin->sin_addr; ! inp->inp_fport = sin->sin_port; return (0); } --- 378,414 ---- if (ia == 0) return (EADDRNOTAVAIL); } ! #ifdef MULTICAST ! /* ! * If the destination address is multicast and an outgoing ! * interface has been set as a multicast option, use the ! * address of that interface as our source address. ! */ ! if (IN_MULTICAST(ntohl(faddr)) && inp->inp_moptions != NULL) { ! struct ip_moptions *imo; ! ! imo = mtod(inp->inp_moptions, struct ip_moptions *); ! if (imo->imo_multicast_ifp != NULL) { ! ifp = imo->imo_multicast_ifp; ! for (ia = in_ifaddr; ia; ia = ia->ia_next) ! if (ia->ia_ifp == ifp) ! break; ! if (ia == 0) ! return (EADDRNOTAVAIL); ! } ! } ! #endif MULTICAST ! laddr = satosin(&ia->ia_addr)->sin_addr.s_addr; ! if (lport == 0) ! lport = in_uniqueport(inp->inp_head,faddr,laddr,fport); } ! if (in_pcbconflict(inp->inp_head, faddr, laddr, fport, lport)) return (EADDRINUSE); ! ! inp->inp_faddr.s_addr = faddr; ! inp->inp_laddr.s_addr = laddr; ! inp->inp_fport = fport; ! inp->inp_lport = lport; return (0); } *************** *** 338,343 **** --- 444,452 ---- if (inp->inp_route.ro_rt) rtfree(inp->inp_route.ro_rt); RTUNLOCK(); + #ifdef MULTICAST + ip_freemoptions(inp->inp_moptions); + #endif MULTICAST remque(inp); KM_FREE(inp, KM_PCB); so->so_pcb = 0; *************** *** 457,499 **** RTUNLOCK(); } struct inpcb * ! in_pcblookup(head, faddr, fport, laddr, lport, flags) struct inpcb *head; ! struct in_addr faddr, laddr; ! u_short fport, lport; int flags; { register struct inpcb *inp, *match = 0; ! int matchwild = 3, wildcard; ! int s; /* SMP */ for (inp = head->inp_next; inp != head; inp = inp->inp_next) { if (inp->inp_lport != lport) ! continue; wildcard = 0; ! if (inp->inp_laddr.s_addr != INADDR_ANY) { ! /* receiver not looking for broadcast */ ! if (laddr.s_addr == INADDR_ANY) ! wildcard++; ! else if (inp->inp_laddr.s_addr != laddr.s_addr) ! continue; ! } else { ! if (laddr.s_addr != INADDR_ANY) ! wildcard++; } ! if (inp->inp_faddr.s_addr != INADDR_ANY) { ! if (faddr.s_addr == INADDR_ANY) ! wildcard++; ! else if (inp->inp_faddr.s_addr != faddr.s_addr || ! inp->inp_fport != fport) ! continue; ! } else { ! if (faddr.s_addr != INADDR_ANY) ! wildcard++; } ! if (wildcard && (flags & INPLOOKUP_WILDCARD) == 0) ! continue; if (wildcard < matchwild) { match = inp; matchwild = wildcard; --- 566,616 ---- RTUNLOCK(); } + /* + * Find the 'best match' between the datagram address and the list of inpcb's starting at 'head'. + * This routine is *only* used by protocol input routines to locate + * the pcb associated with some datagram. (The unused 'flags' parameter + * is a carry-over from days when this routine was (mis-)used to do the + * job that in_pcbconflict does.) + * + * The rules for best match are: + * - the local port must match + * - the longest match (the fewest wildcards) is preferred + * for the other three fields. + * - if there are multiple best matches, the first is taken. + */ struct inpcb * ! in_pcblookup(head, infor, fport, inloc, lport, flags) struct inpcb *head; ! struct in_addr infor, inloc; ! register u_short fport, lport; int flags; { register struct inpcb *inp, *match = 0; ! register u_long faddr = infor.s_addr; ! register u_long laddr = inloc.s_addr; ! register int matchwild = 4, wildcard; for (inp = head->inp_next; inp != head; inp = inp->inp_next) { if (inp->inp_lport != lport) ! continue; wildcard = 0; ! if (inp->inp_laddr.s_addr != laddr) { ! if (inp->inp_laddr.s_addr != INADDR_ANY) ! continue; ! ++wildcard; } ! if (inp->inp_faddr.s_addr != faddr) { ! if (inp->inp_faddr.s_addr != INADDR_ANY) ! continue; ! ++wildcard; } ! if (inp->inp_fport != fport) { ! if (inp->inp_fport != INADDR_ANY) ! continue; ! ++wildcard; ! } if (wildcard < matchwild) { match = inp; matchwild = wildcard; *** sys/net/netinet/ip_icmp.c.orig Tue Feb 7 22:17:52 1995 --- sys/net/netinet/ip_icmp.c Tue Feb 7 22:20:07 1995 *************** *** 1,5 **** --- 1,6 ---- #ifndef lint static char *sccsid = "@(#)ip_icmp.c 8.2 (ULTRIX) 3/19/93"; + /* plus MULTICAST 1.0 */ #endif lint /************************************************************************ *************** *** 66,71 **** --- 67,75 ---- * 3-Mar-89 U. Sinkewicz * Put new directory layout into smp file. * + * Tony Mason, Stanford University, 21-Mar-89 * + * Added IP Multicast changes * + * * * 15-Jan-88 lp * Merge of final 43BSD changes. * *************** *** 169,175 **** --- 173,188 ---- goto free; } + #ifdef MULTICAST /* + * Don't send error in response to a multicast or broadcast packet. + */ + if (IN_MULTICAST(ntohl(oip->ip_dst.s_addr)) || + in_broadcast(oip->ip_dst)) + goto free; + #endif MULTICAST + + /* * First, formulate icmp message */ m = m_get(M_DONTWAIT, MT_DATA); *************** *** 314,319 **** --- 327,338 ---- icmpstat.icps_badlen++; goto free; } + + #ifdef MULTICAST + if (IN_MULTICAST(ntohl(icp->icmp_ip.ip_dst.s_addr))) + goto badcode; + #endif MULTICAST + #ifdef ICMPPRINTFS if (icmpprintfs) printf("deliver to protocol %d\n", icp->icmp_ip.ip_p); *** sys/net/netinet/ip_input.c.orig Tue Feb 7 22:20:56 1995 --- sys/net/netinet/ip_input.c Tue Feb 7 22:35:20 1995 *************** *** 1,5 **** --- 1,6 ---- #ifndef lint static char *sccsid = "@(#)ip_input.c 8.3 (ULTRIX) 5/14/93"; + /* plus MULTICAST 1.1 */ #endif lint /* *************** *** 78,83 **** --- 79,87 ---- * 13-Feb-89 Ursula Sinkewicz * SMP: Added lk_in_ifaddr and lk_ifnet. * + * Tony Mason, Stanford University, 21-Mar-89 * + * Added IP Multicast changes * + * * * 15-Jan-88 lp * Merge of final 43BSD changes. Use new memory allocation * scheme for mbufs. *************** *** 126,131 **** --- 130,140 ---- #include "../net/netinet/ip_icmp.h" #include "../net/netinet/tcp.h" + #ifdef RSVP_ISI + #include + + struct socket *ip_rsvpd; + #endif RSVP_ISI u_char ip_protox[IPPROTO_MAX]; int ipqmaxlen = IFQ_MAXLEN; struct in_ifaddr *in_ifaddr; /* first inet address */ *************** *** 197,207 **** register struct in_ifaddr *ia; struct ifnet *ifp; int hlen, s; ! /* ! * This is to keep these long aligned ! */ ! struct in_addr dst; ! struct in_addr src; struct mbuf * m_pullup_exact(); next: /* --- 206,216 ---- register struct in_ifaddr *ia; struct ifnet *ifp; int hlen, s; ! /* ! * This is to keep these long aligned ! */ ! struct in_addr dst; ! struct in_addr src; struct mbuf * m_pullup_exact(); next: /* *************** *** 229,236 **** if (do_pullup_exact) { ip = mtod(m, struct ip *); ! if (m->m_len >= sizeof (struct ip)) { ! /* * if at least ip hdr length (no options) can test * for udp (really only need 4 longs of header for * this, but...). Prevent large data (e.g. nfs) --- 238,245 ---- if (do_pullup_exact) { ip = mtod(m, struct ip *); ! if (m->m_len >= sizeof (struct ip)) { ! /* * if at least ip hdr length (no options) can test * for udp (really only need 4 longs of header for * this, but...). Prevent large data (e.g. nfs) *************** *** 259,265 **** if ((m = m_pullup(m, sizeof (struct ip))) == 0) { IPSTAT(ips_toosmall++); goto next; ! } } } else { if ((m->m_off > MMAXOFF || m->m_len < sizeof (struct ip)) && --- 268,274 ---- if ((m = m_pullup(m, sizeof (struct ip))) == 0) { IPSTAT(ips_toosmall++); goto next; ! } } } else { if ((m->m_off > MMAXOFF || m->m_len < sizeof (struct ip)) && *************** *** 338,347 **** if (hlen > sizeof (struct ip) && ip_dooptions(ip, ifp)) goto next; /* * Check our list of addresses, to see if the packet is for us. */ ! bcopy(&ip->ip_dst, &dst, sizeof(struct in_addr)); for (ia = in_ifaddr; ia; ia = ia->ia_next) { #define satosin(sa) ((struct sockaddr_in *)(sa)) --- 347,369 ---- if (hlen > sizeof (struct ip) && ip_dooptions(ip, ifp)) goto next; + #ifdef RSVP_ISI + /* greedy RSVP, snatches any PATH packet of the RSVP protocol and no + * matter if it is destined to another node, or whether it is + * a multicast one, RSVP wants it! and prevents it from being forwarded + * anywhere else. Also checks if the rsvp daemon is running before + * grabbing the packet. + */ + /* && IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) OLD: no need anymore */ + + if (ip_rsvpd != NULL && ip->ip_p==IPPROTO_RSVP) + goto ours; + #endif RSVP_ISI + /* * Check our list of addresses, to see if the packet is for us. */ ! bcopy(&ip->ip_dst, &dst, sizeof(struct in_addr)); for (ia = in_ifaddr; ia; ia = ia->ia_next) { #define satosin(sa) ((struct sockaddr_in *)(sa)) *************** *** 375,380 **** --- 397,454 ---- } } } + #ifdef MULTICAST + if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { + struct in_multi *inm; + #ifdef MROUTING + extern struct socket *ip_mrouter; + + + if (ip_mrouter) { + /* + * If we are acting as a multicast router, all + * incoming multicast packets are passed to the + * kernel-level multicast forwarding function. + * The packet is returned (relatively) intact; if + * ip_mforward() returns a non-zero value, the packet + * must be discarded, else it may be accepted below. + * + * (The IP ident field is put in the same byte order + * as expected when ip_mforward() is called from + * ip_output().) + */ + ip->ip_id = htons(ip->ip_id); + #ifdef RSVP_ISI + if (ip_mforward(ip, ifp, m, NULL) != 0) { + #else + if (ip_mforward(ip, ifp, m) != 0) { + #endif RSVP_ISI + m_freem(m); + goto next; + } + ip->ip_id = ntohs(ip->ip_id); + + /* + * The process-level routing demon needs to receive + * all multicast IGMP packets, whether or not this + * host belongs to their destination groups. + */ + if (ip->ip_p == IPPROTO_IGMP) + goto ours; + } + #endif MROUTING + /* + * See if we belong to the destination multicast group on the + * arrival interface. + */ + IN_LOOKUP_MULTI(ip->ip_dst, ifp, inm); + if (inm == NULL) { + m_freem(dtom(ip)); + goto next; + } + goto ours; + } + #endif MULTICAST if (dst.s_addr == (u_long)INADDR_BROADCAST) goto ours; if (dst.s_addr == INADDR_ANY) *************** *** 393,399 **** */ smp_lock(&lk_ipq, LK_RETRY); if(ipq.next != &ipq) { ! bcopy(&ip->ip_src, &src, sizeof(struct in_addr)); for (fp = ipq.next; fp != &ipq; fp = fp->next) if (ip->ip_id == fp->ipq_id && src.s_addr == fp->ipq_src.s_addr && --- 467,473 ---- */ smp_lock(&lk_ipq, LK_RETRY); if(ipq.next != &ipq) { ! bcopy(&ip->ip_src, &src, sizeof(struct in_addr)); for (fp = ipq.next; fp != &ipq; fp = fp->next) if (ip->ip_id == fp->ipq_id && src.s_addr == fp->ipq_src.s_addr && *************** *** 425,447 **** IPSTAT(ips_fragments++); #ifdef mips ! /* ! * if the ip header is not aligned properly, copy the ! * mbuf to avoid lots of bcopy's later when reassembling ! * fragments due to placement of fragment pointers within ! * ip header. ! */ ! if (((u_int)ip & 0x3) != 0) { ! register struct mbuf *mnew; ! mnew = m_copy(m, 0, m->m_len); ! mnew->m_next = m_free(m); ! m = mnew; ! ip = mtod(m, struct ip *); ! } #endif mips ip = ip_reass((struct ipasfrag *)ip, fp); ! smp_unlock(&lk_ipq); if (ip == 0) goto next; m = dtom(ip); --- 499,521 ---- IPSTAT(ips_fragments++); #ifdef mips ! /* ! * if the ip header is not aligned properly, copy the ! * mbuf to avoid lots of bcopy's later when reassembling ! * fragments due to placement of fragment pointers within ! * ip header. ! */ ! if (((u_int)ip & 0x3) != 0) { ! register struct mbuf *mnew; ! mnew = m_copy(m, 0, m->m_len); ! mnew->m_next = m_free(m); ! m = mnew; ! ip = mtod(m, struct ip *); ! } #endif mips ip = ip_reass((struct ipasfrag *)ip, fp); ! smp_unlock(&lk_ipq); if (ip == 0) goto next; m = dtom(ip); *************** *** 449,455 **** if (fp) { ip_freef(fp); } ! smp_unlock(&lk_ipq); } /* * Switch out to protocol's input routine. --- 523,529 ---- if (fp) { ip_freef(fp); } ! smp_unlock(&lk_ipq); } /* * Switch out to protocol's input routine. *************** *** 780,790 **** goto bad2; /* don't attempt reply pkt */ } #ifdef mips ! bcopy(&ip->ip_dst, &ipaddr.sin_addr, ! sizeof(ip->ip_dst)); #endif mips #ifdef vax ! ipaddr.sin_addr = ip->ip_dst; #endif vax ia = (struct in_ifaddr *) ifa_ifwithaddr((struct sockaddr *)&ipaddr); --- 854,864 ---- goto bad2; /* don't attempt reply pkt */ } #ifdef mips ! bcopy(&ip->ip_dst, &ipaddr.sin_addr, ! sizeof(ip->ip_dst)); #endif mips #ifdef vax ! ipaddr.sin_addr = ip->ip_dst; #endif vax ia = (struct in_ifaddr *) ifa_ifwithaddr((struct sockaddr *)&ipaddr); *************** *** 821,828 **** goto bad; } #ifdef mips ! bcopy(&ipaddr.sin_addr, &ip->ip_dst, ! sizeof(ip->ip_dst)); #endif mips #ifdef vax ip->ip_dst = ipaddr.sin_addr; --- 895,902 ---- goto bad; } #ifdef mips ! bcopy(&ipaddr.sin_addr, &ip->ip_dst, ! sizeof(ip->ip_dst)); #endif mips #ifdef vax ip->ip_dst = ipaddr.sin_addr; *************** *** 1271,1273 **** --- 1345,1371 ---- sendicmp: icmp_error(ip, type, code, ifp, dest); } + + #ifdef RSVP_ISI + int ip_rsvp_init(so) + struct socket *so; + { + if (so->so_type != SOCK_RAW || + so->so_proto->pr_protocol != IPPROTO_RSVP) + return EOPNOTSUPP; + + if (ip_rsvpd != NULL) + return EADDRINUSE; + + ip_rsvpd = so; + + return 0; + } + + int ip_rsvp_done() + { + ip_rsvpd = NULL; + + return 0; + } + #endif RSVP_ISI *** sys/net/netinet/ip_output.c.orig Tue Feb 7 22:35:46 1995 --- sys/net/netinet/ip_output.c Wed Feb 8 00:23:59 1995 *************** *** 1,5 **** --- 1,6 ---- #ifndef lint static char *sccsid = "@(#)ip_output.c 8.2 (ULTRIX) 3/19/93"; + /* plus MULTICAST 1.2 */ #endif lint /************************************************************************ *************** *** 83,88 **** --- 84,92 ---- * 13 Feb 89 Ursula Sinkewicz * SMP: Added lk_in_ifaddr, lk_ifnet. * + * Tony Mason, Stanford University, 21-Mar-89 * + * Added IP Multicast changes * + * * * 15-Jan-88 lp * Merge of final 43BSD changes. * *************** *** 148,159 **** --- 152,170 ---- * control of the socket lock. */ + #ifdef MULTICAST + ip_output(m, opt, ro, flags, so, mopts) + #else ip_output(m, opt, ro, flags, so) + #endif MULTICAST struct mbuf *m; struct mbuf *opt; struct route *ro; int flags; struct socket *so; + #ifdef MULTICAST + struct mbuf *mopts; + #endif MULTICAST { register struct ip *ip; register struct ifnet *ifp; *************** *** 245,250 **** --- 256,371 ---- } RTUNLOCK(); + #ifdef MULTICAST + if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { + struct ip_moptions *imo; + struct in_multi *inm; + extern struct ifnet loif; + #ifdef MROUTING + extern struct socket *ip_mrouter; + #ifdef RSVP_ISI + extern struct socket *ip_rsvpd; + #endif RSVP_ISI + #endif MROUTING + /* + * IP destination address is multicast. Make sure "dst" + * still points to the address in "ro". (It may have been + * changed to point to a gateway address, above.) + */ + dst = (struct sockaddr_in *)&ro->ro_dst; + /* + * See if the caller provided any multicast options + */ + if ((flags & IP_MULTICASTOPTS) && mopts != NULL) { + imo = mtod(mopts, struct ip_moptions *); + ip->ip_ttl = imo->imo_multicast_ttl; + if (imo->imo_multicast_ifp != NULL) + ifp = imo->imo_multicast_ifp; + } + else { + imo = NULL; + ip->ip_ttl = IP_DEFAULT_MULTICAST_TTL; + } + /* + * Confirm that the outgoing interface supports multicast. + */ + if ((ifp->if_flags & IFF_MULTICAST) == 0) { + error = ENETUNREACH; + goto bad; + } + /* + * If source address not specified yet, use address + * of outgoing interface. + */ + if (ip->ip_src.s_addr == INADDR_ANY) { + register struct in_ifaddr *ia; + + for (ia = in_ifaddr; ia; ia = ia->ia_next) + if (ia->ia_ifp == ifp) { + ip->ip_src = IA_SIN(ia)->sin_addr; + break; + } + } + + IN_LOOKUP_MULTI(ip->ip_dst, ifp, inm); + if (inm != NULL && + (imo == NULL || imo->imo_multicast_loop)) { + /* + * If we belong to the destination multicast group + * on the outgoing interface, and the caller did not + * forbid loopback, loop back a copy. + */ + ip_mloopback(ifp, m, dst); + } + #ifdef MROUTING + else if (ip_mrouter && (flags & IP_FORWARDING) == 0) { + /* + * If we are acting as a multicast router, perform + * multicast forwarding as if the packet had just + * arrived on the interface to which we are about + * to send. The multicast forwarding function + * recursively calls this function, using the + * IP_FORWARDING flag to prevent infinite recursion. + * + * Multicasts that are looped back by ip_mloopback(), + * above, will be forwarded by the ip_input() routine, + * if necessary. + */ + #ifdef RSVP_ISI + + * Check if rsvp daemon is running. If not, don't + * set ip_moptions. This ensures that the packet + * is multicast and not just sent down one link + * as prescribed by rsvpd. + */ + if (ip_rsvpd == NULL) + imo = NULL; + if (ip_mforward(ip, ifp, m, imo) != 0) { + #else + if (ip_mforward(ip, ifp, m) != 0) { + #endif RSVP_ISI + m_freem(m); + goto done; + } + } + #endif MROUTING + /* + * Multicasts with a time-to-live of zero may be looped- + * back, above, but must not be transmitted on a network. + * Also, multicasts addressed to the loopback interface + * are not sent -- the above call to ip_mloopback() will + * loop back a copy if this host actually belongs to the + * destination group on the loopback interface. + */ + if (ip->ip_ttl == 0 || ifp == &loif) { + m_freem(m); + goto done; + } + + goto sendit; + } + #endif MULTICAST + /* * Look for broadcast address and * and verify user is allowed to send *************** *** 285,290 **** --- 406,414 ---- } } + #ifdef MULTICAST + sendit: + #endif MULTICAST /* * If small enough for interface, can just send directly. */ *************** *** 542,547 **** --- 666,683 ---- case IP_OPTIONS: return (ip_pcbopts(&inp->inp_options, *m)); + #ifdef MULTICAST + case IP_MULTICAST_IF: + #ifdef RSVP_ISI + case IP_MULTICAST_VIF: + #endif RSVP_ISI + case IP_MULTICAST_TTL: + case IP_MULTICAST_LOOP: + case IP_ADD_MEMBERSHIP: + case IP_DROP_MEMBERSHIP: + error = ip_setmoptions(optname, &inp->inp_moptions, *m); + break; + #endif MULTICAST default: error = EINVAL; break; *************** *** 564,569 **** --- 700,717 ---- } else (*m)->m_len = 0; break; + #ifdef MULTICAST + case IP_MULTICAST_IF: + #ifdef RSVP_ISI + case IP_MULTICAST_VIF: + #endif RSVP_ISI + case IP_MULTICAST_TTL: + case IP_MULTICAST_LOOP: + case IP_ADD_MEMBERSHIP: + case IP_DROP_MEMBERSHIP: + error = ip_getmoptions(optname, inp->inp_moptions, m); + break; + #endif MULTICAST default: error = EINVAL; break; *************** *** 678,684 **** return (EINVAL); } - /* * Attempt to fragment type 2 mbuf chain. * Works only if each mbuf is smaller than a packet. --- 826,831 ---- *************** *** 820,822 **** --- 967,1338 ---- } return (1); } + + #ifdef MULTICAST + /* + * Set the IP multicast options in response to user setsockopt(). + */ + ip_setmoptions(optname, mopts, m) + int optname; + struct mbuf **mopts; + struct mbuf *m; + { + int error = 0; + struct ip_moptions *imo; + u_char loop; + int i; + struct in_addr addr; + struct ip_mreq *mreq; + struct ifnet *ifp; + struct route ro; + struct sockaddr_in *dst; + + if (*mopts == NULL) { + /* + * No multicast option buffer attached to the pcb; + * allocate one and initialize to default values. + */ + MGET(*mopts, M_WAIT, MT_IPMOPTS); + if (*mopts == NULL) + return (ENOBUFS); + imo = mtod(*mopts, struct ip_moptions *); + imo->imo_multicast_ifp = NULL; + #ifdef RSVP_ISI + imo->imo_multicast_vif = 0; + #endif RSVP_ISI + imo->imo_multicast_ttl = IP_DEFAULT_MULTICAST_TTL; + imo->imo_multicast_loop = IP_DEFAULT_MULTICAST_LOOP; + imo->imo_num_memberships = 0; + } + + imo = mtod(*mopts, struct ip_moptions *); + + switch (optname) { + + #ifdef RSVP_ISI + /* store an index number for the vif you wanna use in the send */ + case IP_MULTICAST_VIF: + if (m == NULL || m->m_len != sizeof(int)) { + error = EINVAL; + break; + } + i = *(mtod(m, int *)); + if (!legal_vif_num(i)) { + error = EINVAL; + break; + } + imo->imo_multicast_vif = i; + break; + #endif RSVP_ISI + + case IP_MULTICAST_IF: + /* + * Select the interface for outgoing multicast packets. + */ + if (m == NULL || m->m_len != sizeof(struct in_addr)) { + error = EINVAL; + break; + } + addr = *(mtod(m, struct in_addr *)); + /* + * INADDR_ANY is used to remove a previous selection. + * When no interface is selected, a default one is + * chosen every time a multicast packet is sent. + */ + if (addr.s_addr == INADDR_ANY) { + imo->imo_multicast_ifp = NULL; + break; + } + /* + * The selected interface is identified by its local + * IP address. Find the interface and confirm that + * it supports multicasting. + */ + INADDR_TO_IFP(addr, ifp); + if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0) { + error = EADDRNOTAVAIL; + break; + } + imo->imo_multicast_ifp = ifp; + break; + + case IP_MULTICAST_TTL: + /* + * Set the IP time-to-live for outgoing multicast packets. + */ + if (m == NULL || m->m_len != 1) { + error = EINVAL; + break; + } + imo->imo_multicast_ttl = *(mtod(m, u_char *)); + break; + + case IP_MULTICAST_LOOP: + /* + * Set the loopback flag for outgoing multicast packets. + * Must be zero or one. + */ + if (m == NULL || m->m_len != 1 || + (loop = *(mtod(m, u_char *))) > 1) { + error = EINVAL; + break; + } + imo->imo_multicast_loop = loop; + break; + + case IP_ADD_MEMBERSHIP: + /* + * Add a multicast group membership. + * Group must be a valid IP multicast address. + */ + if (m == NULL || m->m_len != sizeof(struct ip_mreq)) { + error = EINVAL; + break; + } + mreq = mtod(m, struct ip_mreq *); + if (!IN_MULTICAST(ntohl(mreq->imr_multiaddr.s_addr))) { + error = EINVAL; + break; + } + /* + * If no interface address was provided, use the interface of + * the route to the given multicast address. + */ + if (mreq->imr_interface.s_addr == INADDR_ANY) { + ro.ro_rt = NULL; + dst = (struct sockaddr_in *)&ro.ro_dst; + dst->sin_family = AF_INET; + dst->sin_addr = mreq->imr_multiaddr; + rtalloc(&ro); + if (ro.ro_rt == NULL) { + error = EADDRNOTAVAIL; + break; + } + ifp = ro.ro_rt->rt_ifp; + rtfree(ro.ro_rt); + } + else { + INADDR_TO_IFP(mreq->imr_interface, ifp); + } + /* + * See if we found an interface, and confirm that it + * supports multicast. + */ + if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0) { + error = EADDRNOTAVAIL; + break; + } + /* + * See if the membership already exists or if all the + * membership slots are full. + */ + for (i = 0; i < imo->imo_num_memberships; ++i) { + if (imo->imo_membership[i]->inm_ifp == ifp && + imo->imo_membership[i]->inm_addr.s_addr + == mreq->imr_multiaddr.s_addr) + break; + } + if (i < imo->imo_num_memberships) { + error = EADDRINUSE; + break; + } + if (i == IP_MAX_MEMBERSHIPS) { + error = ETOOMANYREFS; + break; + } + /* + * Everything looks good; add a new record to the multicast + * address list for the given interface. + */ + if ((imo->imo_membership[i] = + in_addmulti(mreq->imr_multiaddr, ifp)) == NULL) { + error = ENOBUFS; + break; + } + ++imo->imo_num_memberships; + break; + + case IP_DROP_MEMBERSHIP: + /* + * Drop a multicast group membership. + * Group must be a valid IP multicast address. + */ + if (m == NULL || m->m_len != sizeof(struct ip_mreq)) { + error = EINVAL; + break; + } + mreq = mtod(m, struct ip_mreq *); + if (!IN_MULTICAST(ntohl(mreq->imr_multiaddr.s_addr))) { + error = EINVAL; + break; + } + /* + * If an interface address was specified, get a pointer + * to its ifnet structure. + */ + if (mreq->imr_interface.s_addr == INADDR_ANY) + ifp = NULL; + else { + INADDR_TO_IFP(mreq->imr_interface, ifp); + if (ifp == NULL) { + error = EADDRNOTAVAIL; + break; + } + } + /* + * Find the membership in the membership array. + */ + for (i = 0; i < imo->imo_num_memberships; ++i) { + if ((ifp == NULL || + imo->imo_membership[i]->inm_ifp == ifp) && + imo->imo_membership[i]->inm_addr.s_addr + == mreq->imr_multiaddr.s_addr) + break; + } + if (i == imo->imo_num_memberships) { + error = EADDRNOTAVAIL; + break; + } + /* + * Give up the multicast address record to which the + * membership points. + */ + in_delmulti(imo->imo_membership[i]); + /* + * Remove the gap in the membership array. + */ + for (++i; i < imo->imo_num_memberships; ++i) + imo->imo_membership[i-1] = imo->imo_membership[i]; + --imo->imo_num_memberships; + break; + + default: + error = EOPNOTSUPP; + break; + } + + /* + * If all options have default values, no need to keep the mbuf. + */ + if (imo->imo_multicast_ifp == NULL && + #ifdef RSVP_ISI + imo->imo_multicast_vif == 0 && + #endif RSVP_ISI + imo->imo_multicast_ttl == IP_DEFAULT_MULTICAST_TTL && + imo->imo_multicast_loop == IP_DEFAULT_MULTICAST_LOOP && + imo->imo_num_memberships == 0) { + m_free(*mopts); + *mopts = NULL; + } + + return(error); + } + + /* + * Return the IP multicast options in response to user getsockopt(). + */ + ip_getmoptions(optname, mopts, m) + int optname; + struct mbuf *mopts; + struct mbuf **m; + { + u_char *ttl; + u_char *loop; + struct in_addr *addr; + struct ip_moptions *imo; + struct in_ifaddr *ia; + + *m = m_get(M_WAIT, MT_IPMOPTS); + + imo = (mopts == NULL) ? NULL : mtod(mopts, struct ip_moptions *); + + switch (optname) { + + #ifdef RSVP_ISI + case IP_MULTICAST_VIF: + if (imo!=NULL) + *(mtod(*m, int *)) = imo->imo_multicast_vif; + else + *(mtod(*m, int *)) = 7890; + (*m)->m_len = sizeof(int); + return(0); + #endif RSVP_ISI + + case IP_MULTICAST_IF: + addr = mtod(*m, struct in_addr *); + (*m)->m_len = sizeof(struct in_addr); + if (imo == NULL || imo->imo_multicast_ifp == NULL) + addr->s_addr = INADDR_ANY; + else { + IFP_TO_IA(imo->imo_multicast_ifp, ia); + addr->s_addr = (ia == NULL) ? INADDR_ANY + : IA_SIN(ia)->sin_addr.s_addr; + } + return(0); + + case IP_MULTICAST_TTL: + ttl = mtod(*m, u_char *); + (*m)->m_len = 1; + *ttl = (imo == NULL) ? IP_DEFAULT_MULTICAST_TTL + : imo->imo_multicast_ttl; + return(0); + + case IP_MULTICAST_LOOP: + loop = mtod(*m, u_char *); + (*m)->m_len = 1; + *loop = (imo == NULL) ? IP_DEFAULT_MULTICAST_LOOP + : imo->imo_multicast_loop; + return(0); + + default: + return(EOPNOTSUPP); + } + } + + /* + * Discard the IP multicast options. + */ + ip_freemoptions(mopts) + struct mbuf *mopts; + { + struct ip_moptions *imo; + int i; + + if (mopts != NULL) { + imo = mtod(mopts, struct ip_moptions *); + for (i = 0; i < imo->imo_num_memberships; ++i) + in_delmulti(imo->imo_membership[i]); + m_free(mopts); + } + } + + /* + * Routine called from ip_output() to loop back a copy of an IP multicast + * packet to the input queue of a specified interface. Note that this + * calls the output routine of the loopback "driver", but with an interface + * pointer that might NOT be &loif -- easier than replicating that code here. + */ + ip_mloopback(ifp, m, dst) + struct ifnet *ifp; + register struct mbuf *m; + register struct sockaddr_in *dst; + { + register struct ip *ip; + struct mbuf *copym; + + copym = m_copy(m, 0, M_COPYALL); + if (copym != NULL) { + /* + * We don't bother to fragment if the IP length is greater + * than the interface's MTU. Can this possibly matter? + */ + ip = mtod(copym, struct ip *); + ip->ip_len = htons((u_short)ip->ip_len); + ip->ip_off = htons((u_short)ip->ip_off); + ip->ip_sum = 0; + ip->ip_sum = in_cksum(copym, ip->ip_hl << 2); + (void) looutput(ifp, copym, (struct sockaddr *)dst); + } + } + + #endif MULTICAST *** sys/net/netinet/udp_usrreq.c.orig Tue Feb 7 22:47:34 1995 --- sys/net/netinet/udp_usrreq.c Tue Feb 7 22:51:42 1995 *************** *** 1,5 **** --- 1,6 ---- #ifndef lint static char *sccsid = "@(#)udp_usrreq.c 8.2 (ULTRIX) 3/19/93"; + /* plus MULTICAST 1.2 */ #endif lint /************************************************************************ *************** *** 43,48 **** --- 44,52 ---- * they appear negative for very large datagrams. * * This includes fixes for cld 624. * * * + * 91/05/29 Mark J. Steiglitz, Stanford + * IP Multicast modifications from Ultrix 3.1 to Ultrix 4.1 + * * 25-Feb-91 jsd * account for all input packets, including error packets * *************** *** 257,262 **** --- 261,354 ---- mod_ui++; } + #ifdef MULTICAST + if (IN_MULTICAST(ntohl(ui->ui_dst.s_addr)) || + in_broadcast(ui->ui_dst)) { + struct socket *last; + /* + * Deliver a multicast or broadcast datagram to *all* sockets + * for which the local and remote addresses and ports match + * those of the incoming datagram. This allows more than + * one process to receive multi/broadcasts on the same port. + * (This really ought to be done for unicast datagrams as + * well, but that would cause problems with existing + * applications that open both address-specific sockets and + * a wildcard socket listening to the same port -- they would + * end up receiving duplicates of every unicast datagram. + * Those applications open the multiple sockets to overcome an + * inadequacy of the UDP socket interface, but for backwards + * compatibility we avoid the problem here rather than + * fixing the interface. Maybe 4.4BSD will remedy this?) + */ + + /* + * Construct sockaddr format source address. + */ + udp_in.sin_port = ui->ui_sport; + udp_in.sin_addr = ui->ui_src; + m->m_len -= sizeof (struct udpiphdr); + m->m_off += sizeof (struct udpiphdr); + /* + * Locate pcb(s) for datagram. + * (Algorithm copied from raw_intr().) + */ + last = NULL; + for (inp = udb.inp_next; inp != &udb; inp = inp->inp_next) { + if (inp->inp_lport != ui->ui_dport) { + continue; + } + if (inp->inp_laddr.s_addr != INADDR_ANY) { + if (inp->inp_laddr.s_addr != + ui->ui_dst.s_addr) + continue; + } + if (inp->inp_faddr.s_addr != INADDR_ANY) { + if (inp->inp_faddr.s_addr != + ui->ui_src.s_addr || + inp->inp_fport != ui->ui_sport) + continue; + } + + if (last != NULL) { + struct mbuf *n; + + if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { + if (sbappendaddr(&last->so_rcv, + (struct sockaddr *)&udp_in, + n, (struct mbuf *)0) == 0) + m_freem(n); + else + sorwakeup(last); + } + } + last = inp->inp_socket; + /* + * Don't look for additional matches if this one + * does not have the SO_REUSEADDR socket option set. + * This heuristic avoids searching through all pcbs + * in the common case of a non-shared port. It + * assumes that an application will never clear + * the SO_REUSEADDR option after setting it. + */ + if ((last->so_options & SO_REUSEADDR) == 0) + break; + } + + if (last == NULL) { + /* + * No matching pcb found; discard datagram. + * (No need to send an ICMP Port Unreachable + * for a broadcast or multicast datgram.) + */ + goto bad; + } + if (sbappendaddr(&last->so_rcv, (struct sockaddr *)&udp_in, + m, (struct mbuf *)0) == 0) + goto bad; + sorwakeup(last); + return; + } + #endif MULTICAST /* * Locate pcb for datagram. */ *************** *** 268,278 **** --- 360,372 ---- INPLOOKUP_WILDCARD); loop1: if (inp == 0) { smp_unlock(&lk_udb); + #ifndef MULTICAST /* don't send ICMP response for broadcast packet */ if (in_broadcast(ui->ui_dst)) { UDPSTAT(udps_noports++); goto bad; } + #endif !MULTICAST if (mod_ui) *(struct ip *)ui = ip; icmp_error((struct ip *)ui, ICMP_UNREACH, ICMP_UNREACH_PORT, *************** *** 470,478 **** --- 564,578 ---- ((struct ip *)ui)->ip_ttl = udp_ttl; UDPSTAT(udps_total++); UDPSTAT(udps_outdatagrams++); + #ifdef MULTICAST return (ip_output(m, inp->inp_options, &inp->inp_route, + inp->inp_socket->so_options & (SO_DONTROUTE | SO_BROADCAST) + | IP_MULTICASTOPTS, inp->inp_socket, inp->inp_moptions)); + #else + return (ip_output(m, inp->inp_options, &inp->inp_route, inp->inp_socket->so_options & (SO_DONTROUTE | SO_BROADCAST), inp->inp_socket)); + #endif MULTICAST } /* CJ - increased sendspace from 2K, recvspace from 4K */ *** sys/net/netinet/tcp_input.c.orig Mon Feb 13 13:23:09 1995 --- sys/net/netinet/tcp_input.c Tue Feb 7 22:53:50 1995 *************** *** 721,726 **** --- 721,727 ---- * Fill in remote peer address fields if not previously specified. * Enter SYN_RECEIVED state, and process any other fields of this * segment in this state. + * Make sure we do not process multicast datagrams. */ case TCPS_LISTEN: { struct mbuf *am; *************** *** 737,742 **** --- 738,748 ---- if (in_broadcast(ti->ti_dst)){ goto drop; } + #ifdef MULTICAST + if (IN_MULTICAST(ntohl(ti->ti_dst.s_addr))) + goto drop; + #endif MULTICAST + am = m_get(M_DONTWAIT, MT_SONAME); if (am == NULL){ goto drop; *** sys/net/netinet/raw_ip.c.orig Tue Feb 7 22:54:26 1995 --- sys/net/netinet/raw_ip.c Mon Feb 13 13:42:24 1995 *************** *** 119,125 **** --- 119,129 ---- * complete IP packet. Otherwise, allocate an mbuf for a * header and fill it in as needed. */ + #ifdef MULTICAST + if (proto != IPPROTO_RAW && proto != IPPROTO_IGMP) { + #else if (proto != IPPROTO_RAW) { + #endif MULTICAST /* * Calculate data length and get an mbuf * for IP header. *************** *** 163,170 **** --- 167,180 ---- } else ip->ip_src.s_addr = 0; ip->ip_dst = ((struct sockaddr_in *)&rp->rcb_faddr)->sin_addr; + #ifdef MULTICAST return (ip_output(m, rp->rcb_options, &rp->rcb_route, + (so->so_options & SO_DONTROUTE) | IP_ALLOWBROADCAST + | IP_MULTICASTOPTS, so, rp->rcb_moptions)); + #else + return (ip_output(m, rp->rcb_options, &rp->rcb_route, (so->so_options & SO_DONTROUTE) | IP_ALLOWBROADCAST, so)); + #endif MULTICAST bad: m_freem(m); return (error); *************** *** 192,199 **** --- 202,234 ---- case IP_OPTIONS: return (ip_pcbopts(&rp->rcb_options, *m)); + #ifdef RSVP_ISI + case IP_RSVP_ON: + error = ip_rsvp_init(so); + break; + case IP_RSVP_OFF: + error = ip_rsvp_done(); + break; + #endif RSVP_ISI + + #ifdef MULTICAST + case IP_MULTICAST_IF: + #ifdef RSVP_ISI + case IP_MULTICAST_VIF: + #endif RSVP_ISI + case IP_MULTICAST_TTL: + case IP_MULTICAST_LOOP: + case IP_ADD_MEMBERSHIP: + case IP_DROP_MEMBERSHIP: + error = ip_setmoptions(optname, &rp->rcb_moptions, *m); + break; + #endif MULTICAST default: + #ifdef MROUTING + error = ip_mrouter_cmd(optname, so, *m); + #else error = EINVAL; + #endif MROUTING break; } break; *************** *** 214,219 **** --- 249,267 ---- } else (*m)->m_len = 0; break; + #ifdef MULTICAST + case IP_MULTICAST_IF: + #ifdef RSVP_ISI + case IP_MULTICAST_VIF: + #endif RSVP_ISI + case IP_MULTICAST_TTL: + case IP_MULTICAST_LOOP: + case IP_ADD_MEMBERSHIP: + case IP_DROP_MEMBERSHIP: + error = ip_getmoptions(optname, rp->rcb_moptions, m); + break; + #endif MULTICAST + default: error = EINVAL; break; *** sys/net/netinet/igmp.c.orig Mon Feb 13 15:24:22 1995 --- sys/net/netinet/igmp.c Tue Feb 7 22:46:33 1995 *************** *** 0 **** --- 1,608 ---- + /* + * Internet Group Management Protocol (IGMP) routines. + * + * Written by Steve Deering, Stanford, May 1988. + * Modified by Rosen Sharma, Stanford, Aug 1994. + * + * MULTICAST 1.4 + */ + + #ifdef MULTICAST + + #include + #include + #include + #include + + #include + #include + + #include + #include "in_var.h" + #include + #include + #include + #include "igmp.h" + #include "igmp_var.h" + + + extern struct ifnet loif; + + static struct sockproto igmpproto = { AF_INET, IPPROTO_IGMP }; + static struct sockaddr_in igmpsrc = { AF_INET }; + static struct sockaddr_in igmpdst = { AF_INET }; + + static int igmp_timers_are_running = 0; + static u_long igmp_all_hosts_group; + static struct router_info *Head=0; + + igmp_init() + { + /* + * To avoid byte-swapping the same value over and over again. + */ + igmp_all_hosts_group = htonl(INADDR_ALLHOSTS_GROUP); + + Head = (struct router_info *) 0; + /* the random function has to be initialized with the address + of the host - I don't know where to get the host address + from when init is called */ + } + + int fill_rti(inm) + struct in_multi *inm; + { + register struct router_info *rti = Head; + struct mbuf *m; + + #ifdef IGMP_DEBUG + printf("[igmp.c, _fill_rti] --> entering \n"); + #endif + while (rti) { + if (rti->ifp == inm->inm_ifp){ /* ? is it ok to compare */ + /* pointers */ + inm->inm_rti = rti; + #ifdef IGMP_DEBUG + printf("[igmp.c, _fill_rti] --> found old entry \n"); + #endif + if (rti->type == IGMP_OLD_ROUTER) + return IGMP_HOST_MEMBERSHIP_REPORT; + else + return IGMP_HOST_NEW_MEMBERSHIP_REPORT; + } + rti = rti->next; + } + MGET(m,M_DONTWAIT,MT_DATA); + rti = mtod(m,struct router_info *); + rti->ifp = inm->inm_ifp; + rti->type = IGMP_NEW_ROUTER; + rti->time = IGMP_AGE_THRESHOLD; + rti->next = Head; + Head = rti; + inm->inm_rti = rti; + #ifdef IGMP_DEBUG + printf("[igmp.c, _fill_rti] --> created new entry \n"); + #endif + return IGMP_HOST_NEW_MEMBERSHIP_REPORT; + } + + struct router_info *find_rti(ifp) + struct ifnet *ifp; + { + register struct router_info *rti = Head; + struct mbuf *m; + + #ifdef IGMP_DEBUG + printf("[igmp.c, _find_rti] --> entering \n"); + #endif + while (rti) { + if (rti->ifp == ifp){ /* ? is it ok to compare pointers */ + #ifdef IGMP_DEBUG + printf("[igmp.c, _find_rti] --> found old entry \n"); + #endif + return rti; + } + rti = rti->next; + } + MGET(m,M_DONTWAIT,MT_DATA); + rti = mtod(m,struct router_info *); + rti->ifp = ifp; + rti->type = IGMP_NEW_ROUTER; + rti->time = IGMP_AGE_THRESHOLD; + rti->next = Head; + Head = rti; + #ifdef IGMP_DEBUG + printf("[igmp.c, _find_rti] --> created an entry \n"); + #endif + return rti; + } + + igmp_input(m, ifp) + register struct mbuf *m; + register struct ifnet *ifp; + { + register struct igmp *igmp; + register struct ip *ip; + register int igmplen; + register int iphlen; + register int minlen; + struct in_multi *inm; + struct in_multistep step; + struct in_ifaddr *ia; + struct router_info *rti; + + static int timer; /** timer value in the igmp query header **/ + + ++igmpstat.igps_rcv_total; + + ip = mtod(m, struct ip *); + iphlen = ip->ip_hl << 2; + igmplen = ip->ip_len; + + /* + * Validate lengths + */ + if (igmplen < IGMP_MINLEN) { + ++igmpstat.igps_rcv_tooshort; + m_freem(m); + return; + } + minlen = iphlen + IGMP_MINLEN; + if ((m->m_off > MMAXOFF || m->m_len < minlen) && + (m = m_pullup(m, minlen)) == 0) { + ++igmpstat.igps_rcv_tooshort; + return; + } + + /* + * Validate checksum + */ + m->m_off += iphlen; + m->m_len -= iphlen; + igmp = mtod(m, struct igmp *); + if (in_cksum(m, igmplen)) { + ++igmpstat.igps_rcv_badsum; + m_freem(m); + return; + } + m->m_off -= iphlen; + m->m_len += iphlen; + ip = mtod(m, struct ip *); + + timer = ntohs(igmp->igmp_code); + rti = find_rti(ifp); + + switch (igmp->igmp_type) { + + case IGMP_HOST_MEMBERSHIP_QUERY: + ++igmpstat.igps_rcv_queries; + + if (ifp == &loif) + break; + + if (igmp->igmp_code == 0) { + + rti->type = IGMP_OLD_ROUTER; rti->time = 0; + + /* + ** Do exactly as RFC 1112 says + */ + + if (ip->ip_dst.s_addr != igmp_all_hosts_group) { + ++igmpstat.igps_rcv_badqueries; + m_freem(m); + return; + } + + /* + * Start the timers in all of our membership records for + * the interface on which the query arrived, except those + * that are already running and those that belong to the + * "all-hosts" group. + */ + IN_FIRST_MULTI(step, inm); + while (inm != NULL) { + if (inm->inm_ifp == ifp && inm->inm_timer == 0 && + inm->inm_addr.s_addr != igmp_all_hosts_group) { + + inm->inm_state = IGMP_DELAYING_MEMBER; + inm->inm_timer = IGMP_RANDOM_DELAY( + IGMP_MAX_HOST_REPORT_DELAY * PR_FASTHZ ); + + igmp_timers_are_running = 1; + } + IN_NEXT_MULTI(step, inm); + } + } + else { + /* + ** New Router + */ + + if (ip->ip_dst.s_addr != igmp_all_hosts_group) { + if (!IN_MULTICAST(ip->ip_dst.s_addr)) { + ++igmpstat.igps_rcv_badqueries; + m_freem(m); + return; + } + } + if (ip->ip_dst.s_addr == igmp_all_hosts_group){ + + /* + * - Start the timers in all of our membership records + * for the interface on which the query arrived + * excl. those that belong to the "all-hosts" group. + * - For timers already running check if they need to + * be reset. + * - Use the igmp->igmp_code filed as the maximum + * delay possible + */ + IN_FIRST_MULTI(step, inm); + while (inm != NULL){ + switch(inm->inm_state){ + case IGMP_IDLE_MEMBER: + case IGMP_LAZY_MEMBER: + case IGMP_AWAKENING_MEMBER: + if (inm->inm_ifp == ifp && + inm->inm_addr.s_addr != + igmp_all_hosts_group) { + inm->inm_timer = IGMP_RANDOM_DELAY(timer); + igmp_timers_are_running = 1; + inm->inm_state = IGMP_DELAYING_MEMBER; + } + break; + case IGMP_DELAYING_MEMBER: + if (inm->inm_ifp == ifp && + (inm->inm_timer > + timer * PR_FASTHZ / IGMP_TIMER_SCALE) + && + inm->inm_addr.s_addr != + igmp_all_hosts_group) { + inm->inm_timer = IGMP_RANDOM_DELAY(timer); + igmp_timers_are_running = 1; + inm->inm_state = IGMP_DELAYING_MEMBER; + } + break; + case IGMP_SLEEPING_MEMBER: + inm->inm_state = IGMP_AWAKENING_MEMBER; + break; + } + IN_NEXT_MULTI(step, inm); + } + } + else { + /* + ** group specific query + */ + + IN_FIRST_MULTI(step, inm); + while (inm != NULL) { + if (inm->inm_addr.s_addr == ip->ip_dst.s_addr) { + switch(inm->inm_state ){ + case IGMP_IDLE_MEMBER: + case IGMP_LAZY_MEMBER: + case IGMP_AWAKENING_MEMBER: + inm->inm_state = IGMP_DELAYING_MEMBER; + if (inm->inm_ifp == ifp ) { + inm->inm_timer = IGMP_RANDOM_DELAY(timer); + igmp_timers_are_running = 1; + inm->inm_state = IGMP_DELAYING_MEMBER; + } + break; + case IGMP_DELAYING_MEMBER: + inm->inm_state = IGMP_DELAYING_MEMBER; + if (inm->inm_ifp == ifp && + (inm->inm_timer > + timer * PR_FASTHZ / IGMP_TIMER_SCALE) ) { + inm->inm_timer = IGMP_RANDOM_DELAY(timer); + igmp_timers_are_running = 1; + inm->inm_state = IGMP_DELAYING_MEMBER; + } + break; + case IGMP_SLEEPING_MEMBER: + inm->inm_state = IGMP_AWAKENING_MEMBER; + break; + } + } + IN_NEXT_MULTI(step, inm); + } + } + } + break; + + case IGMP_HOST_MEMBERSHIP_REPORT: + ++igmpstat.igps_rcv_reports; + + /* + ** an old report + */ + + + if (ifp == &loif) + break; + + if (!IN_MULTICAST(ntohl(igmp->igmp_group.s_addr)) || + igmp->igmp_group.s_addr != ip->ip_dst.s_addr) { + ++igmpstat.igps_rcv_badreports; + m_freem(m); + return; + } + + /* + * KLUDGE: if the IP source address of the report has an + * unspecified (i.e., zero) subnet number, as is allowed for + * a booting host, replace it with the correct subnet number + * so that a process-level multicast routing demon can + * determine which subnet it arrived from. This is necessary + * to compensate for the lack of any way for a process to + * determine the arrival interface of an incoming packet. + */ + if ((ntohl(ip->ip_src.s_addr) & IN_CLASSA_NET) == 0) { + IFP_TO_IA(ifp, ia); + if (ia) ip->ip_src.s_addr = htonl(ia->ia_subnet); + } + + /* + * If we belong to the group being reported, stop + * our timer for that group. + */ + IN_LOOKUP_MULTI(igmp->igmp_group, ifp, inm); + if (inm != NULL) { + inm->inm_timer = 0; + ++igmpstat.igps_rcv_ourreports; + } + + if (inm != NULL) { + inm->inm_timer = 0; + ++igmpstat.igps_rcv_ourreports; + + switch(inm->inm_state){ + case IGMP_IDLE_MEMBER: + case IGMP_LAZY_MEMBER: + case IGMP_AWAKENING_MEMBER: + case IGMP_SLEEPING_MEMBER: + inm->inm_state = IGMP_SLEEPING_MEMBER; + break; + case IGMP_DELAYING_MEMBER: + /** check this out - this was if (oldrouter) **/ + if (inm->inm_rti->type == IGMP_OLD_ROUTER) + inm->inm_state = IGMP_LAZY_MEMBER; + else inm->inm_state = IGMP_SLEEPING_MEMBER; + break; + } + } + + break; + + case IGMP_HOST_NEW_MEMBERSHIP_REPORT: + /* + * an new report + */ + ++igmpstat.igps_rcv_reports; + + if (ifp == &loif) + break; + + if (!IN_MULTICAST(ntohl(igmp->igmp_group.s_addr)) || + igmp->igmp_group.s_addr != ip->ip_dst.s_addr) { + ++igmpstat.igps_rcv_badreports; + m_freem(m); + return; + } + + /* + * KLUDGE: if the IP source address of the report has an + * unspecified (i.e., zero) subnet number, as is allowed for + * a booting host, replace it with the correct subnet number + * so that a process-level multicast routing demon can + * determine which subnet it arrived from. This is necessary + * to compensate for the lack of any way for a process to + * determine the arrival interface of an incoming packet. + */ + if ((ntohl(ip->ip_src.s_addr) & IN_CLASSA_NET) == 0) { + IFP_TO_IA(ifp, ia); + if (ia) ip->ip_src.s_addr = htonl(ia->ia_subnet); + } + + /* + * If we belong to the group being reported, stop + * our timer for that group. + */ + IN_LOOKUP_MULTI(igmp->igmp_group, ifp, inm); + if (inm != NULL) { + inm->inm_timer = 0; + ++igmpstat.igps_rcv_ourreports; + + switch(inm->inm_state){ + case IGMP_DELAYING_MEMBER: + case IGMP_IDLE_MEMBER: + inm->inm_state = IGMP_LAZY_MEMBER; + break; + case IGMP_AWAKENING_MEMBER: + inm->inm_state = IGMP_LAZY_MEMBER; + break; + case IGMP_LAZY_MEMBER: + case IGMP_SLEEPING_MEMBER: + break; + } + } + } + + /* + * Pass all valid IGMP packets up to any process(es) listening + * on a raw IGMP socket. + */ + igmpsrc.sin_addr = ip->ip_src; + igmpdst.sin_addr = ip->ip_dst; + raw_input(m, &igmpproto, + (struct sockaddr *)&igmpsrc, (struct sockaddr *)&igmpdst); + } + + igmp_joingroup(inm) + struct in_multi *inm; + { + int s = splnet(); + + inm->inm_state = IGMP_IDLE_MEMBER; + + if (inm->inm_addr.s_addr == igmp_all_hosts_group || + inm->inm_ifp == &loif) + inm->inm_timer = 0; + else { + igmp_sendpkt(inm,fill_rti(inm)); + inm->inm_timer = IGMP_RANDOM_DELAY( + IGMP_MAX_HOST_REPORT_DELAY*PR_FASTHZ); + inm->inm_state = IGMP_DELAYING_MEMBER; + igmp_timers_are_running = 1; + } + splx(s); + } + + igmp_leavegroup(inm) + struct in_multi *inm; + { + /* + * No action required on leaving a group. + */ + switch(inm->inm_state){ + case IGMP_DELAYING_MEMBER: + case IGMP_IDLE_MEMBER: + if (!(inm->inm_addr.s_addr == igmp_all_hosts_group || + inm->inm_ifp == &loif)) + if (inm->inm_rti->type != IGMP_OLD_ROUTER) + igmp_sendleave(inm); + break; + case IGMP_LAZY_MEMBER: + case IGMP_AWAKENING_MEMBER: + case IGMP_SLEEPING_MEMBER: + break; + } + } + + igmp_fasttimo() + { + register struct in_multi *inm; + struct in_multistep step; + int s; + + /* + * Quick check to see if any work needs to be done, in order + * to minimize the overhead of fasttimo processing. + */ + + if (!igmp_timers_are_running) + return; + + s = splnet(); + igmp_timers_are_running = 0; + IN_FIRST_MULTI(step, inm); + while (inm != NULL) { + if (inm->inm_timer == 0) { + /* do nothing */ + } + else if (--inm->inm_timer == 0) { + if (inm->inm_state == IGMP_DELAYING_MEMBER) { + if (inm->inm_rti->type == IGMP_OLD_ROUTER) + igmp_sendpkt(inm, IGMP_HOST_MEMBERSHIP_REPORT); + else + igmp_sendpkt(inm, IGMP_HOST_NEW_MEMBERSHIP_REPORT); + inm->inm_state = IGMP_IDLE_MEMBER; + } + } + else { + igmp_timers_are_running = 1; + } + IN_NEXT_MULTI(step, inm); + } + splx(s); + } + + igmp_slowtimo() + { + int s = splnet(); + register struct router_info *rti = Head; + + #ifdef IGMP_DEBUG + printf("[igmp.c,_slowtimo] -- > entering \n"); + #endif + while (rti) { + rti->time ++; + if (rti->time >= IGMP_AGE_THRESHOLD){ + rti->type = IGMP_NEW_ROUTER; + rti->time = IGMP_AGE_THRESHOLD; + } + rti = rti->next; + } + #ifdef IGMP_DEBUG + printf("[igmp.c,_slowtimo] -- > exiting \n"); + #endif + splx(s); + } + + igmp_sendpkt(inm, type) + struct in_multi *inm; int type; + { + struct mbuf *m; + struct igmp *igmp; + struct ip *ip; + struct mbuf *mopts; + struct ip_moptions *imo; + #ifdef MROUTING + extern struct socket *ip_mrouter; + #endif MROUTING + + MGET(m, M_DONTWAIT, MT_HEADER); + if (m == NULL) + return; + MGET(mopts, M_DONTWAIT, MT_IPMOPTS); + if (mopts == NULL) { + m_free(m); + return; + } + m->m_off = roundup(MMINOFF, 8) + 16 + sizeof(struct ip); + m->m_len = IGMP_MINLEN; + igmp = mtod(m, struct igmp *); + igmp->igmp_type = type; + igmp->igmp_code = 0; + igmp->igmp_group = inm->inm_addr; + igmp->igmp_cksum = 0; + igmp->igmp_cksum = in_cksum(m, IGMP_MINLEN); + + m->m_off -= sizeof(struct ip); + m->m_len += sizeof(struct ip); + ip = mtod(m, struct ip *); + ip->ip_tos = 0; + ip->ip_len = sizeof(struct ip) + IGMP_MINLEN; + ip->ip_off = 0; + ip->ip_p = IPPROTO_IGMP; + ip->ip_src.s_addr = INADDR_ANY; + ip->ip_dst = igmp->igmp_group; + + imo = mtod(mopts, struct ip_moptions *); + imo->imo_multicast_ifp = inm->inm_ifp; + imo->imo_multicast_ttl = 1; + /* + * Request loopback of the report if we are acting as a multicast + * router, so that the process-level routing demon can hear it. + */ + #ifdef MROUTING + imo->imo_multicast_loop = (ip_mrouter != NULL); + #else + imo->imo_multicast_loop = 0; + #endif MROUTING + + ip_output(m, (struct mbuf *)0, (struct route *)0, + IP_MULTICASTOPTS, mopts); + + m_free(mopts); + ++igmpstat.igps_snd_reports; + + } + + + igmp_sendleave(inm) + struct in_multi *inm; + { + igmp_sendpkt(inm, IGMP_HOST_LEAVE_MESSAGE); + } + #endif MULTICAST *** sys/net/netinet/ip_mroute.c.orig Mon Feb 13 15:25:44 1995 --- sys/net/netinet/ip_mroute.c Tue Feb 7 22:46:34 1995 *************** *** 0 **** --- 1,1855 ---- + /* + * IP multicast forwarding procedures + * + * Written by David Waitzman, BBN Labs, August 1988. + * Modified by Steve Deering, Stanford, February 1989. + * Modified by Mark J. Steiglitz, Stanford, May, 1991 + * Modified by Van Jacobson, LBL, January 1993 + * Modified by Ajit Thyagarajan, PARC, August 1993 + * + * MROUTING 1.8 + */ + + #ifdef MULTICAST + + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + + #ifndef NTOHL + #if defined(ultrix) || defined(i386) + #define NTOHL(d) ((d) = ntohl((d))) + #define NTOHS(d) ((d) = ntohs((u_short)(d))) + #define HTONL(d) ((d) = htonl((d))) + #define HTONS(d) ((d) = htons((u_short)(d))) + #else + #define NTOHL(d) + #define NTOHS(d) + #define HTONL(d) + #define HTONS(d) + #endif + #endif + + #ifndef MROUTING + /* + * Dummy routines and globals used when multicast routing is not compiled in. + */ + + struct socket *ip_mrouter = NULL; + u_int ip_mrtproto = 0; + + int + ip_mrouter_cmd(cmd, so, m) + int cmd; + struct socket *so; + struct mbuf *m; + { + return(EOPNOTSUPP); + } + + int + ip_mrouter_done() + { + return(0); + } + + int + ip_mforward(ip, ifp, m) + struct ip *ip; + struct ifnet *ifp; + struct mbuf *m; + { + return(0); + } + #else MROUTING + + static int ip_mdq(); + static void phyint_send(); + static void srcrt_send(); + static void encap_send(); + + int multiencap_decap(); + + #define INSIZ sizeof(struct in_addr) + #define same(a1, a2) \ + (bcmp((caddr_t)(a1), (caddr_t)(a2), INSIZ) == 0) + + /* + * Globals. All but ip_mrouter and ip_mrtproto could be static, + * except for netstat or debugging purposes. + */ + struct socket *ip_mrouter = NULL; + int ip_mrtproto = IGMP_DVMRP; /* for netstat only */ + + #define NO_RTE_FOUND 0x1 + #define RTE_FOUND 0x2 + + struct mbuf *mfctable[MFCTBLSIZ]; + struct vif viftable[MAXVIFS]; + struct mrtstat mrtstat; + u_int mrtdebug = 0; /* debug level */ + u_int tbfdebug = 0; /* tbf debug level */ + + u_long timeout_val = 0; /* count of outstanding upcalls */ + static void cleanup_cache(); + + /* + * Define the token bucket filter structures + * tbftable -> each vif has one of these for storing info + * qtable -> each interface has an associated queue of pkts + */ + + struct tbf tbftable[MAXVIFS]; + struct pkt_queue qtable[MAXVIFS][MAXQSIZE]; + + void tbf_control(); + void tbf_queue(); + void tbf_dequeue(); + void tbf_process_q(); + void tbf_reprocess_q(); + int tbf_dq_sel(); + void tbf_send_packet(); + void tbf_update_tokens(); + u_long packet_length(); + int priority(); + + /* + * 'Interfaces' associated with decapsulator (so we can tell + * packets that went through it from ones that get reflected + * by a broken gateway). These interfaces are never linked into + * the system ifnet list & no routes point to them. I.e., packets + * can't be sent this way. They only exist as a placeholder for + * multicast source verification. + */ + struct ifnet multicast_decap_if[MAXVIFS]; + + #define ENCAP_TTL 64 + #define ENCAP_PROTO 4 + + /* prototype IP hdr for encapsulated packets */ + struct ip multicast_encap_iphdr = { + #if defined(ultrix) || defined(i386) + sizeof(struct ip) >> 2, IPVERSION, + #else + IPVERSION, sizeof(struct ip) >> 2, + #endif + 0, /* tos */ + sizeof(struct ip), /* total length */ + 0, /* id */ + 0, /* frag offset */ + ENCAP_TTL, ENCAP_PROTO, + 0, /* checksum */ + }; + + /* + * Private variables. + */ + static vifi_t numvifs = 0; + static int (*encap_oldrawip)(); + + /* + * one-back cache used by multiencap_decap to locate a tunnel's vif + * given a datagram's src ip address. + */ + static u_long last_encap_src; + static struct vif *last_encap_vif; + + /* + * A simple hash function: returns MFCHASHMOD of the low-order octet of + * the argument's network or subnet number and the multicast group assoc. + */ + static u_long + nethash_fc(m,n) + register u_long m; + register u_long n; + { + struct in_addr in1; + struct in_addr in2; + + in1.s_addr = m; + m = in_netof(in1); + while ((m & 0xff) == 0) m >>= 8; + + in2.s_addr = n; + n = in_netof(in2); + while ((n & 0xff) == 0) n >>= 8; + + return (MFCHASHMOD(m) ^ MFCHASHMOD(n)); + } + + /* + * this is a direct-mapped cache used to speed the mapping from a + * datagram source address to the associated multicast route. Note + * that unlike mrttable, the hash is on IP address, not IP net number. + */ + #define MFCHASHSIZ 1024 + #define MFCHASH(a, g) ((((a) >> 20) ^ ((a) >> 10) ^ (a) ^ \ + ((g) >> 20) ^ ((g) >> 10) ^ (g)) & (MFCHASHSIZ-1)) + struct mfc *mfchash[MFCHASHSIZ]; + + /* + * Find a route for a given origin IP address and Multicast group address + * Type of service parameter to be added in the future!!! + */ + #define MFCFIND(o, g, rt) { \ + register u_int _mrhasho = o; \ + register u_int _mrhashg = g; \ + _mrhasho = MFCHASH(_mrhasho, _mrhashg); \ + ++mrtstat.mrts_mfc_lookups; \ + rt = mfchash[_mrhasho]; \ + if ((rt == NULL) || \ + ((o & rt->mfc_originmask.s_addr) != rt->mfc_origin.s_addr) || \ + (g != rt->mfc_mcastgrp.s_addr)) \ + if ((rt = mfcfind(o, g)) != NULL) \ + mfchash[_mrhasho] = rt; \ + } + + /* + * Find route by examining hash table entries + */ + static struct mfc * + mfcfind(origin, mcastgrp) + u_long origin; + u_long mcastgrp; + { + register struct mbuf *mb_rt; + register struct mfc *rt; + register u_long hash; + + hash = nethash_fc(origin, mcastgrp); + for (mb_rt = mfctable[hash]; mb_rt; mb_rt = mb_rt->m_next) { + rt = mtod(mb_rt, struct mfc *); + if (((origin & rt->mfc_originmask.s_addr) == rt->mfc_origin.s_addr) && + (mcastgrp == rt->mfc_mcastgrp.s_addr) && + (mb_rt->m_act == NULL)) + return (rt); + } + mrtstat.mrts_mfc_misses++; + return NULL; + } + + /* + * Macros to compute elapsed time efficiently + * Borrowed from Van Jacobson's scheduling code + */ + #define TV_DELTA(a, b, delta) { \ + register int xxs; \ + \ + delta = (a).tv_usec - (b).tv_usec; \ + if ((xxs = (a).tv_sec - (b).tv_sec)) { \ + switch (xxs) { \ + case 2: \ + delta += 1000000; \ + /* fall through */ \ + case 1: \ + delta += 1000000; \ + break; \ + default: \ + delta += (1000000 * xxs); \ + } \ + } \ + } + + #define TV_LT(a, b) (((a).tv_usec < (b).tv_usec && \ + (a).tv_sec <= (b).tv_sec) || (a).tv_sec < (b).tv_sec) + + /* + * Handle DVMRP setsockopt commands to modify the multicast routing tables. + */ + int + ip_mrouter_cmd(cmd, so, m) + int cmd; + struct socket *so; + struct mbuf *m; + { + if (cmd != DVMRP_INIT && so != ip_mrouter) return EACCES; + + switch (cmd) { + case DVMRP_INIT: return ip_mrouter_init(so); + case DVMRP_DONE: return ip_mrouter_done(); + case DVMRP_ADD_VIF: return add_vif (mtod(m, struct vifctl *)); + case DVMRP_DEL_VIF: return del_vif (mtod(m, vifi_t *)); + case DVMRP_ADD_MFC: return add_mfc (mtod(m, struct mfcctl *)); + case DVMRP_DEL_MFC: return del_mfc (mtod(m, struct delmfcctl *)); + default: return EOPNOTSUPP; + } + } + + + /* + * Handle ioctl commands to obtain information from the cache + */ + int + mrt_ioctl(cmd, data) + int cmd; + caddr_t data; + { + int error = 0; + + switch (cmd) { + #ifdef RSVP_ISI + case (SIOCGETVIFINF): /* Read Virtual Interface (m/cast) */ + return (get_vifs(data)); + break; + #endif RSVP_ISI + case (SIOCGETVIFCNT): + return (get_vif_cnt((struct sioc_vif_req *)data)); + break; + case (SIOCGETSGCNT): + return (get_sg_cnt((struct sioc_sg_req *)data)); + break; + default: + return (EINVAL); + break; + } + return error; + } + + /* + * returns the packet count for the source group provided + */ + int + get_sg_cnt(req) + register struct sioc_sg_req *req; + { + register struct mfc *rt; + int s; + + s = splnet(); + MFCFIND(req->src.s_addr, req->grp.s_addr, rt); + splx(s); + if (rt != NULL) + req->count = rt->mfc_pkt_cnt; + else + req->count = 0xffffffff; + + return 0; + } + + /* + * returns the input and output packet counts on the interface provided + */ + int + get_vif_cnt(req) + register struct sioc_vif_req *req; + { + register vifi_t vifi = req->vifi; + + req->icount = viftable[vifi].v_pkt_in; + req->ocount = viftable[vifi].v_pkt_out; + + return 0; + } + + #ifdef RSVP_ISI + int + get_vifs(data) + char *data; + { + register struct vif_conf *vifc = (struct vif_conf *)data; + register struct vif_req *vifrp, vifr; + int space, error=0; + + vifi_t vifi; + int s; + + space = vifc->vifc_len; + vifrp = vifc->vifc_req; + + s = splnet(); + vifc->vifc_num=numvifs; + + for (vifi = 0; vifi < numvifs; vifi++, vifrp++) { + if (viftable[vifi].v_lcl_addr.s_addr != 0) { + vifr.v_flags=viftable[vifi].v_flags; + vifr.v_threshold=viftable[vifi].v_threshold; + vifr.v_lcl_addr=viftable[vifi].v_lcl_addr; + vifr.v_rmt_addr=viftable[vifi].v_rmt_addr; + strncpy(vifr.v_if_name,viftable[vifi].v_ifp->if_name,IFNAMSIZ); + if ((space -= sizeof(vifr)) < 0) { + splx(s); + return(ENOSPC); + } + error = copyout((caddr_t)&vifr,(caddr_t)vifrp,(u_int)(sizeof vifr)); + if (error) { + splx(s); + return(error); + } + } + } + splx(s); + return 0; + } + #endif RSVP_ISI + /* + * Enable multicast routing + */ + static int + ip_mrouter_init(so) + struct socket *so; + { + if (so->so_type != SOCK_RAW || + so->so_proto->pr_protocol != IPPROTO_IGMP) return EOPNOTSUPP; + + if (ip_mrouter != NULL) return EADDRINUSE; + + ip_mrouter = so; + + if (mrtdebug) + log(LOG_DEBUG, "ip_mrouter_init"); + + return 0; + } + + /* + * Disable multicast routing + */ + int + ip_mrouter_done() + { + vifi_t vifi; + int i; + struct ifnet *ifp; + struct ifreq ifr; + struct mbuf *mb_rt; + struct mbuf *m; + struct rtdetq *rte; + int s; + + s = splnet(); + + /* + * For each phyint in use, disable promiscuous reception of all IP + * multicasts. + */ + for (vifi = 0; vifi < numvifs; vifi++) { + if (viftable[vifi].v_lcl_addr.s_addr != 0 && + !(viftable[vifi].v_flags & VIFF_TUNNEL)) { + ((struct sockaddr_in *)&(ifr.ifr_addr))->sin_family = AF_INET; + ((struct sockaddr_in *)&(ifr.ifr_addr))->sin_addr.s_addr + = INADDR_ANY; + ifp = viftable[vifi].v_ifp; + (*ifp->if_ioctl)(ifp, SIOCDELMULTI, (caddr_t)&ifr); + } + } + bzero((caddr_t)qtable, sizeof(qtable)); + bzero((caddr_t)tbftable, sizeof(tbftable)); + bzero((caddr_t)viftable, sizeof(viftable)); + numvifs = 0; + + /* + * Check if any outstanding timeouts remain + */ + if (timeout_val != 0) + for (i = 0; i < MFCTBLSIZ; i++) { + mb_rt = mfctable[i]; + while (mb_rt) { + if ( mb_rt->m_act != NULL) { + untimeout(cleanup_cache, (caddr_t)mb_rt); + while (m = mb_rt->m_act) { + mb_rt->m_act = m->m_act; + rte = mtod(m, struct rtdetq *); + m_freem(rte->m); + m_free(m); + } + timeout_val--; + } + mb_rt = mb_rt->m_next; + } + if (timeout_val == 0) + break; + } + + /* + * Free all multicast forwarding cache entries. + */ + for (i = 0; i < MFCTBLSIZ; i++) + m_freem(mfctable[i]); + + bzero((caddr_t)mfctable, sizeof(mfctable)); + bzero((caddr_t)mfchash, sizeof(mfchash)); + + /* + * Reset de-encapsulation cache + */ + last_encap_src = NULL; + last_encap_vif = NULL; + + ip_mrouter = NULL; + + splx(s); + + if (mrtdebug) + log(LOG_DEBUG, "ip_mrouter_done"); + + return 0; + } + + /* + * Add a vif to the vif table + */ + static int + add_vif(vifcp) + register struct vifctl *vifcp; + { + register struct vif *vifp = viftable + vifcp->vifc_vifi; + static struct sockaddr_in sin = {AF_INET}; + struct ifaddr *ifa; + struct ifnet *ifp; + struct ifreq ifr; + int error, s; + struct tbf *v_tbf = tbftable + vifcp->vifc_vifi; + + if (vifcp->vifc_vifi >= MAXVIFS) return EINVAL; + if (vifp->v_lcl_addr.s_addr != 0) return EADDRINUSE; + + /* Find the interface with an address in AF_INET family */ + sin.sin_addr = vifcp->vifc_lcl_addr; + ifa = ifa_ifwithaddr(&sin); + if (ifa == 0) return EADDRNOTAVAIL; + ifp = ifa->ifa_ifp; + + if (vifcp->vifc_flags & VIFF_TUNNEL) { + if ((vifcp->vifc_flags & VIFF_SRCRT) == 0) { + /* + * An encapsulating tunnel is wanted. If we haven't done so + * already, put our decap routine in front of raw_input so we + * have a chance to decapsulate incoming packets. Then set + * the arrival 'interface' to be the decapsulator. + */ + if (encap_oldrawip == 0) { + extern u_char ip_protox[]; + register int pr = ip_protox[ENCAP_PROTO]; + + encap_oldrawip = inetsw[pr].pr_input; + inetsw[pr].pr_input = multiencap_decap; + for (s = 0; s < MAXVIFS; ++s) { + multicast_decap_if[s].if_name = "mdecap"; + multicast_decap_if[s].if_unit = s; + } + } + ifp = &multicast_decap_if[vifcp->vifc_vifi]; + } else { + ifp = 0; + } + } else { + /* Make sure the interface supports multicast */ + if ((ifp->if_flags & IFF_MULTICAST) == 0) + return EOPNOTSUPP; + + /* Enable promiscuous reception of all IP multicasts from the if */ + ((struct sockaddr_in *)&(ifr.ifr_addr))->sin_family = AF_INET; + ((struct sockaddr_in *)&(ifr.ifr_addr))->sin_addr.s_addr = INADDR_ANY; + s = splnet(); + error = (*ifp->if_ioctl)(ifp, SIOCADDMULTI, (caddr_t)&ifr); + splx(s); + if (error) + return error; + } + + s = splnet(); + /* define parameters for the tbf structure */ + vifp->v_tbf = v_tbf; + vifp->v_tbf->q_len = 0; + vifp->v_tbf->n_tok = 0; + vifp->v_tbf->last_pkt_t = 0; + + vifp->v_flags = vifcp->vifc_flags; + vifp->v_threshold = vifcp->vifc_threshold; + vifp->v_lcl_addr = vifcp->vifc_lcl_addr; + vifp->v_rmt_addr = vifcp->vifc_rmt_addr; + vifp->v_ifp = ifp; + vifp->v_rate_limit= vifcp->vifc_rate_limit; + /* initialize per vif pkt counters */ + vifp->v_pkt_in = 0; + vifp->v_pkt_out = 0; + splx(s); + + /* Adjust numvifs up if the vifi is higher than numvifs */ + if (numvifs <= vifcp->vifc_vifi) numvifs = vifcp->vifc_vifi + 1; + + if (mrtdebug) + log(LOG_DEBUG, "add_vif #%d, lcladdr %x, %s %x, thresh %x, rate %d", + vifcp->vifc_vifi, + ntohl(vifcp->vifc_lcl_addr.s_addr), + (vifcp->vifc_flags & VIFF_TUNNEL) ? "rmtaddr" : "mask", + ntohl(vifcp->vifc_rmt_addr.s_addr), + vifcp->vifc_threshold, + vifcp->vifc_rate_limit); + + return 0; + } + + /* + * Delete a vif from the vif table + */ + static int + del_vif(vifip) + vifi_t *vifip; + { + register struct vif *vifp = viftable + *vifip; + register vifi_t vifi; + struct ifnet *ifp; + struct ifreq ifr; + int s; + + if (*vifip >= numvifs) return EINVAL; + if (vifp->v_lcl_addr.s_addr == 0) return EADDRNOTAVAIL; + + s = splnet(); + + if (!(vifp->v_flags & VIFF_TUNNEL)) { + ((struct sockaddr_in *)&(ifr.ifr_addr))->sin_family = AF_INET; + ((struct sockaddr_in *)&(ifr.ifr_addr))->sin_addr.s_addr = INADDR_ANY; + ifp = vifp->v_ifp; + (*ifp->if_ioctl)(ifp, SIOCDELMULTI, (caddr_t)&ifr); + } + + if (vifp == last_encap_vif) { + last_encap_vif = 0; + last_encap_src = 0; + } + + bzero((caddr_t)qtable[*vifip], + sizeof(qtable[*vifip])); + bzero((caddr_t)vifp->v_tbf, sizeof(*(vifp->v_tbf))); + bzero((caddr_t)vifp, sizeof (*vifp)); + + /* Adjust numvifs down */ + for (vifi = numvifs; vifi > 0; vifi--) + if (viftable[vifi-1].v_lcl_addr.s_addr != 0) break; + numvifs = vifi; + + splx(s); + + if (mrtdebug) + log(LOG_DEBUG, "del_vif %d, numvifs %d", *vifip, numvifs); + + return 0; + } + + /* + * Add an mfc entry + */ + static int + add_mfc(mfccp) + struct mfcctl *mfccp; + { + struct mfc *rt; + struct mfc *rt1; + register struct mbuf *mb_rt; + struct mbuf *prev_mb_rt; + u_long hash; + struct mbuf *mb_ntry; + struct rtdetq *rte; + register u_short nstl; + int s; + int i; + + rt = mfcfind(mfccp->mfcc_origin.s_addr, mfccp->mfcc_mcastgrp.s_addr); + + /* If an entry already exists, just update the fields */ + if (rt) { + if (mrtdebug) + log(LOG_DEBUG,"add_mfc update o %x g %x m %x p %x", + ntohl(mfccp->mfcc_origin.s_addr), + ntohl(mfccp->mfcc_mcastgrp.s_addr), + ntohl(mfccp->mfcc_originmask.s_addr), + mfccp->mfcc_parent); + + s = splnet(); + rt->mfc_parent = mfccp->mfcc_parent; + for (i = 0; i < numvifs; i++) + VIFM_COPY(mfccp->mfcc_ttls[i], rt->mfc_ttls[i]); + splx(s); + return 0; + } + + /* + * Find the entry for which the upcall was made and update + */ + s = splnet(); + hash = nethash_fc(mfccp->mfcc_origin.s_addr, mfccp->mfcc_mcastgrp.s_addr); + for (prev_mb_rt = mb_rt = mfctable[hash], nstl = 0; + mb_rt; prev_mb_rt = mb_rt, mb_rt = mb_rt->m_next) { + + rt = mtod(mb_rt, struct mfc *); + if (((rt->mfc_origin.s_addr & mfccp->mfcc_originmask.s_addr) + == mfccp->mfcc_origin.s_addr) && + (rt->mfc_mcastgrp.s_addr == mfccp->mfcc_mcastgrp.s_addr) && + (mb_rt->m_act != NULL)) { + + if (!nstl++) { + if (mrtdebug) + log(LOG_DEBUG,"add_mfc o %x g %x m %x p %x dbg %x", + ntohl(mfccp->mfcc_origin.s_addr), + ntohl(mfccp->mfcc_mcastgrp.s_addr), + ntohl(mfccp->mfcc_originmask.s_addr), + mfccp->mfcc_parent, mb_rt->m_act); + + rt->mfc_origin = mfccp->mfcc_origin; + rt->mfc_originmask = mfccp->mfcc_originmask; + rt->mfc_mcastgrp = mfccp->mfcc_mcastgrp; + rt->mfc_parent = mfccp->mfcc_parent; + for (i = 0; i < numvifs; i++) + VIFM_COPY(mfccp->mfcc_ttls[i], rt->mfc_ttls[i]); + /* initialize pkt counters per src-grp */ + rt->mfc_pkt_cnt = 0; + rt1 = rt; + } + + /* prevent cleanup of cache entry */ + untimeout(cleanup_cache, (caddr_t)mb_rt); + timeout_val--; + + /* free packets Qed at the end of this entry */ + while (mb_rt->m_act) { + mb_ntry = mb_rt->m_act; + rte = mtod(mb_ntry, struct rtdetq *); + #ifdef RSVP_ISI + ip_mdq(rte->m, rte->ifp, rte->tunnel_src, + rt1, rte->imo); + #else + ip_mdq(rte->m, rte->ifp, rte->tunnel_src, + rt1); + #endif RSVP_ISI + mb_rt->m_act = mb_ntry->m_act; + m_freem(rte->m); + m_free(mb_ntry); + } + + /* + * If more than one entry was created for a single upcall + * delete that entry + */ + if (nstl > 1) { + MFREE(mb_rt, prev_mb_rt->m_next); + mb_rt = prev_mb_rt; + } + } + } + + /* + * It is possible that an entry is being inserted without an upcall + */ + if (nstl == 0) { + if (mrtdebug) + log(LOG_DEBUG,"add_mfc no upcall h %d o %x g %x m %x p %x", + hash, ntohl(mfccp->mfcc_origin.s_addr), + ntohl(mfccp->mfcc_mcastgrp.s_addr), + ntohl(mfccp->mfcc_originmask.s_addr), + mfccp->mfcc_parent); + + for (prev_mb_rt = mb_rt = mfctable[hash]; + mb_rt; prev_mb_rt = mb_rt, mb_rt = mb_rt->m_next) { + + rt = mtod(mb_rt, struct mfc *); + if (((rt->mfc_origin.s_addr & mfccp->mfcc_originmask.s_addr) + == mfccp->mfcc_origin.s_addr) && + (rt->mfc_mcastgrp.s_addr == mfccp->mfcc_mcastgrp.s_addr)) { + + rt->mfc_origin = mfccp->mfcc_origin; + rt->mfc_originmask = mfccp->mfcc_originmask; + rt->mfc_mcastgrp = mfccp->mfcc_mcastgrp; + rt->mfc_parent = mfccp->mfcc_parent; + for (i = 0; i < numvifs; i++) + VIFM_COPY(mfccp->mfcc_ttls[i], rt->mfc_ttls[i]); + /* initialize pkt counters per src-grp */ + rt->mfc_pkt_cnt = 0; + } + } + if (mb_rt == NULL) { + /* no upcall, so make a new entry */ + MGET(mb_rt, M_DONTWAIT, MT_MRTABLE); + if (mb_rt == NULL) { + splx(s); + return ENOBUFS; + } + + rt = mtod(mb_rt, struct mfc *); + + /* insert new entry at head of hash chain */ + rt->mfc_origin = mfccp->mfcc_origin; + rt->mfc_originmask = mfccp->mfcc_originmask; + rt->mfc_mcastgrp = mfccp->mfcc_mcastgrp; + rt->mfc_parent = mfccp->mfcc_parent; + for (i = 0; i < numvifs; i++) + VIFM_COPY(mfccp->mfcc_ttls[i], rt->mfc_ttls[i]); + /* initialize pkt counters per src-grp */ + rt->mfc_pkt_cnt = 0; + + /* link into table */ + mb_rt->m_next = mfctable[hash]; + mfctable[hash] = mb_rt; + mb_rt->m_act = NULL; + } + } + splx(s); + return 0; + } + + /* + * Delete an mfc entry + */ + static int + del_mfc(mfccp) + struct delmfcctl *mfccp; + { + struct in_addr origin; + struct in_addr mcastgrp; + struct mfc *rt; + struct mbuf *mb_rt; + struct mbuf *prev_mb_rt; + u_long hash; + struct mfc **cmfc; + struct mfc **cmfcend; + int s, i; + + origin = mfccp->mfcc_origin; + mcastgrp = mfccp->mfcc_mcastgrp; + hash = nethash_fc(origin.s_addr, mcastgrp.s_addr); + + if (mrtdebug) + log(LOG_DEBUG,"del_mfc orig %x mcastgrp %x", + ntohl(origin.s_addr), ntohl(mcastgrp.s_addr)); + + for (prev_mb_rt = mb_rt = mfctable[hash] + ; mb_rt + ; prev_mb_rt = mb_rt, mb_rt = mb_rt->m_next) { + rt = mtod(mb_rt, struct mfc *); + if (origin.s_addr == rt->mfc_origin.s_addr && + mcastgrp.s_addr == rt->mfc_mcastgrp.s_addr && + mb_rt->m_act == NULL) + break; + } + if (mb_rt == NULL) { + return ESRCH; + } + + s = splnet(); + + cmfc = mfchash; + cmfcend = cmfc + MFCHASHSIZ; + for ( ; cmfc < cmfcend; ++cmfc) + if (*cmfc == rt) + *cmfc = 0; + + if (prev_mb_rt != mb_rt) { /* if moved past head of list */ + MFREE(mb_rt, prev_mb_rt->m_next); + } else /* delete head of list, it is in the table */ + mfctable[hash] = m_free(mb_rt); + + splx(s); + + return 0; + } + + /* + * IP multicast forwarding function. This function assumes that the packet + * pointed to by "ip" has arrived on (or is about to be sent to) the interface + * pointed to by "ifp", and the packet is to be relayed to other networks + * that have members of the packet's destination IP multicast group. + * + * The packet is returned unscathed to the caller, unless it is tunneled + * or erroneous, in which case a non-zero return value tells the caller to + * discard it. + */ + + #define IP_HDR_LEN 20 /* # bytes of fixed IP header (excluding options) */ + #define TUNNEL_LEN 12 /* # bytes of IP option for tunnel encapsulation */ + + int + #ifdef RSVP_ISI + ip_mforward(ip, ifp, m, imo) + #else + ip_mforward(ip, ifp, m) + #endif RSVP_ISI + struct mbuf *m; + register struct ip *ip; + struct ifnet *ifp; + #ifdef RSVP_ISI + struct ip_moptions *imo; + #endif RSVP_ISI + { + register struct mfc *rt; + register struct vif *vifp; + register u_char *ipoptions; + u_long tunnel_src; + static struct sockproto k_igmpproto = { AF_INET, IPPROTO_IGMP }; + static struct sockaddr_in k_igmpsrc = { AF_INET }; + static struct sockaddr_in k_igmpdst = { AF_INET }; + register struct mbuf *mm; + register struct mbuf *mn; + register struct ip *k_data; + int s; + + if (mrtdebug > 1) + log(LOG_DEBUG, "ip_mforward: src %x, dst %x, ifp %x", + ntohl(ip->ip_src.s_addr), ntohl(ip->ip_dst.s_addr), ifp); + + if (ip->ip_hl < (IP_HDR_LEN + TUNNEL_LEN) >> 2 || + (ipoptions = (u_char *)(ip + 1))[1] != IPOPT_LSRR ) { + /* + * Packet arrived via a physical interface. + */ + tunnel_src = 0; + } else { + /* + * Packet arrived through a source-route tunnel. + * + * A source-route tunneled packet has a single NOP option and a + * two-element + * loose-source-and-record-route (LSRR) option immediately following + * the fixed-size part of the IP header. At this point in processing, + * the IP header should contain the following IP addresses: + * + * original source - in the source address field + * destination group - in the destination address field + * remote tunnel end-point - in the first element of LSRR + * one of this host's addrs - in the second element of LSRR + * + * NOTE: RFC-1075 would have the original source and remote tunnel + * end-point addresses swapped. However, that could cause + * delivery of ICMP error messages to innocent applications + * on intermediate routing hosts! Therefore, we hereby + * change the spec. + */ + + /* + * Verify that the tunnel options are well-formed. + */ + if (ipoptions[0] != IPOPT_NOP || + ipoptions[2] != 11 || /* LSRR option length */ + ipoptions[3] != 12 || /* LSRR address pointer */ + (tunnel_src = *(u_long *)(&ipoptions[4])) == 0) { + mrtstat.mrts_bad_tunnel++; + if (mrtdebug) + log(LOG_DEBUG, + "ip_mforward: bad tunnel from %u (%x %x %x %x %x %x)", + ntohl(ip->ip_src.s_addr), + ipoptions[0], ipoptions[1], ipoptions[2], ipoptions[3], + *(u_long *)(&ipoptions[4]), *(u_long *)(&ipoptions[8])); + return 1; + } + + /* + * Delete the tunnel options from the packet. + */ + ovbcopy((caddr_t)(ipoptions + TUNNEL_LEN), (caddr_t)ipoptions, + (unsigned)(m->m_len - (IP_HDR_LEN + TUNNEL_LEN))); + m->m_len -= TUNNEL_LEN; + ip->ip_len -= TUNNEL_LEN; + ip->ip_hl -= TUNNEL_LEN >> 2; + + ifp = 0; + } + + /* + * Don't forward a packet with time-to-live of zero or one, + * or a packet destined to a local-only group. + */ + if (ip->ip_ttl <= 1 || + ntohl(ip->ip_dst.s_addr) <= INADDR_MAX_LOCAL_GROUP) + return (int)tunnel_src; + + /* + * Determine forwarding vifs from the forwarding cache table + */ + s = splnet(); + MFCFIND(ip->ip_src.s_addr, ip->ip_dst.s_addr, rt); + + /* Entry exists, so forward if necessary */ + if (rt != NULL) { + splx(s); + #ifdef RSVP_ISI + return (ip_mdq(m, ifp, tunnel_src, rt, imo)); + #else + return (ip_mdq(m, ifp, tunnel_src, rt)); + #endif RSVP_ISI + } + + else { + /* + * If we don't have a route for packet's origin, + * Make a copy of the packet & + * send message to routing daemon + */ + + register struct mbuf *mb_rt; + register struct mbuf *mb_ntry; + register struct mbuf *mb0; + register struct rtdetq *rte; + register struct mbuf *rte_m; + register u_long hash; + register struct timeval tp; + + mrtstat.mrts_no_route++; + if (mrtdebug) + log(LOG_DEBUG, "ip_mforward: no rte s %x g %x", + ntohl(ip->ip_src.s_addr), + ntohl(ip->ip_dst.s_addr)); + + /* is there an upcall waiting for this packet? */ + hash = nethash_fc(ip->ip_src.s_addr, ip->ip_dst.s_addr); + for (mb_rt = mfctable[hash]; mb_rt; mb_rt = mb_rt->m_next) { + rt = mtod(mb_rt, struct mfc *); + if (((ip->ip_src.s_addr & rt->mfc_originmask.s_addr) == + rt->mfc_origin.s_addr) && + (ip->ip_dst.s_addr == rt->mfc_mcastgrp.s_addr) && + (mb_rt->m_act != NULL)) + break; + } + + if (mb_rt == NULL) { + /* no upcall, so make a new entry */ + MGET(mb_rt, M_DONTWAIT, MT_MRTABLE); + if (mb_rt == NULL) { + splx(s); + return ENOBUFS; + } + + rt = mtod(mb_rt, struct mfc *); + + /* insert new entry at head of hash chain */ + rt->mfc_origin.s_addr = ip->ip_src.s_addr; + rt->mfc_originmask.s_addr = (u_long)0xffffffff; + rt->mfc_mcastgrp.s_addr = ip->ip_dst.s_addr; + + /* link into table */ + hash = nethash_fc(rt->mfc_origin.s_addr, rt->mfc_mcastgrp.s_addr); + mb_rt->m_next = mfctable[hash]; + mfctable[hash] = mb_rt; + mb_rt->m_act = NULL; + + } + + /* determine if q has overflowed */ + for (rte_m = mb_rt, hash = 0; rte_m->m_act; rte_m = rte_m->m_act) + hash++; + + if (hash > MAX_UPQ) { + mrtstat.mrts_upq_ovflw++; + splx(s); + return 0; + } + + /* add this packet and timing, ifp info to m_act */ + MGET(mb_ntry, M_DONTWAIT, MT_DATA); + if (mb_ntry == NULL) { + splx(s); + return ENOBUFS; + } + + mb_ntry->m_act = NULL; + rte = mtod(mb_ntry, struct rtdetq *); + + mb0 = m_copy(m, 0, M_COPYALL); + if (mb0 == NULL) { + splx(s); + return ENOBUFS; + } + + rte->m = mb0; + rte->ifp = ifp; + rte->tunnel_src = tunnel_src; + #ifdef RSVP_ISI + rte->imo = imo; + #endif RSVP_ISI + + rte_m->m_act = mb_ntry; + + splx(s); + + if (hash == 0) { + /* + * Send message to routing daemon to install + * a route into the kernel table + */ + k_igmpsrc.sin_addr = ip->ip_src; + k_igmpdst.sin_addr = ip->ip_dst; + + mm = m_copy(m, 0, M_COPYALL); + if (mm == NULL) { + splx(s); + return ENOBUFS; + } + + k_data = mtod(mm, struct ip *); + k_data->ip_p = 0; + + mrtstat.mrts_upcalls++; + + raw_input(mm, &k_igmpproto, + (struct sockaddr *)&k_igmpsrc, + (struct sockaddr *)&k_igmpdst); + + /* set timer to cleanup entry if upcall is lost */ + timeout(cleanup_cache, (caddr_t)mb_rt, 100); + timeout_val++; + } + + return 0; + } + } + + /* + * Clean up the cache entry if upcall is not serviced + */ + static void + cleanup_cache(mb_rt) + struct mbuf *mb_rt; + { + struct mfc *rt; + u_long hash; + struct mbuf *prev_m0; + struct mbuf *m0; + struct mbuf *m; + struct rtdetq *rte; + int s; + + rt = mtod(mb_rt, struct mfc *); + hash = nethash_fc(rt->mfc_origin.s_addr, rt->mfc_mcastgrp.s_addr); + + if (mrtdebug) + log(LOG_DEBUG, "ip_mforward: cleanup ipm %d h %d s %x g %x", + ip_mrouter, hash, ntohl(rt->mfc_origin.s_addr), + ntohl(rt->mfc_mcastgrp.s_addr)); + + mrtstat.mrts_cache_cleanups++; + + /* + * determine entry to be cleaned up in cache table + */ + s = splnet(); + for (prev_m0 = m0 = mfctable[hash]; m0; prev_m0 = m0, m0 = m0->m_next) + if (m0 == mb_rt) + break; + + /* + * drop all the packets + * free the mbuf with the pkt, if, timing info + */ + while (mb_rt->m_act) { + m = mb_rt->m_act; + mb_rt->m_act = m->m_act; + + rte = mtod(m, struct rtdetq *); + m_freem(rte->m); + m_free(m); + } + + /* + * Delete the entry from the cache + */ + if (prev_m0 != m0) { /* if moved past head of list */ + MFREE(m0, prev_m0->m_next); + } else /* delete head of list, it is in the table */ + mfctable[hash] = m_free(m0); + + timeout_val--; + splx(s); + } + + /* + * Packet forwarding routine once entry in the cache is made + */ + static int + #ifdef RSVP_ISI + ip_mdq(m, ifp, tunnel_src, rt, imo) + #else + ip_mdq(m, ifp, tunnel_src, rt) + #endif RSVP_ISI + register struct mbuf *m; + register struct ifnet *ifp; + register u_long tunnel_src; + register struct mfc *rt; + #ifdef RSVP_ISI + register struct ip_moptions *imo; + #endif RSVP_ISI + { + register struct ip *ip = mtod(m, struct ip *); + register vifi_t vifi; + register struct vif *vifp; + + /* + * Don't forward if it didn't arrive from the parent vif for its origin. + * Notes: v_ifp is zero for src route tunnels, multicast_decap_if + * for encapsulated tunnels and a real ifnet for non-tunnels so + * the first part of the if catches wrong physical interface or + * tunnel type; v_rmt_addr is zero for non-tunneled packets so + * the 2nd part catches both packets that arrive via a tunnel + * that shouldn't and packets that arrive via the wrong tunnel. + */ + vifi = rt->mfc_parent; + if (viftable[vifi].v_ifp != ifp || + (ifp == 0 && viftable[vifi].v_rmt_addr.s_addr != tunnel_src)) { + /* came in the wrong interface */ + if (mrtdebug) + log(LOG_DEBUG, "wrong if: ifp %x vifi %d", + ifp, vifi); + ++mrtstat.mrts_wrong_if; + return (int)tunnel_src; + } + + /* increment the interface and s-g counters */ + viftable[vifi].v_pkt_in++; + rt->mfc_pkt_cnt++; + + /* + * For each vif, decide if a copy of the packet should be forwarded. + * Forward if: + * - the ttl exceeds the vif's threshold + * - there are group members downstream on interface + */ + #define MC_SEND(ip,vifp,m) { \ + (vifp)->v_pkt_out++; \ + if ((vifp)->v_flags & VIFF_SRCRT) \ + srcrt_send((ip), (vifp), (m)); \ + else if ((vifp)->v_flags & VIFF_TUNNEL) \ + encap_send((ip), (vifp), (m)); \ + else \ + phyint_send((ip), (vifp), (m)); \ + } + + #ifdef RSVP_ISI + /* If no options or the imo_multicast_vif option is 0, don't do this part + */ + if ((imo != NULL) && + (( vifi = imo->imo_multicast_vif - 1) < numvifs) && (vifi>=0)) + { + MC_SEND(ip,viftable+vifi,m); + return (1); /* make sure we are done: No more physical sends */ + } + #endif RSVP_ISI + + for (vifp = viftable, vifi = 0; vifi < numvifs; vifp++, vifi++) + if ((rt->mfc_ttls[vifi] > 0) && + (ip->ip_ttl > rt->mfc_ttls[vifi])) + MC_SEND(ip, vifp, m); + + return 0; + } + + #ifdef RSVP_ISI + /* check if a vif number is legal/ok. This is used by ip_output, to export + * numvifs there, + */ + int + legal_vif_num(vif) + int vif; + { if (vif>=0 && vif<=numvifs) + return(1); + else + return(0); + } + #endif RSVP_ISI + + static void + phyint_send(ip, vifp, m) + struct ip *ip; + struct vif *vifp; + struct mbuf *m; + { + register struct mbuf *mb_copy; + register struct mbuf *mopts; + register struct ip_moptions *imo; + + if ((mb_copy = m_copy(m, 0, M_COPYALL)) == NULL) + return; + + MGET(mopts, M_DONTWAIT, MT_IPMOPTS); + if (mopts == NULL) { + m_freem(mb_copy); + return; + } + + imo = mtod(mopts, struct ip_moptions *); + imo->imo_multicast_ifp = vifp->v_ifp; + imo->imo_multicast_ttl = ip->ip_ttl - 1; + imo->imo_multicast_loop = 1; + + /* link options to enable both mbufs to passed on */ + mb_copy->m_act = mopts; + + if (vifp->v_rate_limit <= 0) + tbf_send_packet(vifp, mb_copy); + else + tbf_control(vifp, mb_copy, mtod(mb_copy, struct ip *), ip->ip_len); + } + + static void + srcrt_send(ip, vifp, m) + struct ip *ip; + struct vif *vifp; + struct mbuf *m; + { + struct mbuf *mb_copy, *mb_opts; + register struct ip *ip_copy; + u_char *cp; + + /* + * Make sure that adding the tunnel options won't exceed the + * maximum allowed number of option bytes. + */ + if (ip->ip_hl > (60 - TUNNEL_LEN) >> 2) { + mrtstat.mrts_cant_tunnel++; + if (mrtdebug) + log(LOG_DEBUG, "srcrt_send: no room for tunnel options, from %u", + ntohl(ip->ip_src.s_addr)); + return; + } + + if ((mb_copy = m_copy(m, 0, M_COPYALL)) == NULL) + return; + + ip_copy = mtod(mb_copy, struct ip *); + ip_copy->ip_ttl--; + ip_copy->ip_dst = vifp->v_rmt_addr; /* remote tunnel end-point */ + /* + * Adjust the ip header length to account for the tunnel options. + */ + ip_copy->ip_hl += TUNNEL_LEN >> 2; + ip_copy->ip_len += TUNNEL_LEN; + MGET(mb_opts, M_DONTWAIT, MT_HEADER); + if (mb_opts == NULL) { + m_freem(mb_copy); + return; + } + /* + * 'Delete' the base ip header from the mb_copy chain + */ + mb_copy->m_len -= IP_HDR_LEN; + mb_copy->m_off += IP_HDR_LEN; + /* + * Make mb_opts be the new head of the packet chain. + * Any options of the packet were left in the old packet chain head + */ + mb_opts->m_next = mb_copy; + mb_opts->m_off += 16; + mb_opts->m_len = IP_HDR_LEN + TUNNEL_LEN; + /* + * Copy the base ip header from the mb_copy chain to the new head mbuf + */ + bcopy((caddr_t)ip_copy, mtod(mb_opts, caddr_t), IP_HDR_LEN); + /* + * Add the NOP and LSRR after the base ip header + */ + cp = mtod(mb_opts, u_char *) + IP_HDR_LEN; + *cp++ = IPOPT_NOP; + *cp++ = IPOPT_LSRR; + *cp++ = 11; /* LSRR option length */ + *cp++ = 8; /* LSSR pointer to second element */ + *(u_long*)cp = vifp->v_lcl_addr.s_addr; /* local tunnel end-point */ + cp += 4; + *(u_long*)cp = ip->ip_dst.s_addr; /* destination group */ + + if (vifp->v_rate_limit <= 0) + tbf_send_packet(vifp, mb_opts); + else + tbf_control(vifp, mb_opts, + mtod(mb_opts, struct ip *), ip_copy->ip_len); + } + + static void + encap_send(ip, vifp, m) + register struct ip *ip; + register struct vif *vifp; + register struct mbuf *m; + { + register struct mbuf *mb_copy; + register struct ip *ip_copy; + register int i, len = ip->ip_len; + + /* + * copy the old packet & pullup it's IP header into the + * new mbuf so we can modify it. Try to fill the new + * mbuf since if we don't the ethernet driver will. + */ + MGET(mb_copy, M_DONTWAIT, MT_DATA); + if (mb_copy == NULL) + return; + mb_copy->m_off += 16; + mb_copy->m_len = sizeof(multicast_encap_iphdr); + + if ((mb_copy->m_next = m_copy(m, 0, M_COPYALL)) == NULL) { + m_freem(mb_copy); + return; + } + i = MMAXOFF - mb_copy->m_off; + if (i > len) + i = len; + mb_copy = m_pullup(mb_copy, i); + if (mb_copy == NULL) + return; + + /* + * fill in the encapsulating IP header. + */ + ip_copy = mtod(mb_copy, struct ip *); + *ip_copy = multicast_encap_iphdr; + ip_copy->ip_id = htons(ip_id++); + ip_copy->ip_len += len; + ip_copy->ip_src = vifp->v_lcl_addr; + ip_copy->ip_dst = vifp->v_rmt_addr; + + /* + * turn the encapsulated IP header back into a valid one. + */ + ip = (struct ip *)((caddr_t)ip_copy + sizeof(multicast_encap_iphdr)); + --ip->ip_ttl; + HTONS(ip->ip_len); + HTONS(ip->ip_off); + ip->ip_sum = 0; + #if defined(LBL) && !defined(ultrix) + ip->ip_sum = ~oc_cksum((caddr_t)ip, ip->ip_hl << 2, 0); + #else + mb_copy->m_off += sizeof(multicast_encap_iphdr); + ip->ip_sum = in_cksum(mb_copy, ip->ip_hl << 2); + mb_copy->m_off -= sizeof(multicast_encap_iphdr); + #endif + + if (vifp->v_rate_limit <= 0) + tbf_send_packet(vifp, mb_copy); + else + tbf_control(vifp, mb_copy, ip, ip_copy->ip_len); + } + + /* + * De-encapsulate a packet and feed it back through ip input (this + * routine is called whenever IP gets a packet with proto type + * ENCAP_PROTO and a local destination address). + */ + multiencap_decap(m, ifp) + register struct mbuf *m; + struct ifnet *ifp; + { + register struct ip *ip = mtod(m, struct ip *); + register int hlen = ip->ip_hl << 2; + register int s; + register struct ifqueue *ifq; + register struct vif *vifp; + + if (ip->ip_p != ENCAP_PROTO) { + (encap_oldrawip)(m, ifp); + return; + } + /* + * dump the packet if it's not to a multicast destination or if + * we don't have an encapsulating tunnel with the source. + * Note: This code assumes that the remote site IP address + * uniquely identifies the tunnel (i.e., that this site has + * at most one tunnel with the remote site). + */ + if (! IN_MULTICAST(ntohl(((struct ip *)((char *)ip + hlen))->ip_dst.s_addr))) { + ++mrtstat.mrts_bad_tunnel; + m_freem(m); + return; + } + if (ip->ip_src.s_addr != last_encap_src) { + register struct vif *vife; + + vifp = viftable; + vife = vifp + numvifs; + last_encap_src = ip->ip_src.s_addr; + last_encap_vif = 0; + for ( ; vifp < vife; ++vifp) + if (vifp->v_rmt_addr.s_addr == ip->ip_src.s_addr) { + if ((vifp->v_flags & (VIFF_TUNNEL|VIFF_SRCRT)) + == VIFF_TUNNEL) + last_encap_vif = vifp; + break; + } + } + if ((vifp = last_encap_vif) == 0) { + last_encap_src = 0; + mrtstat.mrts_cant_tunnel++; /*XXX*/ + m_freem(m); + if (mrtdebug) + log(LOG_DEBUG, "ip_mforward: no tunnel with %u", + ntohl(ip->ip_src.s_addr)); + return; + } + ifp = vifp->v_ifp; + #ifndef ultrix + hlen -= sizeof(struct ifnet *); + #endif + m->m_off += hlen; + m->m_len -= hlen; + #ifndef ultrix + *(mtod(m, struct ifnet **)) = ifp; + #endif + ifq = &ipintrq; + s = splimp(); + if (IF_QFULL(ifq)) { + IF_DROP(ifq); + m_freem(m); + } else { + #ifdef ultrix + IF_ENQUEUEIF(ifq, m, ifp); + #else + IF_ENQUEUE(ifq, m); + #endif + /* + * normally we would need a "schednetisr(NETISR_IP)" + * here but we were called by ip_input and it is going + * to loop back & try to dequeue the packet we just + * queued as soon as we return so we avoid the + * unnecessary software interrrupt. + */ + } + splx(s); + } + + /* + * Token bucket filter module + */ + void + tbf_control(vifp, m, ip, p_len) + register struct vif *vifp; + register struct mbuf *m; + register struct ip *ip; + register u_long p_len; + { + tbf_update_tokens(vifp); + + /* if there are enough tokens, + * and the queue is empty, + * send this packet out + */ + + if (vifp->v_tbf->q_len == 0) { + if (p_len <= vifp->v_tbf->n_tok) { + vifp->v_tbf->n_tok -= p_len; + tbf_send_packet(vifp, m); + } else if (p_len > MAX_BKT_SIZE) { + /* drop if packet is too large */ + mrtstat.mrts_pkt2large++; + m_freem(m); + return; + } else { + /* queue packet and timeout till later */ + tbf_queue(vifp, m, ip); + timeout(tbf_reprocess_q, (caddr_t)vifp, 1); + } + } else if (vifp->v_tbf->q_len < MAXQSIZE) { + /* finite queue length, so queue pkts and process queue */ + tbf_queue(vifp, m, ip); + tbf_process_q(vifp); + } else { + /* queue length too much, try to dq and queue and process */ + if (!tbf_dq_sel(vifp, ip)) { + mrtstat.mrts_q_overflow++; + m_freem(m); + return; + } else { + tbf_queue(vifp, m, ip); + tbf_process_q(vifp); + } + } + return; + } + + /* + * adds a packet to the queue at the interface + */ + void + tbf_queue(vifp, m, ip) + register struct vif *vifp; + register struct mbuf *m; + register struct ip *ip; + { + register u_long ql; + register int index = (vifp - viftable); + register int s = splnet(); + + ql = vifp->v_tbf->q_len; + + qtable[index][ql].pkt_m = m; + qtable[index][ql].pkt_len = (mtod(m, struct ip *))->ip_len; + qtable[index][ql].pkt_ip = ip; + + vifp->v_tbf->q_len++; + splx(s); + } + + + /* + * processes the queue at the interface + */ + void + tbf_process_q(vifp) + register struct vif *vifp; + { + register struct mbuf *m; + register struct pkt_queue pkt_1; + register int index = (vifp - viftable); + register int s = splnet(); + + /* loop through the queue at the interface and send as many packets + * as possible + */ + while (vifp->v_tbf->q_len > 0) { + /* locate the first packet */ + pkt_1.pkt_len = ((qtable[index][0]).pkt_len); + pkt_1.pkt_m = (qtable[index][0]).pkt_m; + pkt_1.pkt_ip = (qtable[index][0]).pkt_ip; + + /* determine if the packet can be sent */ + if (pkt_1.pkt_len <= vifp->v_tbf->n_tok) { + /* if so, + * reduce no of tokens, dequeue the queue, + * send the packet. + */ + vifp->v_tbf->n_tok -= pkt_1.pkt_len; + + tbf_dequeue(vifp,0); + + tbf_send_packet(vifp, pkt_1.pkt_m); + + } else break; + } + splx(s); + } + + /* + * removes the jth packet from the queue at the interface + */ + void + tbf_dequeue(vifp,j) + register struct vif *vifp; + register int j; + { + register u_long index = vifp - viftable; + register int i; + + for (i=j+1; i <= vifp->v_tbf->q_len - 1; i++) { + qtable[index][i-1].pkt_m = qtable[index][i].pkt_m; + qtable[index][i-1].pkt_len = qtable[index][i].pkt_len; + qtable[index][i-1].pkt_ip = qtable[index][i].pkt_ip; + } + qtable[index][i-1].pkt_m = NULL; + qtable[index][i-1].pkt_len = NULL; + qtable[index][i-1].pkt_ip = NULL; + + vifp->v_tbf->q_len--; + + if (tbfdebug > 1) + log(LOG_DEBUG, "tbf_dequeue: vif# %d qlen %d",vifp-viftable, i-1); + } + + void + tbf_reprocess_q(vifp) + register struct vif *vifp; + { + if (ip_mrouter == NULL) + return; + + tbf_update_tokens(vifp); + + tbf_process_q(vifp); + + if (vifp->v_tbf->q_len) + timeout(tbf_reprocess_q, (caddr_t)vifp, 1); + } + + /* function that will selectively discard a member of the queue + * based on the precedence value and the priority obtained through + * a lookup table - not yet implemented accurately! + */ + int + tbf_dq_sel(vifp, ip) + register struct vif *vifp; + register struct ip *ip; + { + register int i; + register int s = splnet(); + register u_int p; + + p = priority(vifp, ip); + + for(i=vifp->v_tbf->q_len-1;i >= 0;i--) { + if (p > priority(vifp, qtable[vifp-viftable][i].pkt_ip)) { + m_freem(qtable[vifp-viftable][i].pkt_m); + tbf_dequeue(vifp,i); + splx(s); + mrtstat.mrts_drop_sel++; + return(1); + } + } + splx(s); + return(0); + } + + void + tbf_send_packet(vifp,m) + register struct vif *vifp; + register struct mbuf *m; + { + register struct mbuf *mcp; + int error; + int s = splnet(); + + /* if source route tunnels */ + if (vifp->v_flags & VIFF_SRCRT) { + #ifdef ultrix + error = ip_output(m, (struct mbuf *)0, (struct route *)0, + IP_FORWARDING, + (struct socket *)0, (struct mbuf *)0); + #else + error = ip_output(m, (struct mbuf *)0, (struct route *)0, + IP_FORWARDING, (struct mbuf *)0); + #endif + if (mrtdebug > 1) + log(LOG_DEBUG, "srcrt_send on vif %d err %d", vifp-viftable, error); + } else if (vifp->v_flags & VIFF_TUNNEL) { + /* If tunnel options */ + #ifdef ultrix + ip_output(m, (struct mbuf *)0, (struct route *)0, + IP_FORWARDING, (struct socket *)0, (struct mbuf *)0); + #else + ip_output(m, (struct mbuf *)0, (struct route *)0, + IP_FORWARDING, (struct mbuf *)0); + #endif + } else { + /* if physical interface option, extract the options and then send */ + mcp = m->m_act; + m->m_act = NULL; + #ifdef ultrix + error = ip_output(m, (struct mbuf *)0, (struct route *)0, + IP_FORWARDING|IP_MULTICASTOPTS, + (struct socket *)0, mcp); + #else + error = ip_output(m, (struct mbuf *)0, (struct route *)0, + IP_FORWARDING|IP_MULTICASTOPTS, mcp); + #endif + m_freem(mcp); + + if (mrtdebug > 1) + log(LOG_DEBUG, "phyint_send on vif %d err %d", vifp-viftable, error); + } + splx(s); + } + + /* determine the current time and then + * the elapsed time (between the last time and time now) + * in milliseconds & update the no. of tokens in the bucket + */ + void + tbf_update_tokens(vifp) + register struct vif *vifp; + { + register struct timeval tp; + register u_long t; + register u_long elapsed; + register int s = splnet(); + + GET_TIME(tp); + + t = tp.tv_sec*1000 + tp.tv_usec/1000; + + elapsed = (t - vifp->v_tbf->last_pkt_t) * vifp->v_rate_limit /8; + vifp->v_tbf->n_tok += elapsed; + vifp->v_tbf->last_pkt_t = t; + + if (vifp->v_tbf->n_tok > MAX_BKT_SIZE) + vifp->v_tbf->n_tok = MAX_BKT_SIZE; + + splx(s); + } + + int + priority(vifp, ip) + register struct vif *vifp; + register struct ip *ip; + { + register u_long graddr; + register int prio; + + /* temporary hack; will add general packet classifier some day */ + + prio = 50; /* default priority */ + + /* check for source route options and add option length to get dst */ + if (vifp->v_flags & VIFF_SRCRT) + graddr = ntohl((ip+8)->ip_dst.s_addr); + else + graddr = ntohl(ip->ip_dst.s_addr); + + switch (graddr & 0xf) { + case 0x0: break; + case 0x1: if (graddr == 0xe0020001) prio = 65; /* MBone Audio */ + break; + case 0x2: break; + case 0x3: break; + case 0x4: break; + case 0x5: break; + case 0x6: break; + case 0x7: break; + case 0x8: break; + case 0x9: break; + case 0xa: if (graddr == 0xe000010a) prio = 85; /* IETF Low Audio 1 */ + break; + case 0xb: if (graddr == 0xe000010b) prio = 75; /* IETF Audio 1 */ + break; + case 0xc: if (graddr == 0xe000010c) prio = 60; /* IETF Video 1 */ + break; + case 0xd: if (graddr == 0xe000010d) prio = 80; /* IETF Low Audio 2 */ + break; + case 0xe: if (graddr == 0xe000010e) prio = 70; /* IETF Audio 2 */ + break; + case 0xf: if (graddr == 0xe000010f) prio = 55; /* IETF Video 2 */ + break; + } + + if (tbfdebug > 1) log(LOG_DEBUG, "graddr%x prio%d", graddr, prio); + + return prio; + } + + /* + * End of token bucket filter modifications + */ + + #endif MROUTING + + #ifdef ultrix + /* + * Ultrix doesn't support the BSD log() call so we have to simulate it for the + * mrouter code. + * + * - tm 3/89 + */ + + /*VARARGS2*/ + log(level, fmt, x1) + char *fmt; + unsigned x1; + { + if(level == LOG_DEBUG) + mprintf(fmt, x1); + else + printf(fmt, x1); + } + + #endif ultrix + + #endif MULTICAST *** sys/net/netinet/if_ether.c.orig Mon Feb 13 15:23:26 1995 --- sys/net/netinet/if_ether.c Sat Feb 4 21:11:37 1995 *************** *** 1,5 **** --- 1,6 ---- #ifndef lint static char *sccsid = "@(#)if_ether.c 8.2 (ULTRIX) 8/26/93"; + /* plus MULTICAST 1.1 */ #endif lint /* *************** *** 51,56 **** --- 52,60 ---- * 3-Mar-89 U. Sinkewicz * Folded in reverse arp (plus pmax/smp). * + * 20-Mar-89 Tony Mason, Stanford Univ. + * Added IP Multicast modifications. + * * 15-Jan-88 lp * Merge of final 43BSD changes. * *************** *** 170,175 **** --- 174,183 ---- #define ARPT_KILLI 3 /* kill incomplete entry in 3 minutes */ u_char etherbroadcastaddr[6] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; + #ifdef MULTICAST + u_char ether_ipmulticast_min[6] = { 0x01, 0x00, 0x5e, 0x00, 0x00, 0x00 }; + u_char ether_ipmulticast_max[6] = { 0x01, 0x00, 0x5e, 0x7f, 0xff, 0xff }; + #endif MULTICAST extern struct ifnet loif; int useloopback = 1; *************** *** 299,304 **** --- 307,320 ---- *usetrailers = 0; + #ifdef MULTICAST + if (IN_MULTICAST(ntohl(destip->s_addr))) { + ETHER_MAP_IP_MULTICAST(destip, desten); + return(1); + } + else + #endif MULTICAST + if(!smp && at_cache && at_cache->at_iaddr.s_addr == destip->s_addr) { s = splimp(); smp_lock(&lk_arptab, LK_RETRY); *************** *** 863,865 **** --- 879,1046 ---- return (0); } #endif GATEWAY + + #ifdef MULTICAST + /* + * Add an Ethernet multicast address or range of addresses to the list for a + * given interface. + */ + ether_addmulti(ifr, ac) + struct ifreq *ifr; + register struct arpcom *ac; + { + register struct ether_multi *enm; + struct sockaddr_in *sin; + u_char addrlo[6]; + u_char addrhi[6]; + struct mbuf *m; + int s = splimp(); + + switch (ifr->ifr_addr.sa_family) { + case AF_UNSPEC: + bcopy(ifr->ifr_addr.sa_data, addrlo, 6); + bcopy(addrlo, addrhi, 6); + break; + + #ifdef INET + case AF_INET: + sin = (struct sockaddr_in *)&(ifr->ifr_addr); + if (sin->sin_addr.s_addr == INADDR_ANY) { + /* + * An IP address of INADDR_ANY means listen to all + * of the Ethernet multicast addresses used for IP. + * (This is for the sake of IP multicast routers.) + */ + bcopy(ether_ipmulticast_min, addrlo, 6); + bcopy(ether_ipmulticast_max, addrhi, 6); + } + else { + ETHER_MAP_IP_MULTICAST(&sin->sin_addr, addrlo); + bcopy(addrlo, addrhi, 6); + } + break; + #endif INET + + default: + splx(s); + return(EAFNOSUPPORT); + } + + /* + * Verify that we have valid Ethernet multicast addresses. + */ + if ((addrlo[0] & 0x01) != 1 || (addrhi[0] & 0x01) != 1) { + splx(s); + return(EINVAL); + } + /* + * See if the address range is already in the list. + */ + ETHER_LOOKUP_MULTI(addrlo, addrhi, ac, enm); + if (enm != NULL) { + /* + * Found it; just increment the reference count. + */ + ++enm->enm_refcount; + splx(s); + return(0); + } + /* + * New address or range; get an mbuf for a new multicast record + * and link it into the interface's multicast list. + */ + if ((m = m_getclr(M_DONTWAIT, MT_IFMADDR)) == NULL) { + splx(s); + return(ENOBUFS); + } + enm = mtod(m, struct ether_multi *); + bcopy(addrlo, enm->enm_addrlo, 6); + bcopy(addrhi, enm->enm_addrhi, 6); + enm->enm_ac = ac; + enm->enm_refcount = 1; + enm->enm_next = ac->ac_multiaddrs; + ac->ac_multiaddrs = enm; + splx(s); + /* + * Return ENETRESET to inform the driver that the list has changed + * and its reception filter should be adjusted accordingly. + */ + return(ENETRESET); + } + + /* + * Delete a multicast address record. + */ + ether_delmulti(ifr, ac) + struct ifreq *ifr; + register struct arpcom *ac; + { + register struct ether_multi *enm; + register struct ether_multi **p; + struct sockaddr_in *sin; + u_char addrlo[6]; + u_char addrhi[6]; + int s = splimp(); + + switch (ifr->ifr_addr.sa_family) { + + case AF_UNSPEC: + bcopy(ifr->ifr_addr.sa_data, addrlo, 6); + bcopy(addrlo, addrhi, 6); + break; + + #ifdef INET + case AF_INET: + sin = (struct sockaddr_in *)&(ifr->ifr_addr); + if (sin->sin_addr.s_addr == INADDR_ANY) { + /* + * An IP address of INADDR_ANY means stop listening + * to the range of Ethernet multicast addresses used + * for IP. + */ + bcopy(ether_ipmulticast_min, addrlo, 6); + bcopy(ether_ipmulticast_max, addrhi, 6); + } + else { + ETHER_MAP_IP_MULTICAST(&sin->sin_addr, addrlo); + bcopy(addrlo, addrhi, 6); + } + break; + #endif INET + + default: + splx(s); + return(EAFNOSUPPORT); + } + + /* + * Look up the address in our list. + */ + ETHER_LOOKUP_MULTI(addrlo, addrhi, ac, enm); + if (enm == NULL) { + splx(s); + return(ENXIO); + } + if (--enm->enm_refcount != 0) { + /* + * Still some claims to this record. + */ + splx(s); + return(0); + } + /* + * No remaining claims to this record; unlink and free it. + */ + for (p = &enm->enm_ac->ac_multiaddrs; + *p != enm; + p = &((*p)->enm_next)); + *p = (*p)->enm_next; + m_free(dtom(enm)); + splx(s); + /* + * Return ENETRESET to inform the driver that the list has changed + * and its reception filter should be adjusted accordingly. + */ + return(ENETRESET); + } + #endif MULTICAST *** sys/net/netinet/igmp.h.orig Mon Feb 13 15:24:29 1995 --- sys/net/netinet/igmp.h Tue Feb 7 22:46:33 1995 *************** *** 0 **** --- 1,51 ---- + /* + * Internet Group Management Protocol (IGMP) definitions. + * + * Written by Steve Deering, Stanford, May 1988. + * + * MULTICAST 1.2 + */ + + /* + * IGMP packet format. + */ + struct igmp { + u_char igmp_type; /* version & type of IGMP message */ + u_char igmp_code; /* unused, should be zero */ + u_short igmp_cksum; /* IP-style checksum */ + struct in_addr igmp_group; /* group address being reported */ + }; /* (zero for queries) */ + + #define IGMP_MINLEN 8 + + #define IGMP_HOST_MEMBERSHIP_QUERY 0x11 /* message types, incl. version */ + #define IGMP_HOST_MEMBERSHIP_REPORT 0x12 + #define IGMP_DVMRP 0x13 /* for experimental multicast */ + /* routing protocol */ + #define IGMP_HOST_NEW_MEMBERSHIP_REPORT 0x16 + + #define IGMP_HOST_LEAVE_MESSAGE 0x17 + + #define IGMP_MAX_HOST_REPORT_DELAY 10 /* max delay for response to */ + /* query (in seconds) */ + #define IGMP_MTRACE 0x1f /* mcast traceroute messages */ + #define IGMP_MTRACE_RESP 0x1e /* traceroute resp. (to sender) */ + + + #define IGMP_TIMER_SCALE 10 /* denotes that the igmp->timer filed */ + /*specifies time in 10th os seconds */ + + #define IGMP_DELAYING_MEMBER 1 + #define IGMP_IDLE_MEMBER 2 + #define IGMP_LAZY_MEMBER 3 + #define IGMP_SLEEPING_MEMBER 4 + #define IGMP_AWAKENING_MEMBER 5 + + + #define IGMP_OLD_ROUTER 0 + #define IGMP_NEW_ROUTER 1 + + #define IGMP_AGE_THRESHOLD 540 + + static char *tostate[]={"","DELAYING_MEMBER","IDLE","LAZY","SLEEPING", + "AWAKENING" }; *** sys/net/netinet/igmp_random.c.orig Mon Feb 13 15:24:35 1995 --- sys/net/netinet/igmp_random.c Tue Feb 7 22:46:33 1995 *************** *** 0 **** --- 1,66 ---- + /* + * + * The "Minimal Standard Random Number Generator" of Park and Miller, + * CACM Vol 31, No 10, October 1988, pp 1192-1201. + * + * Caveats: + * + * The global variable RandomValue is not protected by a lock and, + * therefore, multiple concurrent calls of Random() may return the + * same value, and subsequent calls may skip values in the pseudo- + * random sequence. + * + * Random() uses two long multiplies, a long divide, and a long + * modulus operation, all of which are rather expensive. A faster + * implementation that avoids the divide and modulus is described in + * an article by David Carta in CACM Vol 33, No 1, January 1990, + * pp 87-88. Unfortunately, it requires access to the 64-bit + * product of the multiplication of two 32-bit integers, which is + * not available on many processors. + * + * Written by Steve Deering, May 1993. + * Modified by Rosen Sharma, Aug 1994. + * + * MULTICAST 1.0 + */ + + + static unsigned long RandomValue = 1; + + + void InitRandom( seed ) + unsigned long seed; + { + /* converts seed into a value between 1 and 2^31 - 2 */ + + RandomValue = seed % 2147483646 + 1; + } + + + unsigned long Random( ) + { + /* cycles pseudo-randomly through all values between 1 and 2^31 - 2 */ + + register long rv = RandomValue; + register long lo; + register long hi; + + hi = rv / 127773; + lo = rv % 127773; + rv = 16807 * lo - 2836 * hi; + if( rv <= 0 ) rv += 2147483647; + return( RandomValue = rv ); + } + + + #ifdef TEST_RANDOM + main() + { + int i; + + InitRandom( 0 ); + for( i = 0; i < 9999; i++ ) Random(); + printf( Random() == 1043618065 ? "OK\n" : "NOT OK!\n" ); + } + #endif TEST_RANDOM + *** sys/net/netinet/igmp_var.h.orig Mon Feb 13 15:24:40 1995 --- sys/net/netinet/igmp_var.h Tue Feb 7 22:46:34 1995 *************** *** 0 **** --- 1,27 ---- + /* + * Internet Group Management Protocol (IGMP), + * implementation-specific definitions. + * + * Written by Steve Deering, Stanford, May 1988. + * + * MULTICAST 1.2 + */ + + struct igmpstat { + u_int igps_rcv_total; /* total IGMP messages received */ + u_int igps_rcv_tooshort; /* received with too few bytes */ + u_int igps_rcv_badsum; /* received with bad checksum */ + u_int igps_rcv_queries; /* received membership queries */ + u_int igps_rcv_badqueries; /* received invalid queries */ + u_int igps_rcv_reports; /* received membership reports */ + u_int igps_rcv_badreports; /* received invalid reports */ + u_int igps_rcv_ourreports; /* received reports for our groups */ + u_int igps_snd_reports; /* sent membership reports */ + }; + + #ifdef KERNEL + struct igmpstat igmpstat; + + #define IGMP_RANDOM_DELAY(X) ((int) Random() % (X) + 1 ) + + #endif KERNEL *** sys/net/netinet/ip_mroute.h.orig Mon Feb 13 15:25:21 1995 --- sys/net/netinet/ip_mroute.h Mon Feb 13 14:35:59 1995 *************** *** 0 **** --- 1,216 ---- + /* + * Definitions for IP multicast forwarding. + * + * Written by David Waitzman, BBN Labs, August 1988. + * Modified by Steve Deering, Stanford, February 1989. + * Modified by Ajit Thyagarajan, PARC, August 1993. + * Modified by Ajit Thyagarajan, PARC, August 1994. + * + * MROUTING 1.5 + */ + + + /* + * DVMRP-specific setsockopt commands. + */ + #define DVMRP_INIT 100 + #define DVMRP_DONE 101 + #define DVMRP_ADD_VIF 102 + #define DVMRP_DEL_VIF 103 + #define DVMRP_ADD_MFC 104 + #define DVMRP_DEL_MFC 105 + + + #if BSD >= 199103 || ultrix + #define GET_TIME(t) microtime(&t) + #elif defined(sun) + #define GET_TIME(t) uniqtime(&t) + #else + #define GET_TIME(t) ((t) = time) + #endif + + /* + * Types and macros for handling bitmaps with one bit per virtual interface. + */ + #define MAXVIFS 32 + typedef u_long vifbitmap_t; + typedef u_short vifi_t; /* type of a vif index */ + + #define VIFM_SET(n, m) ((m) |= (1 << (n))) + #define VIFM_CLR(n, m) ((m) &= ~(1 << (n))) + #define VIFM_ISSET(n, m) ((m) & (1 << (n))) + #define VIFM_CLRALL(m) ((m) = 0x00000000) + #define VIFM_COPY(mfrom, mto) ((mto) = (mfrom)) + #define VIFM_SAME(m1, m2) ((m1) == (m2)) + + /* + * Argument structure for DVMRP_ADD_VIF. + * (DVMRP_DEL_VIF takes a single vifi_t argument.) + */ + struct vifctl { + vifi_t vifc_vifi; /* the index of the vif to be added */ + u_char vifc_flags; /* VIFF_ flags defined below */ + u_char vifc_threshold; /* min ttl required to forward on vif*/ + u_int vifc_rate_limit; /* max rate */ + struct in_addr vifc_lcl_addr; /* local interface address */ + struct in_addr vifc_rmt_addr; /* remote address (tunnels only) */ + }; + + #define VIFF_TUNNEL 0x1 /* vif represents a tunnel end-point */ + #define VIFF_SRCRT 0x2 /* tunnel uses IP src routing */ + + + /* + * Argument structure for DVMRP_ADD_MFC + * (mfcc_tos to be added at a future point) + */ + struct mfcctl { + struct in_addr mfcc_origin; /* subnet origin of mcasts */ + struct in_addr mfcc_mcastgrp; /* multicast group associated*/ + struct in_addr mfcc_originmask; /* subnet mask for origin */ + vifi_t mfcc_parent; /* incoming vif */ + u_char mfcc_ttls[MAXVIFS]; /* forwarding ttls on vifs */ + }; + + /* + * Argument structure for DVMRP_DEL_MFC + */ + struct delmfcctl { + struct in_addr mfcc_origin; /* subnet origin of multicasts */ + struct in_addr mfcc_mcastgrp; /* multicast group assoc. w/ origin */ + }; + + #ifdef RSVP_ISI + /* + * Argument structure used by RSVP daemon to get vif information + */ + struct vif_req { + u_char v_flags; /* VIFF_ flags defined above */ + u_char v_threshold; /* min ttl required to forward on vif */ + struct in_addr v_lcl_addr; /* local interface address */ + struct in_addr v_rmt_addr; + char v_if_name[IFNAMSIZ]; /* if name */ + }; + + struct vif_conf { + u_int vifc_len; + u_int vifc_num; + struct vif_req *vifc_req; + }; + #endif RSVP_ISI + + /* + * The kernel's multicast routing statistics. + */ + struct mrtstat { + u_long mrts_mfc_lookups; /* # forw. cache hash table hits */ + u_long mrts_mfc_misses; /* # forw. cache hash table misses */ + u_long mrts_upcalls; /* # calls to mrouted */ + u_long mrts_no_route; /* no route for packet's origin */ + u_long mrts_bad_tunnel; /* malformed tunnel options */ + u_long mrts_cant_tunnel; /* no room for tunnel options */ + u_long mrts_wrong_if; /* arrived on wrong interface */ + u_long mrts_upq_ovflw; /* upcall Q overflow */ + u_long mrts_cache_cleanups; /* # entries with no upcalls */ + u_long mrts_drop_sel; /* pkts dropped selectively */ + u_long mrts_q_overflow; /* pkts dropped - Q overflow */ + u_long mrts_pkt2large; /* pkts dropped - size > BKT SIZE */ + }; + + /* + * Argument structure used by mrouted to get src-grp pkt counts + */ + struct sioc_sg_req { + struct in_addr src; + struct in_addr grp; + u_long count; + }; + + /* + * Argument structure used by mrouted to get vif pkt counts + */ + struct sioc_vif_req { + vifi_t vifi; + u_long icount; + u_long ocount; + }; + + #ifdef KERNEL + /* + * The kernel's virtual-interface structure. + */ + struct vif { + u_char v_flags; /* VIFF_ flags defined above */ + u_char v_threshold; /* min ttl required to forward on vif*/ + u_int v_rate_limit; /* max rate */ + struct tbf *v_tbf; /* token bucket structure at intf. */ + struct in_addr v_lcl_addr; /* local interface address */ + struct in_addr v_rmt_addr; /* remote address (tunnels only) */ + struct ifnet *v_ifp; /* pointer to interface */ + u_long v_pkt_in; /* # pkts in on interface */ + u_long v_pkt_out; /* # pkts out on interface */ + }; + + /* + * The kernel's multicast forwarding cache entry structure + * (A field for the type of service (mfc_tos) is to be added + * at a future point) + */ + struct mfc { + struct in_addr mfc_origin; /* subnet origin of mcasts */ + struct in_addr mfc_mcastgrp; /* multicast group associated*/ + struct in_addr mfc_originmask; /* subnet mask for origin */ + vifi_t mfc_parent; /* incoming vif */ + u_char mfc_ttls[MAXVIFS]; /* forwarding ttls on vifs */ + u_long mfc_pkt_cnt; /* pkt count for src-grp */ + }; + + /* + * Argument structure used for pkt info. while upcall is made + */ + struct rtdetq { + struct mbuf *m; + struct ifnet *ifp; + u_long tunnel_src; + #ifdef RSVP_ISI + struct ip_moptions *imo; + #endif RSVP_ISI + }; + + #define MFCTBLSIZ 256 + #if (MFCTBLSIZ & (MFCTBLSIZ - 1)) == 0 /* from sys:route.h */ + #define MFCHASHMOD(h) ((h) & (MFCTBLSIZ - 1)) + #else + #define MFCHASHMOD(h) ((h) % MFCTBLSIZ) + #endif + + #define MAX_UPQ 4 /* max. no of pkts in upcall Q */ + + /* + * Token Bucket filter code + */ + #define MAX_BKT_SIZE 10000 /* 10K bytes size */ + #define MAXQSIZE 10 /* max # of pkts in queue */ + + /* + * queue structure at each vif + */ + struct pkt_queue + { + u_long pkt_len; /* length of packet in queue */ + struct mbuf *pkt_m; /* pointer to packet mbuf */ + struct ip *pkt_ip; /* pointer to ip header */ + }; + + /* + * the token bucket filter at each vif + */ + struct tbf + { + u_long last_pkt_t; /* arr. time of last pkt */ + u_long n_tok; /* no of tokens in bucket */ + u_long q_len; /* length of queue at this vif */ + }; + + #endif /* KERNEL */ + *** sys/net/dli/dli_setopt.c.orig Mon Feb 13 16:00:27 1995 --- sys/net/dli/dli_setopt.c Sat Feb 4 21:11:37 1995 *************** *** 1,5 **** --- 1,6 ---- #ifndef lint static char *sccsid = "@(#)dli_setopt.c 8.1 ULTRIX 9/18/92"; + /* plus MULTICAST 1.0 */ #endif lint /* *************** *** 256,261 **** --- 257,265 ---- if ( pr == NULL || portid == 0 ) { *(struct ether_pa *) dreq.ifr_addr.sa_data = *(struct ether_pa *) (mcast_buf+i); + #ifdef MULTICAST + dreq.ifr_addr.sa_family = AF_UNSPEC; + #endif MULTICAST CALL_TO_NONSMP_DRIVER( (*ifp), saveaffinity); error = (*ifp->if_ioctl)(ifp, cmd, &dreq); RETURN_FROM_NONSMP_DRIVER( (*ifp), saveaffinity); *** sys/conf/mips/files.mips.orig Fri Sep 10 13:09:28 1993 --- sys/conf/mips/files.mips Sat Feb 4 21:16:45 1995 *************** *** 110,116 **** io/np/np_msg.c optional ci device-driver Binary io/np/np_subr.c optional ci device-driver Binary io/np/npvar.c optional ci device-driver Binary ! io/netif/if_ln.c optional ln device-driver Binary io/netif/if_ln_copy.s optional ln Binary io/netif/if_ne.c optional ne device-driver Binary io/netif/if_sl.c optional sl device-driver Binary Unsupported --- 110,116 ---- io/np/np_msg.c optional ci device-driver Binary io/np/np_subr.c optional ci device-driver Binary io/np/npvar.c optional ci device-driver Binary ! io/netif/if_ln.c optional ln device-driver io/netif/if_ln_copy.s optional ln Binary io/netif/if_ne.c optional ne device-driver Binary io/netif/if_sl.c optional sl device-driver Binary Unsupported *************** *** 222,228 **** data/ts_data.c optional ts or zs device-driver Notbinary data/dmb_data.c optional dmb device-driver Notbinary data/gvp_data.c optional ci or bvpssp or msi Notbinary ! data/if_ln_data.c optional ln Notbinary data/if_ne_data.c optional ne Notbinary data/if_qe_data.c optional qe Notbinary data/if_scs_data.c optional ci inet scsnet Notbinary --- 222,228 ---- data/ts_data.c optional ts or zs device-driver Notbinary data/dmb_data.c optional dmb device-driver Notbinary data/gvp_data.c optional ci or bvpssp or msi Notbinary ! data/if_ln_data.c optional nomulti Notbinary data/if_ne_data.c optional ne Notbinary data/if_qe_data.c optional qe Notbinary data/if_scs_data.c optional ci inet scsnet Notbinary *** sys/conf/files.orig Fri Feb 26 14:45:43 1993 --- sys/conf/files Mon Feb 13 13:54:41 1995 *************** *** 11,17 **** net/dli/dli_open.c optional dli Binary net/dli/dli_output.c optional dli Binary net/dli/dli_proto.c optional ether or fddi or dli or osi Notbinary ! net/dli/dli_setopt.c optional dli Binary net/dli/dli_timer.c optional ether or fddi or dli Binary net/dli/dli_usrreq.c optional dli Binary net/dli/dli_subr.c optional ether or fddi or dli Binary --- 11,17 ---- net/dli/dli_open.c optional dli Binary net/dli/dli_output.c optional dli Binary net/dli/dli_proto.c optional ether or fddi or dli or osi Notbinary ! net/dli/dli_setopt.c optional dli net/dli/dli_timer.c optional ether or fddi or dli Binary net/dli/dli_usrreq.c optional dli Binary net/dli/dli_subr.c optional ether or fddi or dli Binary *************** *** 48,73 **** net/net/af.c standard Binary net/net/conf_net.c standard net/net/if.c standard Binary ! net/net/if_loop.c optional loop Binary net/net/if_to_proto.c standard Binary net/net/pfilt.c optional packetfilter or ether or fddi Binary net/net/gw_screen.c optional gwscreen Binary data/gw_screen_data.c standard ! net/net/raw_cb.c standard Binary net/net/raw_usrreq.c standard Binary net/net/route.c standard Binary net/net/net_common.c standard Binary net/netdnet/decnet_dummy.c optional decnet Notbinary ! net/netinet/if_ether.c optional ether or fddi inet Binary ! net/netinet/in.c optional inet Binary ! net/netinet/in_pcb.c optional inet Binary net/netinet/in_proto.c optional inet ! net/netinet/ip_icmp.c optional inet Binary net/netinet/ip_if.c optional inet Binary ! net/netinet/ip_input.c optional inet Binary ! net/netinet/ip_output.c optional inet Binary net/netinet/ip_screen.c optional inet Binary ! net/netinet/raw_ip.c optional inet Binary net/netinet/tcp_debug.c optional inet Binary net/netinet/tcp_input.c optional inet Binary net/netinet/tcp_output.c optional inet Binary --- 48,73 ---- net/net/af.c standard Binary net/net/conf_net.c standard net/net/if.c standard Binary ! net/net/if_loop.c optional loop net/net/if_to_proto.c standard Binary net/net/pfilt.c optional packetfilter or ether or fddi Binary net/net/gw_screen.c optional gwscreen Binary data/gw_screen_data.c standard ! net/net/raw_cb.c standard net/net/raw_usrreq.c standard Binary net/net/route.c standard Binary net/net/net_common.c standard Binary net/netdnet/decnet_dummy.c optional decnet Notbinary ! net/netinet/if_ether.c optional ether or fddi inet ! net/netinet/in.c optional inet ! net/netinet/in_pcb.c optional inet net/netinet/in_proto.c optional inet ! net/netinet/ip_icmp.c optional inet net/netinet/ip_if.c optional inet Binary ! net/netinet/ip_input.c optional inet ! net/netinet/ip_output.c optional inet net/netinet/ip_screen.c optional inet Binary ! net/netinet/raw_ip.c optional inet net/netinet/tcp_debug.c optional inet Binary net/netinet/tcp_input.c optional inet Binary net/netinet/tcp_output.c optional inet Binary *************** *** 74,80 **** net/netinet/tcp_subr.c optional inet Binary net/netinet/tcp_timer.c optional inet Binary net/netinet/tcp_usrreq.c optional inet Binary ! net/netinet/udp_usrreq.c optional inet Binary net/netbsc/bsc_pcb.c optional bsc Binary net/netbsc/bsc_proto.c optional bsc net/netbsc/bsc_states.c optional bsc Binary --- 74,83 ---- net/netinet/tcp_subr.c optional inet Binary net/netinet/tcp_timer.c optional inet Binary net/netinet/tcp_usrreq.c optional inet Binary ! net/netinet/udp_usrreq.c optional inet ! net/netinet/igmp.c optional inet ! net/netinet/igmp_random.c optional inet ! net/netinet/ip_mroute.c optional inet net/netbsc/bsc_pcb.c optional bsc Binary net/netbsc/bsc_proto.c optional bsc net/netbsc/bsc_states.c optional bsc Binary --mysteryboxofun-- From list-mgr@ISI.EDU Mon Feb 13 18:05:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 20:07:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 20:05:49 -0800 Received: from rpi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 20:05:47 -0800 Received: from hibp.ecse.rpi.edu (hibp7.ecse.rpi.edu) by rpi.edu (4.1/SMHUB41); id AA19315; Mon, 13 Feb 95 23:05:46 EST for mbone@isi.edu Received: from hibp6.ecse.rpi.edu by hibp.ecse.rpi.edu (4.1/ST26); id AA06281 for mbone@isi.edu; Mon, 13 Feb 95 23:05:44 EST Message-Id: <9502140405.AA06281@hibp.ecse.rpi.edu> X-Mailer: exmh version 1.5.3 12/28/94 To: Rob Robertson Cc: mbone Subject: Re: ultrix 4.4 / ipmulti3.3 patches In-Reply-To: Your message of "Mon, 13 Feb 1995 16:30:14 PST." <199502140030.QAA05765@gangrene.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Feb 1995 23:05:04 -0500 From: Paul Stewart > Enclosed are source patches to the Ultrix 4.4 kernel to support ip > multicast 3.3. This should be everything to enable the kernel. The > user programs, such as mrouted, et al are not included, you need to > get the ipmulti3.3-sunos413x.tar.Z distribution from the standard places. > I'll make a binary distribution if people are interested, and someone > tells me how to do it under uglix [what the hell is that data/*_data.c > stuff?] > Please let me know if it works for you, and any bugs or fixes you > might stumble across. [MUNCH] Wow! That's 180K of email! Considering the size of this subscribership and the percentage of us who will be using this, I don't think it was appropriate for you to send us all this email. Perhaps, since it appears that you are MIME savvy, you could have given us an external reference, so we could pick it up at our leisure should we be interested. Personally, my mailer had no problems with it, however others may not have been so lucky... -- Paul From list-mgr@ISI.EDU Mon Feb 13 12:33:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 20:34:08 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 20:33:47 -0800 Received: from gangrene.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-20) id ; Mon, 13 Feb 1995 20:33:46 -0800 Received: from localhost.Berkeley.EDU by gangrene.berkeley.edu (8.6.8.1/1.33) id UAA07185; Mon, 13 Feb 1995 20:33:41 -0800 Message-Id: <199502140433.UAA07185@gangrene.berkeley.edu> To: Paul Stewart Cc: mbone Subject: Re: ultrix 4.4 / ipmulti3.3 patches In-Reply-To: Your message of "Mon, 13 Feb 1995 23:05:04 EST." <9502140405.AA06281@hibp.ecse.rpi.edu> Date: Mon, 13 Feb 1995 20:33:41 -0800 From: Rob Robertson yeah, it wasn't the brightest thing i've ever done. rob From list-mgr@ISI.EDU Mon Feb 13 16:25:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 00:26:16 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 00:25:37 -0800 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 00:25:35 -0800 Posted-Date: Tue 14 Feb 95 00:25:30 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 14 Feb 95 00:25:31 PST Date: Tue 14 Feb 95 00:25:30 PST From: Stephen Casner Subject: Re: Upgrading to mrouted V3.3 To: mit@cs.tut.fi Cc: MBONE Message-Id: <792750331.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199502130949.LAA09816@isosotka.cs.tut.fi> Mail-System-Version: Mikko, Thanks for the bug report on the mcast_install script. I have fixed the quoting on that line. Along with the bug fix, I am releasing a new version of the script with a new feature to "mirror" the .../sys directory before applying the patches. This was written by Paul Stewart, with some enhancements to the UI part by me. I have also added another feature to keep track of the success or failure of the patching process, and print a summary at the end. If the patches failed, it won't do the make. As before, you can get the script from ftp://ftp.isi.edu/mbone/mcast_install The plan is to include the script in the tar file for the next release. -- Steve ------- From list-mgr@ISI.EDU Tue Feb 14 06:59:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 07:01:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 06:59:44 -0800 Received: from AWIUNI11.EDVZ.UniVie.AC.AT (helios.edvz.univie.ac.at) by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 06:59:36 -0800 Message-Id: <199502141459.AA07468@venera.isi.edu> Received: from ALIJKU21.BITNET by AWIUNI11.EDVZ.UniVie.AC.AT (IBM VM SMTP V2R2) with BSMTP id 4376; Tue, 14 Feb 95 15:58:15 MEZ Date: Tue, 14 Feb 95 15:56 SET To: terena-ga@TERENA.NL, wg-all@TERENA.NL, newsletter@TERENA.NL, ceec@TERENA.NL, M2107@EUROKOM.IE, tcp-ip@NIC.DDN.MIL, iepg@CNRI.RESTON.VA.US, ietf@CNRI.RESTON.VA.US, ccirn@LBL.GOV, acpccirn@AARNET.EDU.AU, ripe@RIPE.NET, TF-ATM@TERENA.NL, mice-nsc-admin@CS.UCL.AC.UK, mbone, EARN-NOG@GUMNCC.BITNET From: Guenther Schmittner Subject: Summer School 95 Announcement Sorry for any cross-posting. Guenther ------------------------------------------------------------------------ Third International Summer School on Advanced Broadband Communications 26th-30th June 1995 After the success of the "First and Second International Summer Schools on Advanced Broadband Communications" distributed between Aveiro (Portugal) and Madrid (Spain) in July 93 and 94, RACE Project BRAIN is pleased to announce its Third International Summer School on Advanced Broadband Communications to take place from 26th to 30th June 1995. This year the School will be distributed to at least four different and geographically distant sites and will constitute a unique event joining a thorough presentation of ABC (Advanced Broadband Communications) with its real use and demonstration. It will include tutorials, in-depth lectures, panels and demonstration of results achieved within R&D projects. Among others the following issues will be addressed: * Cell based technologies * Access Networks * Evolution Scenarios * Management of ABC Systems. * Multimedia * Future Visions of ABC Most important, the 1995 Summer School itself will be a demonstration of ATM based broadband communications, applications and services where a number of results and achievements from different RACE projects will be shown in real operation. The first 3 days of ABC'95 will provide a technical view of ABC and the second 2 days the user view of applications, market and future trends. The 1995 Summer School will be a distributed event where a multimedia CSCW (Computer Supported Cooperative Work) tele-training application will join the lecture rooms of the different physical sites into a unique virtual lecture room such that lecturers and participants lose the sense of physical separation and work together with full interaction. At least, the following sites will join ABC'95: * Madrid, Spain ( ETSI Telecomunicacion, UPM ) * Aveiro, Portugal ( CET / University of Aveiro ) * Turin, Italy ( CSELT ) * Sophia-Antipolis, France ( Theseus Institute / AGORA ) Switzerland, The Netherlands and Austria will also join Summer School 95 as subsidiary sites. These will incorporate the full set of functionalities as the main sites and aimed to serve a (reduced) local audience. The pan-European ATM trial connecting the National Hosts from countries involved in this event will provide the necessary communication infrastructure for ABC'95. This will require a complex collaboration between several institutions and R&D projects within the framework of EU initiatives. Overall technical co-ordination is the responsibility of the IBER Project. ORGANISING COMMITTEE Eric Scharf, Queen Mary Westfield College, UK Finn Hansen, ASCOM, Switzerland George Williamson, British Telecom, UK Hans Melchior, Swiss Federal Institut of Technology, Switzerland I. Venieris, National Technical University of Athens, Greece James Callaghan, British Telecom, UK Joco Bastos, Portugal Telecom\CET, Portugal John Dobson, University of Newcastle, UK Jose Domingues, Portugal Telecom\CET, Portugal (BRAIN Project Manager) Josi Scarr, PTT Research, Netherlands Juan Quemada, Technical University of Madrid, Spain (ABC'95 Manager) Klaus Franke, Technical University of Chemnitz, Germany Manuel Duarte, University of Aveiro, Portugal (Aveiro site Manager) Pedro Chas, Telefonica, Spain (IBER Project Manager) Ronan O'Boyle, University of Limerick, Ireland Rui Aguiar, University of Aveiro, Portugal Silvana Ferreri, Institut Theseus, France (site manager ) Silvia Ruiz, Technical University of Catalunya, Spain Stefano Guido Coiro, CNR, Turin, Italy (site manager) Stephen Plagemann, SHP Systems Services, Ireland (BRAIN Technical Manager) Tomas de Miguel, Technical University of Madrid, Spain Vasco Lagarto, Portugal Telecom\CET, Portugal Wilfried Maschtera, University of Linz, Austria If you are interested in receiving direct information about ABC'95 please send the following questionnaire by mail, fax or e-mail to: Dept Ing. Telematica (ABC'95) ETSI Telecomunicacion E-28040 Madrid, Spain tel.: +34 1 3367332, fax: +34 1 3367333, email: ABC95@dit.upm.es Name: Company: Address: Telephone: Fax: Email: From list-mgr@ISI.EDU Tue Feb 14 23:29:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 13:30:17 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 13:30:00 -0800 Received: from droopy.laas.fr by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 13:29:57 -0800 Received: from voltaire.laas.fr by droopy.laas.fr; Tue, 14 Feb 1995 22:04:47 +0100 Return-Receipt-To: villemur@laas.fr Received: by voltaire.laas.fr (5.0/SMI-SVR4) id AA04546; Tue, 14 Feb 1995 22:29:24 --100 Date: Tue, 14 Feb 1995 22:29:24 --100 From: villemur@laas.fr (Thierry Villemur) Message-Id: <9502142129.AA04546@voltaire.laas.fr> To: ajit@udel.edu, deering@parc.xerox.com, mbone Subject: Access to IP multicast extensions through the Transport Layer Interface with SOLARIS2 X-Sun-Charset: US-ASCII Content-Length: 888 Hi, In the framework of a future implementation, I am interested about Internet Protocols extensions to multicast messages. Until now, I have used the socket library that gives an easy access to the IP multicast service that you have developped. But, as the current socket library is not fully compatible with the multithreading of SUN SOLARIS2, I would like to use (if possible) the System V Transport Layer Interface supported by SOLARIS 2 on top of IP multicast extensions. Is it possible to fit the TLI parameters for multicast and how can it be done ? I would like to have some information (or some piece of code) about this adaptation and about the data structures that have to be filled and handled. Thanks in advance for your help. Here is my address: Thierry Villemur. LAAS du CNRS 7 Avenue du Colonel Roche 31077 TOULOUSE Cedex. FRANCE. e-mail : villemur@laas.fr From list-mgr@ISI.EDU Tue Feb 14 09:30:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 15:31:16 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 15:31:00 -0800 Received: from scapa.cs.ualberta.ca by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 15:30:58 -0800 Received: from nestow.cs.ualberta.ca by scapa.cs.ualberta.ca id <13791-1>; Tue, 14 Feb 1995 16:30:53 -0700 Subject: Multicast and ATM From: Kannan Thiruvengadam To: mbone Date: Tue, 14 Feb 1995 16:30:47 -0700 (MST) Cc: rem-conf@es.net X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 123 Message-Id: <95Feb14.163053-0700_mst.13791-1+3@scapa.cs.ualberta.ca> Hello, Is anybody working on issues concering the use of Multicast on ATM ? Please share the knowledge. Thanks - Kannan From list-mgr@ISI.EDU Tue Feb 14 13:08:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 17:08:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 17:08:20 -0800 Received: from plains.NoDak.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 14 Feb 1995 17:08:18 -0800 Received: by plains.NoDak.edu; Tue, 14 Feb 1995 19:08:01 -0600 From: "Dr. Ronald J. Vetter" Message-Id: <199502150108.AA05870@plains.NoDak.edu> Subject: Getting Started Problem To: mbone Date: Tue, 14 Feb 1995 19:08:00 -0600 (CST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2230 At NDSU we just configured a Pentium box as a mrouter (running mrouted) under FreeBSD 2.x -- the sd tool does not display any sessions from outside NDSU (and we tested the fact that our sessions are not seen by anyone outside of NDSU either). Internally (of course) everthing works fine. Here is the /etc/mrouted.conf file. # mrouted.conf,v 1.2 1994/09/08 02:51:21 wollman Exp # # This is the configuration file for "mrouted", an IP multicast router. # mrouted looks for it in "/etc/mrouted.conf". # # Command formats: # # cache_lifetime 3600 # pruning on # # phyint [disable] [metric ] [threshold ] [rate_limit ] # [boundary /] # tunnel [srcrt] [metric ] # [threshold ] [rate_limit ] # [boundary /] # # NOTE: any phyint commands MUST precede any tunnel commands # NOTE: boundary commands may appear on a separate line # (OTHER keywords must be on the same line as phyint or tunnel) # NOTE: the mask-len is the no. of leading 1's in the mask # phyint 134.129.125.191 metric 1 threshold 16 tunnel 134.129.125.191 192.147.166.20 metric 1 threshold 32 ---- Our network provider (Northwest Net: 192.147.166.20) is also set up this way. Using network monitoring, we see the two mrouters exchanging lots of info. It seems (at least to me) that something is wrong with our tunnel connection. Anyone have any ideas on what I might try to find this problem? The "map" tool does traverse the MBone and display the proper routers on our machine, so we are connected, but something isn't allowing our sessions to go out, or come in. We are at the end of a tunnel and do not forward to anyone else. Please reply directly to me. I will post the solution when we get this working (anyone else using FreeBSD?). Thanks - Ron -- Dr. Ronald J. Vetter, rvetter@plains.nodak.edu Computer Science Department Phone: (701) 231-7084 IACC Building, Room 258 Fax: (701) 231-8255 North Dakota State University Fargo, North Dakota 58105-5164 From list-mgr@ISI.EDU Wed Feb 15 13:42:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Feb 1995 03:45:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Feb 1995 03:44:39 -0800 Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Feb 1995 03:44:27 -0800 Message-Id: <199502151144.AA20403@venera.isi.edu> Received: from ursa.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Wed, 15 Feb 1995 12:41:21 +0100 X-Mailer: exmh version 1.5.3 12/28/94 To: mbone From: Henning Schulzrinne Subject: Video-on-demand seminar this afternoon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Feb 95 12:42:11 +0100 Sender: schulzrinne@fokus.gmd.de The video-on-demand seminar announced a few days ago will take place at 14.15 central European time or 13.15 GMT, February 15, 1994. As an experiment, we will be using RTP for both audio (nevot) and video (vic). We don't know yet how well multicast travels from Germany to the civilized (that is, non-X.25) Internet world, but unfortunately, please anticipate problems. If you get this message after the fact, you know that we lost IP connectivity once again... Nevot-3.24(beta) is available for sun4, sun5, and sgi on ftp://gaia.cs.umass.edu/pub/hgschulz/nevot/ Earlier versions (from the same server) should work. Further information on the talk is available at: http://www.tk.tu-berlin.de/~rainer/tubkom/kolloquium/tubkom-colloqium.ht ml The session is announced in sd as TUBKOM Kolloquium. ---- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 182 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin URL: http://www.fokus.gmd.de/htbin/info/step/hgs From list-mgr@ISI.EDU Wed Feb 15 04:04:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Feb 1995 12:05:10 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Feb 1995 12:04:54 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Feb 1995 12:04:52 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14490(4)>; Wed, 15 Feb 1995 12:04:18 PST Received: by crevenia.parc.xerox.com id <49859>; Wed, 15 Feb 1995 12:04:10 -0800 From: Bill Fenner To: mbone Subject: Is anyone still using source routed tunnels? Message-Id: <95Feb15.120410pst.49859@crevenia.parc.xerox.com> Date: Wed, 15 Feb 1995 12:04:07 PST I have a suspicion that source routed tunnels have been mildly broken since the 3.1 release. I would like to remove them completely, since they add a layer of complexity to the code, and source-routed tunnels generally cause problems with many routers anyway. Is anyone still using srcrt tunnels? If so, what types of machines are on the ends of the tunnel, and why can't you replace them with encapsulated tunnels? Please respond directly to me, not to the list. Thanks, Bill From list-mgr@ISI.EDU Wed Feb 15 08:50:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Feb 1995 16:52:08 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Feb 1995 16:50:43 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Feb 1995 16:50:41 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14682(1)>; Wed, 15 Feb 1995 16:50:28 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Wed, 15 Feb 1995 16:50:25 -0800 X-Mailer: exmh version 1.5.3 12/28/94 To: Henning Schulzrinne Cc: mbone Subject: Re: Video-on-demand seminar this afternoon In-Reply-To: Your message of "Wed, 15 Feb 95 03:42:11 PST." <199502151144.AA20403@venera.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Feb 1995 16:50:21 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <95Feb15.165025pst.49859@crevenia.parc.xerox.com> In message <199502151144.AA20403@venera.isi.edu> you write: >The video-on-demand seminar announced a few days ago will take place >at 14.15 central European time or 13.15 GMT, February 15, 1994. As an >experiment, we will be using RTP for both audio (nevot) and video >(vic). Your sd advertiesment has no "rtp" option on the audio media, and no "fmt:vic" option on the video media, therefore my .sd.tcl launches vat and nv. If you are going to be using new tools, please craft your session advertisements to not assume that everyone wants those tools as defaults. Bill From list-mgr@ISI.EDU Thu Feb 16 18:23:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 08:25:58 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 08:25:36 -0800 Received: from obelix.hrz.tu-chemnitz.de by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 08:23:47 -0800 Received: from tricia.hrz.tu-chemnitz.de by obelix.hrz.tu-chemnitz.de with Local SMTP (PP) id <03653-0@obelix.hrz.tu-chemnitz.de>; Thu, 16 Feb 1995 17:23:20 +0100 Received: by tricia.hrz.tu-chemnitz.de (4.1/SMI-4.1) id AA09307; Thu, 16 Feb 95 17:23:17 +0100 Date: Thu, 16 Feb 1995 17:23:16 +0100 (MET) From: "X.500-Manager DE" To: rem-conf@es.net Cc: mbone Subject: Announcement - KiVS'95 - 22.-24. February 1995 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We will broadcast a part of this conference over the internet using Mbone. The opening and the first plenary session we will be broadcasted with ttl 127 and for the rest of the conference we will use ttl 47 (Germany only). We will send with vat, vic/h261 and wb. An announcement in sd will be made soon. --------------------------------------------------------- Kommunikation in Verteilten Systemen - KiVS '95 "Neue Laender - Neue Netze - Neue Dienste" 22. - 24. Februar 1995 ITG/GI - Fachtagung Technische Universitaet Chemnitz-Zwickau --------------------------------------------------------- 22. February: ------------- 9:30 - 11:00 (MET): ------------------ opening welcome: - B.Butscher (Speaker of section "Kommunikation und verteilte Systeme) welcoming speech: - Prof. Dr. Kurt Biedenkopf, ministerpresident of the Free State of Saxony - Dr. P. Seifert, mayor of city Chemnitz - Prof. Dr. G. Hecht, rector of the Technical University of Chemnitz-Zwickau plenary session I: - Programs for Networking Research and Testbed Activities in the U.S. Prof. Dr. Domenico Ferrari, University of California, Berkeley, ICSI For more information see (German language): URL:http//www.tu-chemnitz.de/~apf/kivs95.html URL:http//www.tu-chemnitz.de/~apf/kivs95tagung.html Enrico Mowitz .............................................................................. Mail: ds-manager@tu-chemnitz.de S=ds-manager;PRMD=tu-chemnitz;ADMD=d400;C=de WWW-URL: http://tricia.hrz.tu-chemnitz.de Telefon: +49 371 531-1379 .............................................................................. From list-mgr@ISI.EDU Thu Feb 16 04:13:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 08:14:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 08:13:41 -0800 Received: from heliostat.uchicago.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 08:13:40 -0800 Received: (khopper@localhost) by heliostat.uchicago.edu (8.6.9/8.6.5) id KAA04772 for mbone@isi.edu; Thu, 16 Feb 1995 10:13:38 -0600 Date: Thu, 16 Feb 1995 10:13:38 -0600 From: khopper@midway.uchicago.edu Message-Id: <199502161613.KAA04772@heliostat.uchicago.edu> To: mbone Subject: [Q] how to choose a multicast address ? Reply-To: k-hopper@uchicago.edu X-Sun-Charset: US-ASCII O.K. flame suit on... We are successfully multicasting around our campus using vic/vat. How do we choose an APPROPRIATE multicast address ? and port ? for campus experimentation ? We have set our ttl down as low as possible ( 64 seems to work O.K.) to be good network citizens, but the choice of 230.2.230.99/33298 was arbitrary. Is there a proper algorithm to use ? Thanks, Ken Hopper The University of Chicago Academic Information Technologies (v) (312)-702-2787 email: k-hopper@uchicago.edu (f) (312)-702-3219 From list-mgr@ISI.EDU Thu Feb 16 04:27:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 12:31:00 -0800 Received: from hal.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 12:30:58 -0800 Received: from dillia.hal.com by hal.com (4.1/SMI-4.1.1) id AA22153; Thu, 16 Feb 95 12:30:58 PST Received: by dillia.hal.com (5.x/SMI-4.1.2) id AA07223; Thu, 16 Feb 1995 12:27:48 -0800 From: centaur@hal.com (Paul Blair) Message-Id: <9502162027.AA07223@dillia.hal.com> Subject: Looking for help setting up mbone on a firewall To: mbone-na Date: Thu, 16 Feb 1995 12:27:47 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text I am just getting MBONE going on my site. So far, I have our firewall machine receiving MBONE fine. I have another tunnel set up to a site outside our firewall from the firewall machine which is also receiving MBONE broadcasts, and I am trying to set it up so that machines inside the firewall on the second interface of our firewall machine can get MBONE broadcasts. So far I have run into 2 problems... 1) Machines inside the firewall don't see outside broadcasts... I have the interface turned on, but the external firewall interface doesn't seem to be talking to the internal interface. I can do mbone type things internally fine, but external stuff doesn't show up on internal SD displays, etc... Could someone give me some examples from a similar configuration (Sun 4.1.X firewall, 2 ethernet interfaces) 2) The machine I first chose to be the internal tunnel receiver, A SunOS 4.1.3 machine, doesn't seem to have built properly. The other 2 4.1.3 machines I have installed work fine, but this one gets an IP_ADD_MEMBERSHIP: Can't assign requested address message whenever I try to start up sd or any other tool. mrouted seems to work fine though, and I'm not sure what I did wrong since I used the same process as on the other machines I set up... Any help would be appreciated. Please reply via e-mail, as I have not yet been added to this list. Paul Blair HaL Computer Systems From list-mgr@ISI.EDU Thu Feb 16 08:44:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 16:45:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 16:44:11 -0800 Received: from skaface.arc.nasa.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 16:44:09 -0800 Received: from localhost.arc.nasa.gov by skaface.arc.nasa.gov (8.6.8/1.5T) id QAA27145; Thu, 16 Feb 1995 16:44:08 -0800 Message-Id: <199502170044.QAA27145@skaface.arc.nasa.gov> X-Mailer: exmh version 1.5.3 12/28/94 To: mbone Cc: evans@skaface.arc.nasa.gov Subject: mrouted 3.3 and pruning Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Feb 1995 16:44:07 -0800 From: Dan Evans Hi, I need a quick sanity check here. If my mbone provider is running mrouted 3.3 on their tunnel machine do I have to run mrouted 3.3 on my leaf-node, tunnel endpoint machine to take advantage of pruning? i.e. Provider / | ------- / ------- | |mrouted|/ tunnel |mrouted| | ------- | 3.3 |---------------| 2.2 |=======| | |\ | | | ------- \ ------- | \ |LAN With this configuration will multicast traffic for sessions that are *not* being viewed/listened to at my site traverse the tunnel? My gut says no! But I want to be sure. Cheers...Dan From list-mgr@ISI.EDU Thu Feb 16 09:29:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 17:30:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 17:30:17 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 17:30:15 -0800 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14609(5)>; Thu, 16 Feb 1995 17:30:05 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Thu, 16 Feb 1995 17:29:59 -0800 To: Dan Evans Cc: mbone Subject: Re: mrouted 3.3 and pruning In-Reply-To: evans's message of Thu, 16 Feb 95 16:44:07 -0800. <199502170044.QAA27145@skaface.arc.nasa.gov> Date: Thu, 16 Feb 1995 17:29:53 PST Sender: Steve Deering From: Steve Deering Message-Id: <95Feb16.172959pst.12174@skylark.parc.xerox.com> Provider / | ------- / ------- | |mrouted|/ tunnel |mrouted| | ------- | 3.3 |---------------| 2.2 |=======| | |\ | | | ------- \ ------- | \ |LAN > With this configuration will multicast traffic for sessions > that are *not* being viewed/listened to at my site traverse > the tunnel? Yes. Multicast traffic will reach all pre-3.x mrouteds in the MBone, because they don't know how to send prune messages to stop the traffic. To keep unwanted traffic out of your site, all your intra-site mrouteds, plus your provider's mrouted, must be version 3.x or later. Steve From list-mgr@ISI.EDU Thu Feb 16 09:42:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 17:43:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 17:43:06 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 17:43:04 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14536(5)>; Thu, 16 Feb 1995 17:42:50 PST Received: by crevenia.parc.xerox.com id <49859>; Thu, 16 Feb 1995 17:42:39 -0800 From: Bill Fenner To: evans@skaface.arc.nasa.gov, mbone Subject: Re: mrouted 3.3 and pruning Message-Id: <95Feb16.174239pst.49859@crevenia.parc.xerox.com> Date: Thu, 16 Feb 1995 17:42:39 PST You need to run mrouted 3.x all the way to the LAN to get the benefits of pruning. The 2.x version has no mechanism with which to tell the upstream router what groups are being listened to (that's what pruning is all about.) Bill From list-mgr@ISI.EDU Thu Feb 16 13:31:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 21:27:19 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 21:27:13 -0800 Received: by rx7.ee.lbl.gov for mbone-na@isi.edu (5.65/1.44r) id AA16395; Thu, 16 Feb 95 21:31:05 -0800 Message-Id: <9502170531.AA16395@rx7.ee.lbl.gov> To: trouble@es.net Cc: mbone-na Subject: serious multicast routing loop at ANL.GOV Date: Thu, 16 Feb 95 21:31:03 PST From: Van Jacobson There's a very serious multicast routing loop at Argonne National Lab. Most multicast packets originating at Argonne are being duplicated hundreds of times. This is pretty much trashing the mbone. The ESNet tunnel to Argone on anl-mr1.es.net (the tunnel to dns2.anl.gov) should probably be disabled until this problem is found and fixed. It's not clear what's causing the problem but it appears that a cisco PIM router has recently been turned on at Argonne (woody.ctd.anl.gov, 146.137.10.119) and cisco's running PIM have been implicated in several mbone loops. Attached is a 30 second tcpdump trace showing the problem. One packet was sent from medusa.aps.anl.gov which then got duplicated 1437 times. All other traffic on the mbone was wiped out while this was going on. - Van Jacobson 20:51:15.903252 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 179, id 35085) 20:51:16.444590 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 177, id 35085) 20:51:16.445673 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 175, id 35085) 20:51:16.819652 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 175, id 35085) 20:51:16.820261 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 173, id 35085) 20:51:16.822826 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 173, id 35085) 20:51:16.823679 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 171, id 35085) 20:51:17.044478 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 173, id 35085) 20:51:17.046181 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 171, id 35085) 20:51:17.048021 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 171, id 35085) 20:51:17.051097 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 171, id 35085) 20:51:17.052735 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 169, id 35085) 20:51:17.054462 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 169, id 35085) 20:51:17.056167 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.249421 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 171, id 35085) 20:51:17.260052 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 169, id 35085) 20:51:17.260143 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 169, id 35085) 20:51:17.261476 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 169, id 35085) 20:51:17.264344 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.266311 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.267997 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 169, id 35085) 20:51:17.271471 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.273408 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.275000 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.276695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.278463 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.280157 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.281753 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 163, id 35085) 20:51:17.547685 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.551198 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.552918 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.554546 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.556287 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 163, id 35085) 20:51:17.558035 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:17.559789 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:17.561459 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:17.563152 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:17.564894 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:17.916085 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.918182 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 163, id 35085) 20:51:17.919785 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 163, id 35085) 20:51:17.924402 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:17.925559 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 163, id 35085) 20:51:17.927604 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:17.929008 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:17.930765 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:17.965791 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:17.967268 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:18.518220 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 163, id 35085) 20:51:18.519659 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:18.521192 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:18.523772 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:18.525458 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:18.527515 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:18.529375 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:18.531066 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:18.532966 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:18.534659 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:18.536998 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:18.538743 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:18.540436 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:18.545776 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:18.546256 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:18.552370 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:18.553806 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:18.555760 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:18.557474 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:18.559089 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:19.264010 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:19.265624 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:19.267543 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:19.269402 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:19.271035 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:19.275789 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:19.276366 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:19.278222 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:19.279935 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:19.281640 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:19.283368 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:19.285073 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:19.286759 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:19.288808 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:19.290551 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:19.292109 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:19.293756 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:19.295374 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.004656 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:20.006322 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:20.008354 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:20.010222 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:20.012301 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:20.014198 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:20.018860 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:20.020378 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:20.022249 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:20.023842 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.025543 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.027491 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.029142 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.030789 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.032448 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.034256 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:20.035889 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:20.752524 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:20.752589 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.752686 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.752982 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:20.753367 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:20.755165 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.760128 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:20.760599 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.762558 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.764298 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.765987 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.767878 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:20.769427 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:20.771029 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:20.772618 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:20.774259 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.775838 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:21.468332 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:21.469938 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:21.476963 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:21.478657 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:21.480520 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:21.482146 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:21.483814 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:21.485556 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:21.487502 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:21.489034 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:21.490751 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:21.492483 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:21.494167 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:21.495891 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:21.498625 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:21.499391 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:21.501385 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:21.502995 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:21.504556 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:21.506455 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:21.508151 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:21.513059 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:21.515102 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:21.516346 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.206730 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:22.210074 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:22.216275 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:22.218539 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:22.220594 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:22.223553 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:22.225293 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.227334 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:22.228897 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.230568 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.232253 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.234157 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.235789 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:22.237873 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.239361 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.240985 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.242922 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.244513 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.246216 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:22.248124 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.253250 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.254885 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:22.256552 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:22.258218 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:22.956875 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:22.958693 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:22.965607 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:22.967338 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:22.969622 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.971294 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:22.973162 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.974762 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:22.976536 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:22.978285 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.979963 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:22.981611 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:22.983354 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:22.988372 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:22.988643 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:22.990357 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:22.992101 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:22.993884 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.997425 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.999034 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:23.000680 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:23.707883 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:23.709722 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:23.711222 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:23.713837 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:23.715975 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:23.717669 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:23.719367 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:23.721196 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:23.722659 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:23.726483 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:23.728335 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:23.729916 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:23.731716 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:23.733483 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:23.735143 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:23.736805 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:23.738634 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:23.742211 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:23.744014 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:23.745717 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:23.747560 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:23.749271 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:23.750889 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:23.756494 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:24.456321 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:24.459300 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:24.463076 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:24.464575 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:24.474076 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:24.474165 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:24.476669 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:24.477389 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:24.481361 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:24.484461 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:24.487926 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:24.489319 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:24.491118 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:24.492873 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:24.494503 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:24.496067 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:24.497920 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:24.499566 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:24.501428 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:24.503201 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:24.504712 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:24.506495 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:24.508165 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:24.509962 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:24.515659 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:25.206838 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:25.209368 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:25.210825 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:25.216859 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:25.217452 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.219111 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:25.223410 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:25.226015 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:25.228051 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.229669 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.231297 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.233163 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.234766 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.236469 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.238275 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.240007 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.241855 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.243509 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.245192 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.246993 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.248664 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.250270 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.251978 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.254028 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.256621 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:25.257280 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:25.259069 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:25.260615 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:25.262371 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:25.266977 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:25.936823 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:25.943762 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:25.945401 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.947375 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.950200 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.952969 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:25.954764 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.956860 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.958886 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.960543 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.962132 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.963854 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.965552 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.967362 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:25.968988 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.971085 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.972941 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.974592 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.976310 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.978087 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.979773 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.985694 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.986267 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.988091 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.989725 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:25.991478 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.993169 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:25.995117 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:25.996734 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:25.999048 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:26.000477 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:26.002184 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:26.005762 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:26.682127 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:26.684829 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:26.686523 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:26.688554 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:26.690161 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:26.691795 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:26.693697 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:26.695390 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:26.698038 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:26.699724 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:26.702473 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:26.704393 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:26.707053 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:26.711626 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.712214 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:26.715899 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:26.719683 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.721555 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.723188 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.724867 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.726754 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.728626 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.731761 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.733930 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.734937 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.736712 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.738445 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.740310 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.742039 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.743787 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.745465 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:26.747693 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:26.752686 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:26.752941 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:26.754559 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:26.756268 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:27.430390 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:27.431651 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:27.433420 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:27.435021 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:27.438523 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:27.440161 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:27.441652 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:27.444556 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:27.449191 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:27.450468 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:27.452538 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:27.454787 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:27.456419 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:27.458721 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:27.460753 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.462535 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:27.464585 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.466651 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.468566 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.473580 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.475308 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.477416 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.479318 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.481557 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:27.483722 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.485592 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.487531 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.489319 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.491211 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.492793 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.494504 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:27.496176 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.498141 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:27.499845 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.501745 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:27.503345 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:27.505086 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:27.506586 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:27.508945 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:27.510057 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:27.511794 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:27.513355 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:28.177822 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:28.178595 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:28.180846 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:28.182737 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:28.184385 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.186166 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.187922 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.189462 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.191267 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.193025 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.194657 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:28.196361 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.198262 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:28.199836 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.201591 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.203353 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.205080 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:28.208825 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.210649 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.212401 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.214050 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.216030 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.217860 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.219393 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.221080 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.222800 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.228105 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.228498 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.230172 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.231802 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.233478 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.235137 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.236733 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.249823 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.249889 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.250203 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.250451 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.251708 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.253385 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.255108 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:28.258818 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:28.260541 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:28.262384 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:28.263990 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:28.265659 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:28.270366 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:28.927803 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:28.943686 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.943833 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.944092 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.944343 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.945511 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.947273 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.948831 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:28.958556 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.958622 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:28.958710 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.966239 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.966306 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.966719 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.966967 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.968640 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:28.970422 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.972004 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.973720 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.978728 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.981032 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.990955 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:28.991041 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:28.991114 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:28.994548 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.994813 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:28.999582 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.000509 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:29.002326 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.003844 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.005533 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.007363 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.009078 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.012500 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.014197 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.016326 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.018092 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:29.019572 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:29.021338 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:29.022983 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:29.024677 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:29.029655 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:29.029902 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:29.665708 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:29.669911 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:29.673936 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:29.675515 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:29.677569 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:29.678980 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:29.680822 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:29.682565 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:29.684287 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:29.685958 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:29.687934 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:29.689407 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.691107 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.692744 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.694467 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.696140 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:29.697948 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:29.702915 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.703196 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.704953 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.706540 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.708526 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:29.710027 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.711742 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:29.713725 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.715123 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.716867 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:29.718606 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.720781 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.722060 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.723776 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.725685 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:29.727483 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.729074 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.730682 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:29.732544 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.734169 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.743720 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:29.743870 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:29.744120 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:29.744368 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:29.745529 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:29.747260 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:29.749120 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:29.750644 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:29.752255 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:29.753849 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:29.755490 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:29.757314 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:30.391168 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:30.391259 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:30.391494 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:30.391741 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:30.393059 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:30.396505 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:30.401330 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:30.401929 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.403974 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.405495 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.407520 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.409056 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.410810 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:30.412505 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:30.414241 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:30.416071 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:30.420835 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:30.423444 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:30.425140 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.426883 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:30.428782 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.430463 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.432166 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.434020 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.435648 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.437806 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.439162 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:30.441049 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.442656 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.444307 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.445995 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.448403 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:30.449670 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.451367 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.453089 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:30.454904 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.456702 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.458412 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:30.460098 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.462278 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.463587 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.465336 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.467040 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:30.468760 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:30.470278 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:30.471871 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:30.473498 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:30.478657 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:30.478913 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:30.480326 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:31.108324 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:31.108740 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:31.110667 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.112222 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.114246 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.115616 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.117562 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.119140 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.120959 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.122638 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.124351 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.126082 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:31.128237 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.129759 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.131376 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:31.133028 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.134667 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:31.136478 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.138264 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.140059 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.141753 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.143491 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.145290 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.147315 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.148735 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.153572 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.154061 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.155860 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.157863 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.159348 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.161068 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.162968 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.164553 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.166257 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.168271 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.169972 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.171689 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.173611 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.175338 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.177092 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.178712 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.180442 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.182215 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.183979 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.188855 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.189308 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.191035 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.194356 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.195920 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.199581 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.201342 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.203296 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.205056 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.206786 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.208528 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.210211 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.211918 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.213555 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.215253 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.216944 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.218639 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.221527 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.223103 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:31.224672 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.226466 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:31.228189 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:31.229771 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:31.231454 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:31.854719 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:31.858021 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.859909 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:31.861676 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.863668 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.864908 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.866681 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.871617 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.872313 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.874440 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.876079 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.877924 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.879569 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.881354 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.883062 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.884782 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.886773 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.888538 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.890143 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.891870 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.895004 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.896739 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.898448 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.900350 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.901970 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.903668 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.908578 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.909044 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.911086 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.914603 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.916516 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.918106 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.919702 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.921494 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.923213 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.925095 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.926703 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.928490 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.930124 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.931904 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.933695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.935387 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.937333 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.938864 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.940610 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.942306 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.944021 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.945697 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.947747 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.949147 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.950772 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.952329 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.954015 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.955570 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:31.957421 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:32.610516 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:32.611992 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:32.619039 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.621816 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:32.623716 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.625469 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.627109 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.628830 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.630566 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.632381 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.634117 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.636002 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:32.637777 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.639371 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.641201 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.643036 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.644642 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.646370 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.648212 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.649902 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.651744 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.653422 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.655134 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.657118 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.659106 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.660754 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.662660 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.664290 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.666145 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.668051 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.669889 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.671577 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.676464 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.677455 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.679113 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.680834 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.682471 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.684276 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.686005 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.688093 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:32.689540 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.691245 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:32.692888 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.694775 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.696288 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.698091 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.699726 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.701424 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.703015 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.704600 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.706222 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.707975 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:32.709713 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:33.351931 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:33.353258 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:33.356327 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:33.359765 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.361644 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.363339 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.366780 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.370291 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.371890 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.373581 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.375343 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.376966 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.378819 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.380489 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.382232 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.383895 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.385594 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.387459 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.389018 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.390915 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:33.392540 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.394282 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.396082 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.397934 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.399632 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.401285 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.402999 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.404660 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.406315 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.408403 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.409979 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.411622 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.413565 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.415293 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:33.417004 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.418787 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.420441 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.422109 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.425850 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:33.427872 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.429507 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:33.431209 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.432954 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.434643 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.436338 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.438185 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:33.440344 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.441257 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.443084 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.444812 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:33.446788 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.448343 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.450032 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:33.451682 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.453227 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:34.091724 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:34.093336 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:34.098174 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.098718 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:34.100638 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.105460 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.107146 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.111124 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.113484 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.115222 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.117401 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.118832 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.120673 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.122185 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.124011 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.125687 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.127906 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.129299 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.131057 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.132685 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.134586 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.136188 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.137982 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.139656 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.143436 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.145207 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.146901 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.151754 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.152245 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.154137 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.155865 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.157947 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.159263 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.161088 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.162856 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.164819 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.166477 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.168427 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.170100 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.171724 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.173426 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.175422 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.177170 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.179070 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.180695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.182416 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.184108 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.185763 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.187493 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:34.190353 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.191947 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.193514 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.195156 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.196951 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.198596 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:34.844913 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.850197 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.851913 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.853593 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.856622 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.860438 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.862337 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.864018 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.865644 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.867682 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.869093 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.870766 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.872511 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.874484 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.876018 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.877903 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.879408 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.881039 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.882848 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.884602 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.886641 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.891201 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.892208 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:34.893943 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:34.897147 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.898753 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.900702 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.902285 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.904019 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:34.905724 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.907710 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.909357 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.911077 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.912692 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.914577 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.918012 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.919969 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.921280 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.923021 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.924785 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.926529 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:34.928132 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.929800 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:35.592615 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.594278 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.596119 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.597881 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.599471 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.601143 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.605997 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.606570 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.608538 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.610232 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:35.611868 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.613645 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.615390 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.617458 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.619198 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.620761 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.622500 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.624401 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.626079 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.627918 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.629506 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.631489 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.633037 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.634739 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.636506 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:35.638343 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:35.640226 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:35.641852 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.643732 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.645579 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.647370 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.648960 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:35.650863 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.652516 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.654188 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.656208 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:35.660868 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.661155 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.663536 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.664495 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:35.666316 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.667928 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.669562 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.671536 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.673208 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:36.327112 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:36.328426 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.338435 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.338603 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.338860 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.339112 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.340262 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.342130 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.343788 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.345421 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.355853 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.356645 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.358654 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.360400 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.362225 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.363999 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.365803 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.375578 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.375805 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.376061 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.376307 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.377379 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.379090 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.380880 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.382620 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:36.389357 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:36.391089 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:36.392117 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.393913 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.395792 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.397732 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.401434 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.403312 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.404938 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.406856 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.408390 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.410004 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.411580 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.413229 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.414900 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:36.420072 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.422210 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.424015 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.425788 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.427625 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.429135 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.431029 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:37.056475 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:37.058931 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.061814 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.063406 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.064889 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.066749 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.068607 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.070324 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.072120 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.073866 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.075788 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:37.077492 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.080973 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:37.082731 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.084519 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.086099 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.091061 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.091510 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.093300 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.095027 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.096724 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.098460 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.100097 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.101856 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:37.105751 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.107738 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:37.109210 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:37.110935 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.112859 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.114485 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.116144 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.118379 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.119345 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.121354 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:37.122926 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.124695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:37.126530 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.128364 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.129913 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.131643 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:37.133411 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:37.135329 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.136908 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.138546 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.140220 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.141854 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.813084 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.816177 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.820623 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.824316 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.826231 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:37.830116 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:37.832187 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.834286 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.836386 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.839031 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.840763 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.842568 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.844697 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.846556 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.848351 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.850268 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.852121 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.853744 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.855535 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.857522 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.859340 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:37.860921 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:37.862782 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:37.864235 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.866168 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:37.867958 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.869632 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.879680 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:37.879847 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.880100 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.880348 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.881066 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.886145 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.886373 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.889696 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.891238 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.892870 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.894532 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.896206 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.897928 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.899521 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.901169 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.902656 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.904336 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.537886 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:38.538138 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.540228 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:38.546596 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:38.548516 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.550248 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.551925 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.553836 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:38.555522 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.557287 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:38.558926 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:38.561130 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.562441 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:38.564166 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.565855 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:38.567776 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.572382 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.572907 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:38.574825 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.576545 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.578459 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.580089 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.581836 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.583512 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:38.585401 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:38.587086 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.588783 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:38.590611 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.592242 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:38.593947 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:38.595801 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.597604 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.599174 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:38.600743 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.602380 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.604127 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.605727 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.607377 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.608963 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.610516 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.262458 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:39.264218 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.265967 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.276011 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:39.276101 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.276800 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.280616 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:39.282456 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.283992 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:39.285723 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.287915 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.289269 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.291058 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.293000 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:39.302323 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:39.302404 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:39.303793 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:39.304926 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:39.306726 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.308234 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.310045 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.311748 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:39.313741 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.315083 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:39.324918 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.324999 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:39.325337 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:39.325585 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.326552 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:39.336148 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.336238 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:39.336549 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.336796 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.337989 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.341281 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.342875 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.344608 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.346181 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.348231 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.357471 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.357532 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.358033 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:39.358106 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.359209 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.015426 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:40.016774 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.018888 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.020778 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.022343 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.024054 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:40.025943 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.027764 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.029318 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.031047 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.032726 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.034432 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.038195 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.039666 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.041607 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.044562 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.046293 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:40.048163 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.049668 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.051373 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.053091 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.054933 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.056530 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.058295 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.059876 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.061817 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:40.065401 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.067198 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.068901 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.070565 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:40.072249 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.074253 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.075874 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.077987 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.079714 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.081453 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.083252 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.085153 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.086748 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.089800 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.091385 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.092877 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.094501 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.096261 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.098061 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.099672 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.755992 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.758310 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.759999 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.763421 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.765326 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.766971 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.768739 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.770419 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.772141 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.773788 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.775449 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.777536 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.787164 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:40.787256 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.787561 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.787810 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:40.789167 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:40.790709 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.799062 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.799805 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.801492 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.803295 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:40.805044 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.806695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.808465 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.810187 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.811928 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.813597 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.815457 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.817156 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.818804 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.820613 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.822246 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.824141 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.825712 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.827928 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.829140 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.830877 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.832588 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.835969 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.837762 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.839255 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.840887 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.510387 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:41.511858 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:41.513945 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:41.515164 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.517148 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:41.518962 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.523810 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.524077 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.525700 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.527923 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:41.529182 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:41.530982 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:41.532836 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.534525 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.536180 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:41.537986 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.539714 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:41.541390 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:41.543207 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:41.544987 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.546680 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.548405 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.550155 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:41.551869 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:41.553464 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:41.555150 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:41.556855 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:41.561695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.562171 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:41.563803 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.565785 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.567824 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:41.569360 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.571192 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:41.572961 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.574626 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.576237 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:41.578019 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.581738 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.583575 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.585318 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.587135 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.588838 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.592179 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.593799 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.595710 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:41.597563 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.255948 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:42.257791 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.259428 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.263201 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.264813 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.266497 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.268342 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.269995 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.271749 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.273787 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.275238 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:42.280038 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:42.280510 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.282500 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:42.283959 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:42.285943 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:42.288047 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:42.289402 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:42.291190 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:42.292852 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.294737 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.296357 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.300096 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.301921 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:42.303694 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.305410 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:42.307186 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:42.309395 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:42.310647 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:42.312451 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:42.314841 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.315890 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.318033 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.319549 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.321117 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.324848 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.326390 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.328647 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.333279 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.333735 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.335732 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.337631 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.339029 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.340816 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.342621 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.344668 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.346074 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.347813 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.003690 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:43.004958 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.016545 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:43.016638 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.016716 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.017008 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.018202 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.019812 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.021296 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.025199 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.027207 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.029278 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.030683 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.033055 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.034667 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.045488 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.047264 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.048955 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.050640 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.055500 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.056107 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:43.061051 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.061705 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:43.063560 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.064869 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:43.066521 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:43.069555 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:43.074611 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.074875 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.079579 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.080290 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.082224 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.084123 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.085678 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.087877 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.089242 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.091066 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.092930 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.094533 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.096040 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.098018 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.099408 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.101155 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.752695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.760433 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.764409 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.766667 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.768585 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.770404 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.771961 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.776796 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.779125 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.781138 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.782834 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.791663 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.793299 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.795435 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.797739 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:43.800798 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.805802 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.806069 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.808432 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.809557 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.811341 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.812936 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.814622 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.816315 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.820057 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.821762 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.823389 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.825013 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.826757 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.828663 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.830344 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.835834 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.509531 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:44.511123 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.513175 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.520079 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.526270 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:44.528197 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.537067 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.546092 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:44.547669 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.550437 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:44.554170 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:44.555993 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.562348 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.566471 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:45.252298 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:45.274022 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:45.292793 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) From list-mgr@ISI.EDU Thu Feb 16 14:27:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 22:28:12 -0800 Received: from beagle.nersc.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Feb 1995 22:27:54 -0800 Received: from localhost by beagle.nersc.gov; (5.65/1.1.8.2/18May94-1051AM) id AA01460; Thu, 16 Feb 1995 22:27:41 -0800 Message-Id: <9502170627.AA01460@beagle.nersc.gov> To: Van Jacobson Cc: trouble@es.net, mbone-na, lwinkler@anl.gov, noc@anl.gov Subject: Re: TTS# 0242 serious multicast routing loop at ANL.GOV In-Reply-To: Your message of "Thu, 16 Feb 95 21:31:03 PST." <9502170531.AA16395@rx7.ee.lbl.gov> Date: Thu, 16 Feb 95 22:27:41 -0800 From: "Joe Burrescia" X-Mts: smtp Van, I turned off the tunnel to ANL till we can get the site people to look at it. Please let us know if you see any other problems. -- Joe Burrescia (ESnet) --- Prompting message There's a very serious multicast routing loop at Argonne National Lab. Most multicast packets originating at Argonne are being duplicated hundreds of times. This is pretty much trashing the mbone. The ESNet tunnel to Argone on anl-mr1.es.net (the tunnel to dns2.anl.gov) should probably be disabled until this problem is found and fixed. It's not clear what's causing the problem but it appears that a cisco PIM router has recently been turned on at Argonne (woody.ctd.anl.gov, 146.137.10.119) and cisco's running PIM have been implicated in several mbone loops. Attached is a 30 second tcpdump trace showing the problem. One packet was sent from medusa.aps.anl.gov which then got duplicated 1437 times. All other traffic on the mbone was wiped out while this was going on. - Van Jacobson 20:51:15.903252 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 179, id 35085) 20:51:16.444590 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 177, id 35085) 20:51:16.445673 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 175, id 35085) 20:51:16.819652 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 175, id 35085) 20:51:16.820261 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 173, id 35085) 20:51:16.822826 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 173, id 35085) 20:51:16.823679 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 171, id 35085) 20:51:17.044478 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 173, id 35085) 20:51:17.046181 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 171, id 35085) 20:51:17.048021 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 171, id 35085) 20:51:17.051097 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 171, id 35085) 20:51:17.052735 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 169, id 35085) 20:51:17.054462 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 169, id 35085) 20:51:17.056167 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.249421 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 171, id 35085) 20:51:17.260052 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 169, id 35085) 20:51:17.260143 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 169, id 35085) 20:51:17.261476 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 169, id 35085) 20:51:17.264344 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.266311 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.267997 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 169, id 35085) 20:51:17.271471 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.273408 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.275000 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.276695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.278463 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.280157 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.281753 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 163, id 35085) 20:51:17.547685 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 167, id 35085) 20:51:17.551198 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.552918 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.554546 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.556287 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 163, id 35085) 20:51:17.558035 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:17.559789 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:17.561459 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:17.563152 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:17.564894 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:17.916085 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 165, id 35085) 20:51:17.918182 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 163, id 35085) 20:51:17.919785 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 163, id 35085) 20:51:17.924402 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:17.925559 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 163, id 35085) 20:51:17.927604 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:17.929008 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:17.930765 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:17.965791 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:17.967268 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:18.518220 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 163, id 35085) 20:51:18.519659 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:18.521192 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:18.523772 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:18.525458 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:18.527515 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:18.529375 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:18.531066 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:18.532966 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:18.534659 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:18.536998 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:18.538743 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:18.540436 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:18.545776 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:18.546256 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:18.552370 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:18.553806 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:18.555760 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:18.557474 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:18.559089 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:19.264010 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 161, id 35085) 20:51:19.265624 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:19.267543 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:19.269402 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:19.271035 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:19.275789 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:19.276366 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:19.278222 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:19.279935 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:19.281640 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:19.283368 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:19.285073 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:19.286759 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:19.288808 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:19.290551 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:19.292109 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:19.293756 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:19.295374 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.004656 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 159, id 35085) 20:51:20.006322 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:20.008354 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:20.010222 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 157, id 35085) 20:51:20.012301 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:20.014198 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:20.018860 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:20.020378 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:20.022249 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:20.023842 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.025543 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.027491 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.029142 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.030789 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.032448 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.034256 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:20.035889 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:20.752524 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 155, id 35085) 20:51:20.752589 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.752686 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.752982 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:20.753367 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:20.755165 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.760128 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:20.760599 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:20.762558 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.764298 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.765987 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.767878 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:20.769427 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:20.771029 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:20.772618 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:20.774259 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:20.775838 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:21.468332 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 153, id 35085) 20:51:21.469938 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:21.476963 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:21.478657 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:21.480520 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:21.482146 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:21.483814 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:21.485556 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:21.487502 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:21.489034 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:21.490751 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:21.492483 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:21.494167 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:21.495891 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:21.498625 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:21.499391 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:21.501385 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:21.502995 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:21.504556 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:21.506455 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:21.508151 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:21.513059 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:21.515102 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:21.516346 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.206730 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 151, id 35085) 20:51:22.210074 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:22.216275 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:22.218539 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:22.220594 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:22.223553 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:22.225293 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.227334 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:22.228897 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.230568 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.232253 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.234157 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.235789 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:22.237873 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.239361 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.240985 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.242922 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.244513 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.246216 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:22.248124 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.253250 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.254885 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:22.256552 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:22.258218 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:22.956875 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 149, id 35085) 20:51:22.958693 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 147, id 35085) 20:51:22.965607 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:22.967338 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:22.969622 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.971294 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:22.973162 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:22.974762 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:22.976536 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:22.978285 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.979963 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:22.981611 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:22.983354 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:22.988372 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:22.988643 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:22.990357 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:22.992101 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:22.993884 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.997425 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:22.999034 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:23.000680 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:23.707883 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:23.709722 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 145, id 35085) 20:51:23.711222 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:23.713837 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:23.715975 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:23.717669 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:23.719367 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:23.721196 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:23.722659 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:23.726483 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:23.728335 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:23.729916 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:23.731716 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:23.733483 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:23.735143 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:23.736805 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:23.738634 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:23.742211 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:23.744014 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:23.745717 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:23.747560 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:23.749271 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:23.750889 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:23.756494 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:24.456321 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 143, id 35085) 20:51:24.459300 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:24.463076 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:24.464575 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:24.474076 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:24.474165 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:24.476669 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:24.477389 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:24.481361 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:24.484461 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:24.487926 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:24.489319 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:24.491118 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:24.492873 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:24.494503 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:24.496067 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:24.497920 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:24.499566 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:24.501428 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:24.503201 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:24.504712 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:24.506495 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:24.508165 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:24.509962 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:24.515659 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:25.206838 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 141, id 35085) 20:51:25.209368 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:25.210825 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:25.216859 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:25.217452 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.219111 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:25.223410 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:25.226015 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:25.228051 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.229669 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.231297 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.233163 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.234766 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.236469 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.238275 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.240007 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.241855 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.243509 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.245192 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.246993 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.248664 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.250270 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.251978 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.254028 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.256621 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:25.257280 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:25.259069 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:25.260615 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:25.262371 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:25.266977 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:25.936823 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 139, id 35085) 20:51:25.943762 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:25.945401 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.947375 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.950200 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:25.952969 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:25.954764 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.956860 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:25.958886 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.960543 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.962132 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.963854 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.965552 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.967362 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:25.968988 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.971085 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.972941 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.974592 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.976310 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:25.978087 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.979773 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.985694 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.986267 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.988091 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.989725 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:25.991478 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:25.993169 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:25.995117 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:25.996734 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:25.999048 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:26.000477 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:26.002184 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:26.005762 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:26.682127 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 137, id 35085) 20:51:26.684829 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:26.686523 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:26.688554 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:26.690161 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:26.691795 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:26.693697 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:26.695390 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:26.698038 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:26.699724 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:26.702473 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:26.704393 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:26.707053 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:26.711626 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.712214 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:26.715899 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:26.719683 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.721555 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.723188 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.724867 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.726754 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.728626 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.731761 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.733930 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.734937 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.736712 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:26.738445 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.740310 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.742039 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.743787 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:26.745465 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:26.747693 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:26.752686 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:26.752941 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:26.754559 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:26.756268 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:27.430390 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 135, id 35085) 20:51:27.431651 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:27.433420 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:27.435021 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:27.438523 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:27.440161 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:27.441652 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:27.444556 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:27.449191 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:27.450468 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:27.452538 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:27.454787 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:27.456419 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:27.458721 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:27.460753 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.462535 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:27.464585 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.466651 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.468566 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.473580 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.475308 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.477416 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.479318 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.481557 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:27.483722 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.485592 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.487531 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:27.489319 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.491211 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.492793 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.494504 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:27.496176 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.498141 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:27.499845 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:27.501745 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:27.503345 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:27.505086 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:27.506586 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:27.508945 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:27.510057 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:27.511794 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:27.513355 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:28.177822 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 133, id 35085) 20:51:28.178595 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:28.180846 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:28.182737 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:28.184385 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.186166 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.187922 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.189462 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.191267 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.193025 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.194657 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:28.196361 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.198262 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:28.199836 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.201591 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.203353 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.205080 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:28.208825 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.210649 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.212401 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.214050 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.216030 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.217860 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.219393 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.221080 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.222800 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.228105 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.228498 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.230172 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.231802 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.233478 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.235137 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.236733 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.249823 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.249889 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.250203 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.250451 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.251708 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.253385 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.255108 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:28.258818 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:28.260541 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:28.262384 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:28.263990 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:28.265659 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:28.270366 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:28.927803 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 131, id 35085) 20:51:28.943686 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.943833 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.944092 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.944343 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.945511 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.947273 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:28.948831 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:28.958556 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.958622 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:28.958710 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.966239 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.966306 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.966719 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.966967 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:28.968640 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:28.970422 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:28.972004 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.973720 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:28.978728 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.981032 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.990955 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:28.991041 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:28.991114 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:28.994548 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:28.994813 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:28.999582 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.000509 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:29.002326 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.003844 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.005533 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.007363 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.009078 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.012500 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.014197 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.016326 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.018092 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:29.019572 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:29.021338 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:29.022983 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:29.024677 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:29.029655 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:29.029902 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:29.665708 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 129, id 35085) 20:51:29.669911 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:29.673936 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:29.675515 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:29.677569 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:29.678980 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:29.680822 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:29.682565 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:29.684287 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:29.685958 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:29.687934 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:29.689407 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.691107 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.692744 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.694467 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.696140 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:29.697948 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:29.702915 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.703196 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.704953 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.706540 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.708526 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:29.710027 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.711742 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:29.713725 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.715123 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.716867 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:29.718606 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:29.720781 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.722060 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.723776 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.725685 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:29.727483 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.729074 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.730682 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:29.732544 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:29.734169 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:29.743720 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:29.743870 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:29.744120 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:29.744368 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:29.745529 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:29.747260 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:29.749120 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:29.750644 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:29.752255 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:29.753849 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:29.755490 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:29.757314 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:30.391168 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 127, id 35085) 20:51:30.391259 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:30.391494 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:30.391741 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 123, id 35085) 20:51:30.393059 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 125, id 35085) 20:51:30.396505 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:30.401330 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:30.401929 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.403974 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.405495 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.407520 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.409056 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.410810 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:30.412505 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:30.414241 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:30.416071 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:30.420835 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:30.423444 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:30.425140 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.426883 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:30.428782 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.430463 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.432166 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.434020 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.435648 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.437806 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.439162 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:30.441049 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.442656 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.444307 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.445995 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.448403 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:30.449670 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.451367 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.453089 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:30.454904 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.456702 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.458412 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:30.460098 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.462278 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:30.463587 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:30.465336 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:30.467040 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:30.468760 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:30.470278 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:30.471871 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:30.473498 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:30.478657 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:30.478913 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:30.480326 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:31.108324 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:31.108740 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 121, id 35085) 20:51:31.110667 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.112222 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.114246 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.115616 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.117562 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.119140 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.120959 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.122638 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.124351 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.126082 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:31.128237 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.129759 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.131376 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:31.133028 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.134667 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:31.136478 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.138264 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.140059 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.141753 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.143491 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.145290 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.147315 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.148735 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.153572 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.154061 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.155860 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.157863 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.159348 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.161068 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.162968 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.164553 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.166257 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.168271 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.169972 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.171689 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.173611 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.175338 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.177092 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.178712 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.180442 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.182215 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.183979 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.188855 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.189308 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.191035 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.194356 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.195920 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.199581 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.201342 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.203296 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.205056 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.206786 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.208528 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.210211 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.211918 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.213555 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.215253 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.216944 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.218639 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.221527 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.223103 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:31.224672 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.226466 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:31.228189 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:31.229771 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:31.231454 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:31.854719 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 119, id 35085) 20:51:31.858021 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.859909 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 117, id 35085) 20:51:31.861676 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.863668 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.864908 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.866681 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.871617 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.872313 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.874440 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.876079 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.877924 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.879569 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:31.881354 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.883062 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.884782 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.886773 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.888538 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:31.890143 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.891870 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.895004 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.896739 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.898448 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.900350 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.901970 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.903668 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.908578 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.909044 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.911086 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.914603 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.916516 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.918106 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.919702 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.921494 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.923213 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.925095 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.926703 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.928490 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.930124 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.931904 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.933695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.935387 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:31.937333 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.938864 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.940610 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.942306 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.944021 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.945697 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.947747 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:31.949147 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:31.950772 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:31.952329 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.954015 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:31.955570 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:31.957421 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:32.610516 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:32.611992 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 115, id 35085) 20:51:32.619039 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.621816 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 113, id 35085) 20:51:32.623716 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.625469 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.627109 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.628830 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.630566 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.632381 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.634117 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.636002 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:32.637777 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.639371 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.641201 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.643036 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.644642 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.646370 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.648212 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.649902 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.651744 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.653422 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.655134 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.657118 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.659106 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.660754 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.662660 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.664290 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.666145 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.668051 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.669889 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.671577 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.676464 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.677455 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.679113 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.680834 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.682471 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.684276 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.686005 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.688093 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:32.689540 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:32.691245 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:32.692888 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.694775 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.696288 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:32.698091 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.699726 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.701424 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.703015 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:32.704600 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 109, id 35085) 20:51:32.706222 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:32.707975 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:32.709713 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:33.351931 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:33.353258 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:33.356327 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 111, id 35085) 20:51:33.359765 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.361644 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.363339 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.366780 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.370291 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.371890 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.373581 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.375343 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.376966 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.378819 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.380489 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.382232 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.383895 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.385594 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.387459 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.389018 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.390915 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:33.392540 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.394282 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.396082 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.397934 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.399632 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.401285 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.402999 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.404660 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.406315 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.408403 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.409979 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.411622 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.413565 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.415293 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:33.417004 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.418787 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.420441 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.422109 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.425850 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:33.427872 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.429507 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:33.431209 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.432954 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:33.434643 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.436338 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.438185 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:33.440344 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.441257 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.443084 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.444812 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:33.446788 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:33.448343 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:33.450032 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:33.451682 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:33.453227 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:34.091724 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:34.093336 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:34.098174 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.098718 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 107, id 35085) 20:51:34.100638 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.105460 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.107146 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.111124 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.113484 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.115222 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.117401 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.118832 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.120673 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.122185 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.124011 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.125687 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.127906 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.129299 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.131057 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.132685 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.134586 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.136188 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.137982 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.139656 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.143436 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.145207 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.146901 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.151754 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.152245 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.154137 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.155865 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.157947 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.159263 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.161088 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.162856 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.164819 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.166477 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.168427 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.170100 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.171724 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.173426 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.175422 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.177170 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.179070 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.180695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.182416 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.184108 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.185763 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.187493 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 105, id 35085) 20:51:34.190353 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.191947 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.193514 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.195156 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.196951 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.198596 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:34.844913 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 103, id 35085) 20:51:34.850197 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.851913 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.853593 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.856622 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.860438 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.862337 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.864018 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.865644 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.867682 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.869093 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.870766 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.872511 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.874484 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.876018 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.877903 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.879408 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.881039 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.882848 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.884602 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.886641 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.891201 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.892208 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:34.893943 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:34.897147 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.898753 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.900702 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.902285 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.904019 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:34.905724 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.907710 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.909357 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.911077 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:34.912692 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.914577 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:34.918012 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 101, id 35085) 20:51:34.919969 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.921280 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.923021 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.924785 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:34.926529 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:34.928132 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:34.929800 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:35.592615 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.594278 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.596119 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.597881 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.599471 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.601143 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.605997 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.606570 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.608538 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.610232 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:35.611868 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.613645 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.615390 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.617458 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.619198 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.620761 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.622500 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.624401 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.626079 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.627918 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.629506 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.631489 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.633037 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.634739 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.636506 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:35.638343 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:35.640226 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:35.641852 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.643732 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.645579 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.647370 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.648960 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:35.650863 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.652516 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.654188 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.656208 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:35.660868 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.661155 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.663536 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.664495 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 99, id 35085) 20:51:35.666316 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 97, id 35085) 20:51:35.667928 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:35.669562 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:35.671536 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:35.673208 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:36.327112 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:36.328426 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.338435 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.338603 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.338860 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.339112 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.340262 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.342130 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.343788 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.345421 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.355853 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.356645 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.358654 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.360400 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.362225 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.363999 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.365803 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.375578 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.375805 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.376061 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.376307 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.377379 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.379090 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.380880 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.382620 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:36.389357 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:36.391089 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:36.392117 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.393913 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.395792 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.397732 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.401434 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.403312 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.404938 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.406856 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.408390 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.410004 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.411580 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.413229 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.414900 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 95, id 35085) 20:51:36.420072 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.422210 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:36.424015 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.425788 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:36.427625 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:36.429135 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:36.431029 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:37.056475 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:37.058931 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.061814 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.063406 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.064889 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.066749 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.068607 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.070324 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.072120 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.073866 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.075788 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:37.077492 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.080973 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:37.082731 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.084519 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.086099 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.091061 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.091510 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.093300 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.095027 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.096724 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.098460 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.100097 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.101856 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:37.105751 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.107738 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:37.109210 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:37.110935 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.112859 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.114485 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.116144 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.118379 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.119345 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.121354 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:37.122926 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.124695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:37.126530 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.128364 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.129913 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.131643 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 93, id 35085) 20:51:37.133411 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 91, id 35085) 20:51:37.135329 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.136908 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.138546 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.140220 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.141854 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.813084 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.816177 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.820623 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.824316 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.826231 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:37.830116 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:37.832187 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.834286 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.836386 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.839031 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.840763 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.842568 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.844697 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.846556 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.848351 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.850268 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.852121 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.853744 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.855535 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.857522 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.859340 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:37.860921 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:37.862782 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:37.864235 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.866168 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:37.867958 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.869632 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.879680 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:37.879847 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.880100 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.880348 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.881066 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.886145 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.886373 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.889696 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 89, id 35085) 20:51:37.891238 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.892870 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.894532 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:37.896206 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.897928 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:37.899521 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.901169 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.902656 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:37.904336 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.537886 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:38.538138 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.540228 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:38.546596 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:38.548516 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.550248 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.551925 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.553836 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:38.555522 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.557287 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:38.558926 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:38.561130 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.562441 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:38.564166 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.565855 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:38.567776 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.572382 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.572907 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:38.574825 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.576545 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.578459 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.580089 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.581836 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.583512 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:38.585401 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:38.587086 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.588783 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:38.590611 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.592242 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:38.593947 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 87, id 35085) 20:51:38.595801 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.597604 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.599174 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 85, id 35085) 20:51:38.600743 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.602380 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.604127 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:38.605727 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.607377 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:38.608963 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:38.610516 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.262458 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:39.264218 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.265967 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.276011 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:39.276101 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.276800 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.280616 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:39.282456 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.283992 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:39.285723 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.287915 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.289269 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.291058 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.293000 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:39.302323 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:39.302404 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:39.303793 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:39.304926 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:39.306726 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.308234 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.310045 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.311748 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:39.313741 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.315083 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:39.324918 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.324999 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:39.325337 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:39.325585 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.326552 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:39.336148 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.336238 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 83, id 35085) 20:51:39.336549 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.336796 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.337989 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.341281 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:39.342875 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.344608 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.346181 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.348231 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:39.357471 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.357532 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.358033 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:39.358106 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:39.359209 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.015426 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:40.016774 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.018888 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.020778 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.022343 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.024054 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:40.025943 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.027764 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.029318 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.031047 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.032726 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.034432 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.038195 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.039666 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.041607 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.044562 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.046293 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:40.048163 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.049668 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.051373 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.053091 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.054933 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.056530 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.058295 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.059876 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.061817 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:40.065401 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.067198 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.068901 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.070565 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 81, id 35085) 20:51:40.072249 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.074253 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.075874 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.077987 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.079714 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.081453 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.083252 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.085153 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.086748 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.089800 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.091385 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.092877 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.094501 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.096261 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.098061 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.099672 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.755992 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.758310 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.759999 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.763421 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.765326 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.766971 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.768739 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.770419 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.772141 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.773788 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.775449 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.777536 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.787164 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:40.787256 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.787561 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.787810 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:40.789167 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:40.790709 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.799062 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.799805 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.801492 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.803295 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:40.805044 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.806695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.808465 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 79, id 35085) 20:51:40.810187 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.811928 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.813597 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.815457 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.817156 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.818804 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:40.820613 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.822246 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.824141 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:40.825712 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:40.827928 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.829140 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.830877 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.832588 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.835969 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:40.837762 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.839255 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:40.840887 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.510387 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:41.511858 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:41.513945 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:41.515164 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.517148 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:41.518962 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.523810 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.524077 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.525700 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.527923 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:41.529182 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:41.530982 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:41.532836 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.534525 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.536180 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:41.537986 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.539714 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:41.541390 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:41.543207 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:41.544987 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.546680 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.548405 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.550155 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:41.551869 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:41.553464 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:41.555150 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:41.556855 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 77, id 35085) 20:51:41.561695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.562171 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:41.563803 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.565785 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.567824 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:41.569360 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.571192 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:41.572961 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.574626 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.576237 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:41.578019 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:41.581738 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.583575 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.585318 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.587135 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.588838 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:41.592179 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.593799 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:41.595710 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:41.597563 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.255948 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:42.257791 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.259428 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.263201 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.264813 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.266497 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.268342 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.269995 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.271749 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.273787 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.275238 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:42.280038 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:42.280510 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.282500 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:42.283959 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:42.285943 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:42.288047 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:42.289402 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:42.291190 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:42.292852 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.294737 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.296357 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.300096 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.301921 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:42.303694 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.305410 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:42.307186 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 75, id 35085) 20:51:42.309395 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:42.310647 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:42.312451 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 73, id 35085) 20:51:42.314841 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.315890 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.318033 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.319549 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.321117 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.324848 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:42.326390 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.328647 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.333279 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.333735 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.335732 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:42.337631 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.339029 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.340816 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:42.342621 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.344668 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.346074 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:42.347813 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.003690 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:43.004958 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.016545 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:43.016638 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.016716 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.017008 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.018202 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.019812 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.021296 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.025199 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.027207 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.029278 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.030683 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.033055 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.034667 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.045488 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.047264 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.048955 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.050640 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.055500 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.056107 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:43.061051 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.061705 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:43.063560 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.064869 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 71, id 35085) 20:51:43.066521 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:43.069555 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:43.074611 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.074875 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.079579 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.080290 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.082224 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.084123 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.085678 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.087877 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.089242 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.091066 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.092930 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.094533 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.096040 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.098018 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.099408 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.101155 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.752695 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.760433 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.764409 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.766667 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.768585 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.770404 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.771961 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.776796 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.779125 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.781138 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.782834 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.791663 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.793299 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.795435 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.797739 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 69, id 35085) 20:51:43.800798 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.805802 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.806069 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.808432 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 67, id 35085) 20:51:43.809557 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.811341 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.812936 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.814622 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.816315 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.820057 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.821762 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:43.823389 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.825013 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.826757 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.828663 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:43.830344 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:43.835834 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.509531 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:44.511123 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.513175 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.520079 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.526270 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:44.528197 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.537067 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.546092 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:44.547669 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.550437 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 65, id 35085) 20:51:44.554170 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 63, id 35085) 20:51:44.555993 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.562348 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:44.566471 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:45.252298 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:45.274022 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) 20:51:45.292793 medusa.aps.anl.gov > 224.2.253.119: udp 33 (ttl 61, id 35085) From list-mgr@ISI.EDU Thu Feb 16 22:43:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 00:44:51 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 00:43:47 -0800 Received: from relay1.UU.NET by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 00:43:44 -0800 Received: from alterdial.UU.NET by relay1.UU.NET with SMTP id QQydli09690; Fri, 17 Feb 1995 03:43:41 -0500 Received: from [198.4.181.158] by alterdial.UU.NET with SMTP id QQydli24517; Fri, 17 Feb 1995 03:43:36 -0500 X-Sender: mail00821@alterdial.uu.net (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Feb 1995 03:43:16 -0500 To: mbone From: adamgood@voices.com (Adam Goodman) Subject: Multicast applications on Solaris 2.x for x86 Cc: rem-conf@es.net Hello All, I was wondering if it is possible to recompile source code for all the multicast applications under Solaris 2.x for x86 machines. Does the x86 Solaris even come with multicast support in the kernel? If not, can it be recompiled to include multicast support? Can mrouted be recompiled to work on a machine like this? Is this feasible at all? Does anyone have any experience with this? If none of this is possible, is there any effort underway (by either SunSoft or anyone else) to enable multicast on Solaris for x86? Any help with this will be greatly appreciated. TIA, -Adam Adam M. Goodman Mulsanne Communications 19 W. 44th St. Ste. 1217 New York, NY 10036 ph# (212) 221-7065 fx# (212) 221-1413 From list-mgr@ISI.EDU Fri Feb 17 14:11:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 02:15:09 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 02:13:50 -0800 Received: from lohi.dat.tele.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 02:13:46 -0800 Message-Id: <199502171013.AA27251@venera.isi.edu> Received: from lohi.dat.tele.fi by lohi.dat.tele.fi id <11042-0@lohi.dat.tele.fi>; Fri, 17 Feb 1995 12:11:18 +0200 To: adamgood@voices.com Cc: mbone, rem-conf@es.net In-Reply-To: (adamgood@voices.com) Subject: Re: Multicast applications on Solaris 2.x for x86 Date: Fri, 17 Feb 1995 12:11:18 +0200 From: Juha Heinanen Sender: Juha.Heinanen@lohi.dat.tele.fi it is hard to compile the multicast applications for anything unless you have the sources and those are not available except for nv. it would be nice if the sources of the multicast applications were either publicly available or if there was a company that would be selling binaries on a commercial basis. neither of these two is now true, which i consider a very bad thing. -- juha From list-mgr@ISI.EDU Fri Feb 17 11:15:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 03:18:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 03:17:34 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 03:17:31 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 17 Feb 1995 03:17:26 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 17 Feb 1995 11:15:09 +0000 To: Juha Heinanen Cc: adamgood@voices.com, mbone, rem-conf@es.net Subject: Re: Multicast applications on Solaris 2.x for x86 In-Reply-To: Your message of "Fri, 17 Feb 95 12:11:18 +0200." <199502171013.AA27251@venera.isi.edu> Date: Fri, 17 Feb 95 11:15:05 +0000 Message-Id: <1329.793019705@cs.ucl.ac.uk> From: Jon Crowcroft >it is hard to compile the multicast applications for anything unless you >have the sources and those are not available except for nv. and vic and ivs and a few other things.... jon From list-mgr@ISI.EDU Fri Feb 17 13:26:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 03:27:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 03:26:52 -0800 Received: from concorde.inria.fr by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 03:26:49 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.9/8.6.9) with ESMTP id MAA25154; Fri, 17 Feb 1995 12:26:28 +0100 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.8/8.6.6) with ESMTP id MAA00706; Fri, 17 Feb 1995 12:26:27 +0100 Message-Id: <199502171126.MAA00706@givry.inria.fr> From: Francis Dupont To: Juha Heinanen Cc: adamgood@voices.com, mbone, rem-conf@es.net Subject: Re: Multicast applications on Solaris 2.x for x86 In-Reply-To: Your message of Fri, 17 Feb 1995 12:11:18 +0200. <199502171013.AA27251@venera.isi.edu> Date: Fri, 17 Feb 1995 12:26:20 +0100 Sender: Francis.Dupont@inria.fr In your previous mail you wrote: it is hard to compile the multicast applications for anything unless you have the sources and those are not available except for nv. it would be nice if the sources of the multicast applications were either publicly available or if there was a company that would be selling binaries on a commercial basis. neither of these two is now true, which i consider a very bad thing. => I fully agree with you! We should stop to use multicast tools without available sources or industry-level support or worse to consider them as standards... Francis.Dupont@inria.fr PS: IVS (INRIA Videoconferencing System) and Nevot sources are available too. From list-mgr@ISI.EDU Fri Feb 17 15:00:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 05:01:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 05:01:03 -0800 Received: from mitsou.inria.fr by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 05:01:01 -0800 Received: by mitsou.inria.fr (8.6.9/8.6.9) id OAA19512; Fri, 17 Feb 1995 14:00:38 +0100 Message-Id: <199502171300.OAA19512@mitsou.inria.fr> To: Juha Heinanen Cc: adamgood@voices.com, mbone, rem-conf@es.net Subject: Re: Multicast applications on Solaris 2.x for x86 In-Reply-To: Your message of "Fri, 17 Feb 1995 12:11:18 +0200." <199502171238.NAA16848@sophia.inria.fr> Date: Fri, 17 Feb 1995 14:00:37 +0100 From: Christian Huitema Juha, The sources of ivs are available on: ftp://zenon.inria.fr/rodeo/ivs/* Christian Huitema From list-mgr@ISI.EDU Fri Feb 17 15:03:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 05:08:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 05:07:46 -0800 Received: from faui45.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 05:07:12 -0800 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA16112 (5.65c-6/7.3w-FAU); Fri, 17 Feb 1995 14:03:36 +0100 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA07597 (5.65c-6/7.3m-FAU); Fri, 17 Feb 1995 14:03:33 +0100 From: Toerless Eckert Message-Id: <199502171303.AA07597@faui43.informatik.uni-erlangen.de> Subject: Re: Multicast applications on Solaris 2.x for x86 To: Francis.Dupont@inria.fr (Francis Dupont) Date: Fri, 17 Feb 1995 14:03:23 +0100 (MET) Cc: Juha.Heinanen@lohi.dat.tele.fi, adamgood@voices.com, mbone, rem-conf@es.net In-Reply-To: <199502171126.MAA00706@givry.inria.fr> from "Francis Dupont" at Feb 17, 95 12:26:20 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > PS: IVS (INRIA Videoconferencing System) and Nevot sources > are available too. PPS: vic sources are available too. All we need is vat... From list-mgr@ISI.EDU Fri Feb 17 17:57:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 06:00:50 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 05:59:50 -0800 Received: from lohi.dat.tele.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 05:59:46 -0800 Message-Id: <199502171359.AA02132@venera.isi.edu> Received: from lohi.dat.tele.fi by lohi.dat.tele.fi id <13727-0@lohi.dat.tele.fi>; Fri, 17 Feb 1995 15:57:33 +0200 To: Toerless.Eckert@Informatik.Uni-Erlangen.de Cc: Francis.Dupont@inria.fr, adamgood@voices.com, mbone, rem-conf@es.net In-Reply-To: <199502171303.AA07597@faui43.informatik.uni-erlangen.de> (Toerless.Eckert@Informatik.Uni-Erlangen.de) Subject: Re: Multicast applications on Solaris 2.x for x86 Date: Fri, 17 Feb 1995 15:57:33 +0200 From: Juha Heinanen Sender: Juha.Heinanen@lohi.dat.tele.fi PPS: vic sources are available too. All we need is vat... where did you get sd and mrouted sources? -- juha From list-mgr@ISI.EDU Fri Feb 17 04:15:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 06:21:55 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 06:21:18 -0800 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 06:21:17 -0800 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA18488; Fri, 17 Feb 1995 09:15:31 +0500 Message-Id: <9502171415.AA18488@msf.psi.net.> To: Van Jacobson Cc: mbone Subject: Re: serious multicast routing loop at ANL.GOV In-Reply-To: Your message of "Thu, 16 Feb 1995 21:31:03 PST." <9502170531.AA16395@rx7.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <18486.793030530.1@msf.psi.net> Date: Fri, 17 Feb 1995 09:15:30 -0500 From: "Mark S. Fedor" Content-Length: 762 Is there any config guideline for what causes Cisco PIM to misbehave like this on the MBONE? I know there have been many requests for something like this, but no good replies. I am fooling with PIM internally, totally disconnected from the MBONE. I feel like I am ready to plod onward and try some mbone interaction. However, I fear the worst. I have read everything I can find on PIM and the cisco implementation, but haven't found any real words of wisdom for proper mbone interaction. It looks straight forward from what I've read. Why does PIM screw up the mbone so much. Am I missing something? Any pointers to reading and/or experiences would be appreciated. Maybe some cisco "standard config" for PIM-mbone interaction would help? Thanks, Mark From list-mgr@ISI.EDU Thu Feb 16 23:44:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 07:55:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 07:54:35 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 07:54:34 -0800 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14430(2)>; Fri, 17 Feb 1995 07:44:28 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Fri, 17 Feb 1995 07:44:07 -0800 To: Juha Heinanen Cc: Toerless.Eckert@informatik.uni-erlangen.de, Francis.Dupont@inria.fr, adamgood@voices.com, mbone, rem-conf@es.net Cc: deering@parc.xerox.com Subject: Re: Multicast applications on Solaris 2.x for x86 In-Reply-To: Juha.Heinanen's message of Fri, 17 Feb 95 05:57:33 -0800. <199502171359.AA02132@venera.isi.edu> Date: Fri, 17 Feb 1995 07:44:03 PST Sender: Steve Deering From: Steve Deering Message-Id: <95Feb17.074407pst.12174@skylark.parc.xerox.com> > where did you get sd and mrouted sources? > > -- juha mrouted sources have been publically available since 1989. The current version is available from ftp://parcftp.xerox.com/pub/net-research/. Steve From list-mgr@ISI.EDU Fri Feb 17 00:15:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 08:16:26 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 08:16:09 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 08:16:08 -0800 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14416(1)>; Fri, 17 Feb 1995 08:16:01 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Fri, 17 Feb 1995 08:15:54 -0800 To: "Mark S. Fedor" Cc: mbone Subject: Re: serious multicast routing loop at ANL.GOV In-Reply-To: fedor's message of Fri, 17 Feb 95 06:15:30 -0800. <95Feb17.065757pst.386@palain.parc.xerox.com> Date: Fri, 17 Feb 1995 08:15:40 PST Sender: Steve Deering From: Steve Deering Message-Id: <95Feb17.081554pst.12174@skylark.parc.xerox.com> > Why does PIM screw up the mbone so much? Because PIM thinks the topology represented in its unicast routing table is the same as the multicast topology, which is not true as long as there are tunnels in the MBone and non-multicast routers in the Internet. > Maybe some cisco "standard config" for PIM-mbone interaction would help? That's a very good idea. I believe Dino has come up with his own "rules of thumb" for what PIM topologies are MBone-safe, which he might be convinced to publish. When we get hierarchical multicast routing deployed later this year (I hope!), we'll have a real architecture for isolating one multicast routing protocol from another, rather than relying on rules of thumb and coincidences of topology. Steve From list-mgr@ISI.EDU Fri Feb 17 06:47:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 08:39:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 08:39:22 -0800 Received: from NS.METROLINK.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 08:39:19 -0800 Received: from anubis.metrolink.com. (anubis.metrolink.com) by ns.metrolink.com with SMTP id AA27245 (5.67b/IDA-1.5 for ); Fri, 17 Feb 1995 11:45:21 GMT Received: by anubis.metrolink.com. (4.1/SMI-4.1) id AA04739; Fri, 17 Feb 95 11:47:07 EST Date: Fri, 17 Feb 95 11:47:07 EST From: pax@anubis.metrolink.com (Garry M. Paxinos) Message-Id: <9502171647.AA04739@anubis.metrolink.com.> To: mbone Cc: rem-conf@es.net Subject: Re: Multicast applications on Solaris 2.x for x86 X-Mailer: XALT Mail [Version 1.2.d] X-Stamp-Id: 7 > > PS: IVS (INRIA Videoconferencing System) and Nevot sources > > are available too. > > PPS: vic sources are available too. All we need is vat... Does anyone have the source to Nevot tar'd up with all the other required packages? Thanks, Pax. ---- Metro Link Incorporated. 4711 N. Powerline Rd. Fort Lauderdale Fl, 33309 Voice: +1.305.938.0283x414 Fax: +1.305.938.1982 Email: pax@metrolink.com URL: http://www.flsig.org/people/garryp "The real voyage of discovery consists not in seeking new landscapes but in having new eyes." -Proust From list-mgr@ISI.EDU Fri Feb 17 00:43:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 08:41:21 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 08:41:08 -0800 Received: from ece.nps.navy.mil by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 08:41:07 -0800 Received: from sun13.ece.nps.navy.mil by ece.nps.navy.mil (4.1/SMI-4.1) id AA19715; Fri, 17 Feb 95 08:43:09 PST Date: Fri, 17 Feb 95 08:43:09 PST From: barton@ece.nps.navy.mil (Robert Barton 03-96) Message-Id: <9502171643.AA19715@ece.nps.navy.mil> To: mbone Subject: Multicast RTP monitoring Cc: voigt@ece.nps.navy.mil, shukla@ece.nps.navy.mil On april 15 Naval Postgraduate School is going to demonstrate a multi-user interactive session of NPSNET(3D virtual wargaming scenario) on mbone. The conference site itself is connected via a wireless bridge back to NPS from the Monterey Hyatt. We are interested in monitoring and analyzing RTP performance during the session. Remote sites include NRL, AFID, Australia, and several others. Of specific interest is the following: 1. Toplogy - ability to view/store the trees created/updated at various points during the session. 2. Delay - end-to-end delay between sites. 3. QoS - Packet loss, playback point, etc.. Any suggestions on what/where current tools are greatly appreciated. Also, any ideas on specific data to collect would be helpful. Bob B. Lt Robert J barton Naval Postgraduate School Dept. of ECE barton@ece.nps.navy.mil From list-mgr@ISI.EDU Sat Feb 18 00:22:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 12:24:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 12:22:35 -0800 Received: from lohi.dat.tele.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 12:22:31 -0800 Message-Id: <199502172022.AA16897@venera.isi.edu> Received: from lohi.dat.tele.fi by lohi.dat.tele.fi id <02425-0@lohi.dat.tele.fi>; Fri, 17 Feb 1995 22:22:22 +0200 To: mbone Subject: gated with multicast support for linux Date: Fri, 17 Feb 1995 22:22:22 +0200 From: Juha Heinanen Sender: Juha.Heinanen@lohi.dat.tele.fi looks like gated with multicast support has been made available for linux. -- juha -------------------- Title =Gate Daemon (gated) Version =3.5A9 Desc1 =Gated for Linux. Desc2 =Ported from code developed by Cornell University. Desc3 =Beta code as at date of posting. Desc4 = Desc5 = Author =Cornell University AuthorEmail =gated- people@gated.cornell.edu Maintainer =Stephen Davies MaintEmail =scldad@sdc.com.au.au Site1 =sunsite.unc.edu Path1 =/pub/Linux/ File1 =gated_3_5A9_bin.linux.tgz FileSize1 =515K Site2 = Path2 = File2 = FileSize2 = Site3 = Path3 = File3 = FileSize3 = Site4 = Path4 = File4 = FileSize4 = Required1 =Linux kernel which supports multicasting Required2 =Documentation from gated.cornel.edu. Required3 = Required4 = CopyPolicy1 =Copyright Cornell but open. CopyPolicy2 = Keywords =gated routed route daemon Comment1 =Source is available direct from gated.cornell.edu. Comment2 =This binary package is for people who do not want to Comment3 =compile for themselves (or cannot). All routing protocols Comment4 =are included. Comment5 =NOTE. This version _REQUIRES_ kernel multicast support. RelFiles1 = RelFiles2 = RelFiles3 = Entered =13Feb1995 EnteredBy =Stephen Davies CheckedEmail =scldad@sdc.com.au From list-mgr@ISI.EDU Fri Feb 17 05:12:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 13:13:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 13:13:00 -0800 Received: from power.net (touchstone.power.net) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 13:12:57 -0800 Received: by power.net (Smail3.1.29.1 #3) id m0rfZyy-0005N7C; Fri, 17 Feb 95 13:12 PST Date: Fri, 17 Feb 1995 13:12:56 -0800 (PST) From: Elias Levy To: Juha Heinanen Cc: mbone Subject: Re: gated with multicast support for linux In-Reply-To: <199502172022.AA16897@venera.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes! On Fri, 17 Feb 1995, Juha Heinanen wrote: > looks like gated with multicast support has been made available for > linux. > > -- juha > -------------------- > Title =Gate Daemon (gated) > Version =3.5A9 > Desc1 =Gated for Linux. > Desc2 =Ported from code developed by Cornell University. > Desc3 =Beta code as at date of posting. > Desc4 = > Desc5 = > Author =Cornell University > AuthorEmail =gated- > people@gated.cornell.edu > Maintainer =Stephen Davies > MaintEmail =scldad@sdc.com.au.au > Site1 =sunsite.unc.edu > Path1 =/pub/Linux/ > File1 =gated_3_5A9_bin.linux.tgz > FileSize1 =515K > Site2 = > Path2 = > File2 = > FileSize2 = > Site3 = > Path3 = > File3 = > FileSize3 = > Site4 = > Path4 = > File4 = > FileSize4 = > Required1 =Linux kernel which supports multicasting > Required2 =Documentation from gated.cornel.edu. > Required3 = > Required4 = > CopyPolicy1 =Copyright Cornell but open. > CopyPolicy2 = > Keywords =gated routed route daemon > Comment1 =Source is available direct from gated.cornell.edu. > Comment2 =This binary package is for people who do not want to > Comment3 =compile for themselves (or cannot). All routing protocols > Comment4 =are included. > Comment5 =NOTE. This version _REQUIRES_ kernel multicast support. > RelFiles1 = > RelFiles2 = > RelFiles3 = > Entered =13Feb1995 > EnteredBy =Stephen Davies > CheckedEmail =scldad@sdc.com.au > elias@power.net (Elias Levy) PowerNet, Inc. From list-mgr@ISI.EDU Fri Feb 17 11:56:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 13:57:00 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 13:56:43 -0800 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 13:56:41 -0800 Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id QAA15879; Fri, 17 Feb 1995 16:56:12 -0500 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Feb 1995 16:56:24 -0500 To: Juha Heinanen From: Scott Brim Subject: Re: gated with multicast support for linux Cc: mbone At 22:22 02/17/95, Juha Heinanen wrote: >looks like gated with multicast support has been made available for >linux. He's not supposed to distribute it without a license. I'll have to talk to him. From list-mgr@ISI.EDU Fri Feb 17 11:59:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 14:00:56 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 14:00:40 -0800 Received: from MITCHELL.CIT.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 14:00:38 -0800 Received: from mitchell.cit.cornell.edu (MITCHELL.CIT.CORNELL.EDU [132.236.200.25]) by mitchell.cit.cornell.edu (8.6.9/8.6.9) with ESMTP id QAA05330; Fri, 17 Feb 1995 16:59:59 -0500 Message-Id: <199502172159.QAA05330@mitchell.cit.cornell.edu> To: Juha Heinanen Cc: mbone Subject: Re: gated with multicast support for linux In-Reply-To: Message from Juha Heinanen on Fri, 17 Feb 1995 22:22:22 +0200.<199502172022.AA16897@venera.isi.edu> Organization: Information Technologies/Network Resources; Cornell University, Ithaca, NY X-Mailier: MH-E [version 4.1+] MH [version 6.8.1] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Feb 1995 16:59:58 -0500 From: Jeffrey C Honig > looks like gated with multicast support has been made available for > linux. Gated does not yet support IP multicast forwarding. The multicast references just refer to the use of local-wire IP multicast for Router Discovery, OSPF and RIP. Jeff From list-mgr@ISI.EDU Fri Feb 17 19:07:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 19:09:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 19:07:48 -0800 Received: from mulga.cs.mu.OZ.AU by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Feb 1995 19:07:26 -0800 Received: by mulga.cs.mu.OZ.AU (5.83--+1.3.1+0.50); id AA16636 Sat, 18 Feb 1995 14:07:12 +1100 (from kre) Date: Sat, 18 Feb 1995 14:07:12 +1100 From: Robert Elz Message-Id: <9502180307.16636@mulga.cs.mu.OZ.AU> To: mbone Subject: A couple of multicast/av hardware questions 1) Does anyone happen to have one of Sun's "Quad Ethernet" cards, and multicast support for it. I'm consdering getting one, and would like for it to be able to run multicast (SunOS 4.1.3_U1 or 4.1.4). Its supposed to come with a driver, so can't be using the standard drivers for which we have multicast support. Note that this particular box isn't likely to be involved in mrouting, or the mbone at all, multicast would be used more to enable gated to speak OSPF... BPF support would be real nice to be able to do as well. Does anyone know anything about that board, anyone have driver source? 2) I suppose this is a bit early, but does anyone know if the new SS4 uses the same audio hardware (on its optional audio board) as the SS5, and so will use the driver Sun haven't worked out how to write, or does it use one of the ones that works well, or perhaps something new, yet again? Thanks, kre From list-mgr@ISI.EDU Sun Feb 19 17:06:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 18 Feb 1995 15:08:18 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 18 Feb 1995 15:06:48 -0800 Received: from mingus.slab.ntt.jp by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 18 Feb 1995 15:06:41 -0800 Received: by mingus.slab.ntt.jp (8.6.9/core*slab.mx8+) id IAA06043; Sun, 19 Feb 1995 08:06:01 +0900 Message-Id: <199502182306.IAA06043@mingus.slab.ntt.jp> To: vin@shore.net (Vin McLellan) Cc: firewalls@greatcircle.com, mbone Subject: Re: PROPOSAL: alt.abuse.kevin-mitnick Reply-To: sumisu@slab.ntt.jp In-Reply-To: Your message of "Sat, 18 Feb 1995 05:26:03 EST" References: <3i0k27$7s8@news.primenet.com> <3i14bf$jr1@news.primenet.com> <3i1b97$4md@crl.crl.com> <3i2dtj$9js@news.duke.edu> <3i40m2$8rf@news.primenet.com> <199502182224.AA06491@northshore.ecosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Sun, 19 Feb 1995 08:06:00 +0900 From: Jeff Smith |>How about: alt.abuse.kevin_mitnick? |> |>With such a name, various interpretations can be selectively embraced by |>different groups, agencies, corporations and covens. |> |>Meanwhile, some anon researchers can start posting what has been written |>about K.M., and some solid questions can be framed and answered about what |>he has done. Where, when, why, and to whom. And we can invite CNN, or better yet - Carl Malamud to cover the trial and broadcast it over the mbone. :) ( please remember ":)" means I'm joking - couldn't resist) |> |>I am intrigued at the reports that he recently blasted through Motorola's |>EDP security system (a firewall, I presume.) Anyone hear any details? |>Motorola where? What type of firewall? What type of attack? |> |>Has anyone obtained the court's index of items confiscated from Mitnick's |>apartment? |> |>_vin |> |>-- |>Vin McLellan+The Privacy Guild++Technical Translators' Guild = M |>ULTI-LINGUAL tech writers, hw/sw engineers, Ph.ds: * BICULTURAL TRANSLATORS F |>OR HIRE * (617) 884-5546 From list-mgr@ISI.EDU Sun Feb 19 09:55:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 01:57:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 01:55:46 -0800 Received: from mailsun.aber.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 01:55:44 -0800 Received: from mailhost.aber.ac.uk (actually host saturnbb.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Sun, 19 Feb 1995 09:55:34 +0000 To: Robert Elz , mbone Cc: dap@aber.ac.uk Subject: Another Me-Too Re: A couple of multicast/av hardware questions In-Reply-To: Your message of Sat, 18 Feb 1995 14:07:12 +1100. <9502180307.16636@mulga.cs.mu.OZ.AU> Date: Sun, 19 Feb 1995 09:55:31 +0000 Message-Id: <22325.793187731@mailhost.aber.ac.uk> From: D E PRICE Dear Robert and List, Sorry, this is just another `me-too'.. We have a slightly different requirement in so much as I WOULD like to use a Sun SPARC + quad card to support Mrouted. This would help greatly in allowing me to route multicast off our backbone router and directly into multiple subnets with out loading the machines that route unicast into the subnets. Thus, Any info re the quad cards etc would be greatfully received Dave Price From list-mgr@ISI.EDU Sun Feb 19 06:31:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 08:34:46 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 08:33:15 -0800 Received: from stimpy.sura.net by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 08:33:13 -0800 Received: from localhost.sura.net by stimpy.sura.net (4.1/($Id: sendmail.cf,v 1.17 1991/02/11 14:07:23 jmalcolm Exp $)) id AA04265; Sun, 19 Feb 95 11:31:17 EST Message-Id: <9502191631.AA04265@stimpy.sura.net> To: mbone Subject: unsubcribe Date: Sun, 19 Feb 1995 11:31:16 -0500 From: Jennifer Blake-Hedges jbh@sura.net and/or jbh@sura.net From list-mgr@ISI.EDU Mon Feb 20 01:01:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 15:36:47 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 15:02:05 -0800 Received: from mailgzrz.TU-Berlin.DE by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 15:01:59 -0800 Received: from tubkom.prz.tu-berlin.de by mailgzrz.TU-Berlin.DE with SMTP (PP); Mon, 20 Feb 1995 00:01:16 +0100 Received: from (sunday.prz.tu-berlin.de [130.149.62.93]) by tubkom.prz.tu-berlin.de (8.6.9/8.6.9) with SMTP id AAA24957; Mon, 20 Feb 1995 00:01:10 +0100 From: Thomas Wolfram Message-Id: <199502192301.AAA24957@tubkom.prz.tu-berlin.de> Subject: SBus FDDI cards & multicast drivers To: mbone, mbone-de@informatik.uni-erlangen.de Date: Mon, 20 Feb 1995 00:01:09 +0100 (MET) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1303 Hi, I'm looking for SBus FDDI boards which have multicast capable drivers for SunOS 4.1.3 U1 and work with the kernel changes of the "ipmulti 3.3" package. We want to run the mrouted 3.3 on a machine with FDDI interface. The "ipmulti 3.3" release contains only patches for the Sun "Bantam" FDDI boards. Maybe someone has a list? Especially I would like to know whether there are multicast drivers available for: - CMC 950 boards - Network Peripherals (NP) boards - Crescendo boards - Interphase (iphase) boards The second important question: if we have only a usual binary distribution of SunOS (i.e. no source license) is it possible at all to include support for IP multicast over (non-Bantam) FDDI in the kernel? (That would be the case if there are source files which would need recompliation but we cannot do it because we don't have them in the binary distribution). Thank you in advance, Thomas -- Thomas Wolfram Germany: 0 30 31421171 PRZ TU Berlin abroad: +49 30 31421171 EANTC WWW: http://www.prz.tu-berlin.de:/~wolf _____________________________________________________________________________ _____S__I__C____T__R__A__N__S__I__T____G__L__O__R__I__A____M__U__N__D__I_____ From list-mgr@ISI.EDU Sun Feb 19 08:25:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 16:26:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 16:25:28 -0800 Received: from piccolo.cco.caltech.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 16:25:27 -0800 Received: from ricketts.cco.caltech.edu by piccolo.cco.caltech.edu with ESMTP (8.6.7/DEI:4.41) id QAA27052; Sun, 19 Feb 1995 16:25:25 -0800 Received: by ricketts.cco.caltech.edu (8.6.7/UGCS:4.41) id QAA02393; Sun, 19 Feb 1995 16:25:21 -0800 Date: Sun, 19 Feb 1995 16:25:19 -0800 (PST) From: "Liubomir A. Borissov" To: mbone Subject: local MBone topology (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ---------- Forwarded message ---------- Date: Sun, 19 Feb 1995 16:17:02 -0800 (PST) From: Liubomir A. Borissov To: mbone-na-request@isi.edu Subject: local MBone topology Hello, Caltech High Energy Physics laboratoty is interested in using MBone for IP multicast teleconferencing. Our network provider does not presently support MBone facilities. In the near future, we hope that we will be able to set up such a facility. However, for now we would like to get started as soon as possible, in order to gain experience that will help us set up our own site. I would like to ask you what is the closest point that we could connect to? I would also appreciate any additional information that you may consider helpful. Sincerely, Liubomir Borissov From list-mgr@ISI.EDU Sun Feb 19 17:14:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 19:14:54 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 19:14:15 -0800 Received: from stone.ucs.indiana.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 19:14:14 -0800 Received: by stone.ucs.indiana.edu (4.1/9.7jsm) id AA05242; Sun, 19 Feb 95 22:14:07 EST Date: Sun, 19 Feb 1995 22:14:06 -0500 (EST) From: Cell-Relay Gopher Janitor Subject: Re: Multicast and ATM To: Kannan Thiruvengadam Cc: mbone, rem-conf@es.net In-Reply-To: <95Feb14.163053-0700_mst.13791-1+3@scapa.cs.ualberta.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Is anybody working on issues concering the > use of Multicast on ATM ? Please share the > knowledge. Hi Kannan, Go to your favorite rfc site and pick up draft-armitage-ipatm-ipmc-04.txt for current work on ip multicast over atm. Also, the following will bring up some multicast-oriented papers: gopher://cell-relay.indiana.edu:70/7waissrc%3A/bib/netbib?multicast The above is a search of a bibliography i maintain that can be found at: http://cell-relay.indiana.edu/cell-relay/ regards, allen From list-mgr@ISI.EDU Sun Feb 19 11:39:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 19:39:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 19:39:23 -0800 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Feb 1995 19:39:21 -0800 Posted-Date: Sun 19 Feb 95 19:39:16 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Sun, 19 Feb 95 19:39:17 PST Date: Sun 19 Feb 95 19:39:16 PST From: Stephen Casner Subject: Re: local MBone topology (fwd) To: liubo@cco.caltech.edu, MBONE Message-Id: <793251556.0.CASNER@XFR.ISI.EDU> In-Reply-To: Mail-System-Version: There already is an MBone node at Caltech: charybdis.ipac.caltech.edu You should get a tunnel to that node (or direct multicast connection if there is a common ethernet segment). -- Steve ------- From list-mgr@ISI.EDU Sun Feb 19 23:53:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 01:54:14 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 01:53:43 -0800 Received: from relay1.UU.NET by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 01:53:42 -0800 Received: from alterdial.UU.NET by relay1.UU.NET with SMTP id QQydwp03007; Mon, 20 Feb 1995 04:53:38 -0500 Received: from [198.4.181.158] by alterdial.UU.NET with SMTP id QQydwp23959; Mon, 20 Feb 1995 04:53:33 -0500 X-Sender: mail00821@alterdial.uu.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Feb 1995 04:53:17 -0500 To: mbone From: adamgood@voices.com (Adam Goodman) Cc: rem-comf@es.net Hello All, I wonder if anyone can help with this question. I am in the process of purchasing a new SparcStation that will be used primarily for Mbone applications. I know that development of multicast applications takes place under SunOS 4.1.3. Unfortunately, new SparcStations only ship with Solaris 2.4, which is incompatible with the new multicast apps. So, the question is this; does anyone know of a way of acquiring SunOS 4.1.3 for installation on a new Sparc? Any help here will as always be much appreciated. Thanks, -Adam Adam M. Goodman Mulsanne Communications 19 W. 44th St. Ste. 1217 New York, NY 10036 ph# (212) 221-7065 fx# (212) 221-1413 From list-mgr@ISI.EDU Mon Feb 20 00:07:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 02:08:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 02:08:06 -0800 Received: from relay2.UU.NET by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 02:08:05 -0800 Received: from alterdial.UU.NET by relay2.UU.NET with SMTP id QQydwq03307; Mon, 20 Feb 1995 05:07:48 -0500 Received: from [198.4.181.158] by alterdial.UU.NET with SMTP id QQydwq24069; Mon, 20 Feb 1995 05:07:44 -0500 X-Sender: mail00821@alterdial.uu.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Feb 1995 05:07:28 -0500 To: mbone From: adamgood@voices.com (Adam Goodman) Subject: Finding SunOS 4.1.3 Cc: rem-conf@es.net Whoops! Sorry, everyone. I forgot to put a subject on my last e-mail. In case anyone didn't bother to read it for that reason, I was basically asking if anyone knows where one can aquire SunOS 4.1.3 in order to run the latest version of Mrouted. I am purchasing a new SparcStation which only ships with Solaris 2.4. Sorry again, and thanks for any assistance. -Adam Adam M. Goodman Mulsanne Communications 19 W. 44th St. Ste. 1217 New York, NY 10036 ph# (212) 221-7065 fx# (212) 221-1413 From list-mgr@ISI.EDU Mon Feb 20 12:08:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 02:10:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 02:10:10 -0800 Received: from faui45.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 02:09:41 -0800 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA03752 (5.65c-6/7.3w-FAU); Mon, 20 Feb 1995 11:09:04 +0100 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA10589 (5.65c-6/7.3m-FAU); Mon, 20 Feb 1995 11:09:01 +0100 From: Toerless Eckert Message-Id: <199502201009.AA10589@faui43.informatik.uni-erlangen.de> Subject: Re: SBus FDDI cards & multicast drivers To: wolf@prz.tu-berlin.de (Thomas Wolfram) Date: Mon, 20 Feb 1995 11:08:54 +0100 (MET) Cc: mbone, mbone-de@informatik.uni-erlangen.de In-Reply-To: <199502192301.AAA24957@tubkom.prz.tu-berlin.de> from "Thomas Wolfram" at Feb 20, 95 00:01:09 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I'm looking for SBus FDDI boards which have multicast capable > drivers for SunOS 4.1.3 U1 and work with the kernel changes > of the "ipmulti 3.3" package. We want to run the mrouted 3.3 > on a machine with FDDI interface. > The "ipmulti 3.3" release contains only patches for the > Sun "Bantam" FDDI boards. > > Maybe someone has a list? > Especially I would like to know whether there are multicast > drivers available for: > > - CMC 950 boards > - Network Peripherals (NP) boards > - Crescendo boards > - Interphase (iphase) boards > > The second important question: if we have only a usual binary > distribution of SunOS (i.e. no source license) is it possible > at all to include support for IP multicast over (non-Bantam) > FDDI in the kernel? (That would be the case if there are source > files which would need recompliation but we cannot do it because > we don't have them in the binary distribution). I've had a hell of an experience in this area. The one word summary is: ENFW. I've had experience with Sun VME FDDI Cards, Sun FDDI 1.0 cards (from Bantam), Sun FDDI 3.0 cards (which are from NP) and Cisco boards (interphase). For all interfaces you can use the hack from anders clemets to have the boards running in a machine with multicast. You won't be able to send multicast over these interfaces though. If you want to try multicast directly supported on the fddi, these are the Results: - 3.3 multicast distribution FDDI support for the Sun Bantam board is a hoax, it has explicitly no multicast support compiled in. - SunLink FDDI 3.0 comes with a 4.1.3 driver for multicast that crashes the machine. I didn't had the nerves to bug report that with enough force to get that fixed, because it's incredible cumbersome to do bug reporting to sun on products that they themselves only licensed (SunLink FDDI 3.0 is both hardware and software from NP, whereas with SunLink FDDI 1.0/2.0 the boards are from Bantam and the software is from sun). - The new NP boards are said to have multicast support (haven't tested those myself), but it's said to be broken. An older version of the NP software for their own board (not for those that they sell to sun) is said to work. I tried that software with a Sun FDDI 3.0 board (needed only minor hacking in the binary) and it actually worked. Only problem was that the board was loosing about 10% of the multicast packets that it received on FDDI. The same bug is also there for the SunLink FDDI 3.0 driver in Solaris, where multicast is supported officially. Again: no nerves to bugreport it. - The Crescendo boards come with no multicast support for 4.1.3 as far as i could see it. Use solaris with a SunLink FDDI 1.0 interface i would guess. Toerless From list-mgr@ISI.EDU Mon Feb 20 10:10:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 02:11:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 02:10:53 -0800 Received: from cancer.ucs.ed.ac.uk ([129.215.200.7]) by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 02:10:51 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id KAA10835; Mon, 20 Feb 1995 10:10:09 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id KAA07354; Mon, 20 Feb 1995 10:10:06 GMT Date: Mon, 20 Feb 1995 10:10:04 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Adam Goodman Cc: mbone, rem-comf@net.es Subject: Re: your mail In-Reply-To: Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 20 Feb 1995, Adam Goodman wrote: > Hello All, > > I wonder if anyone can help with this question. I am in the process of > purchasing a new SparcStation that will be used primarily for Mbone > applications. > > I know that development of multicast applications takes place under SunOS > 4.1.3. Unfortunately, new SparcStations only ship with Solaris 2.4, which > is incompatible with the new multicast apps. Where did you hear this? I have all the publically available applications running on Solaris 2.4 (wb, nv, vic, vat, sd, imm, nevot). The only thing that is not available for Solaris 2.4 (yet) is version 3.3 of IP multicast; this means that if you want to make your machine a multicast router you will need to run mrouted 2.2. As a result of this you will not get the benefits of multicast pruning and your network provider/local network manager may not allow this. > So, the question is this; does anyone know of a way of acquiring SunOS > 4.1.3 for installation on a new Sparc? You can buy a licence from Sun/your reseller when you buy your machine. > Any help here will as always be much appreciated. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Mon Feb 20 12:24:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 02:25:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 02:24:55 -0800 Received: from gmdzi.gmd.de by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 02:24:52 -0800 Received: from bagheera.gmd.de (bagheera) by gmdzi.gmd.de with SMTP id AA16491 (5.65c8/IDA-1.4.4 for ); Mon, 20 Feb 1995 11:24:43 +0100 Received: by bagheera.gmd.de id AA27726 (5.67b8/IDA-1.5 for mbone@isi.edu); Mon, 20 Feb 1995 11:24:42 +0100 Date: Mon, 20 Feb 1995 11:24:42 +0100 From: Reiner Brabender Message-Id: <199502201024.AA27726@bagheera.gmd.de> To: mbone Subject: Subscribe Reiner.Brabender@gmd.de ----- Begin Included Message ----- From MAILER-DAEMON@gmdzi.gmd.de Mon Feb 20 11:23:12 1995 Date: Mon, 20 Feb 1995 11:22:53 +0100 To: reiner@bagheera.gmd.de Subject: Returned mail: Remote protocol error X-Charset: LATIN1 X-Char-Esc: 29 Content-Length: 740 X-Lines: 18 ----- Transcript of session follows ----- While talking to mail.germany.eu.net: >>> RCPT To: <<< 501 ... no such host:isi-edu 554 ... Remote protocol error PLEASE SUBSCRIBE Reiner.Brabender@gmd.de From list-mgr@ISI.EDU Mon Feb 20 03:09:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 03:10:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 03:10:25 -0800 Received: from vitep3.itep.ru by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 03:09:54 -0800 Received: by vitep3.itep.ru (MX V4.1 VAX) id 2; Mon, 20 Feb 1995 14:08:16 EET Date: Mon, 20 Feb 1995 14:05:03 EET From: anovikov@vitep3.itep.ru To: mbone Message-Id: <0098C453.6C5D4040.2@vitep3.itep.ru> Subject: Unsubscribe anovikov@vxitep.itep.ru Cause of unsuffisient disk place here I'm changing to anovikov@helious.itep.ru From list-mgr@ISI.EDU Mon Feb 20 02:18:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 04:20:09 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 04:18:42 -0800 Received: from tintagel.ops.aol.com by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 04:18:40 -0800 Received: by tintagel.ops.aol.com with SMTP (1.37.109.11/16.2) id AA135332715; Mon, 20 Feb 1995 07:18:35 -0500 Message-Id: <199502201218.AA135332715@tintagel.ops.aol.com> To: mbone Subject: mrouted for hp-ux Date: Mon, 20 Feb 1995 07:18:35 -0500 From: "Matthew V. J. Whalen" Before I experiment with compiling teh different versions of mrouted, I thought that I sould ask what version of mrouted is suggested for machines running hp-ux 9.0.x (if any of them are). I can find a sun to put it on if I need to, but I'd prefer to use an HP if possible. Thanks -matthew | I bet the main reason the police keep people away whalenm@aol.net | from a plane crash is that they don't want anybody | walking in and lying down in the crash stuff, | then, when somebody comes up, act like they just America Online, Inc. | woke up and go, "What was THAT?!" From list-mgr@ISI.EDU Mon Feb 20 14:29:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 04:30:14 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 04:29:48 -0800 Received: from concorde.inria.fr by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 04:29:45 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.9/8.6.9) with ESMTP id NAA29573; Mon, 20 Feb 1995 13:29:11 +0100 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.8/8.6.6) with ESMTP id NAA04728; Mon, 20 Feb 1995 13:29:10 +0100 Message-Id: <199502201229.NAA04728@givry.inria.fr> From: Francis Dupont To: Toerless Eckert Cc: wolf@prz.tu-berlin.de (Thomas Wolfram), mbone, mbone-de@informatik.uni-erlangen.de Subject: Re: SBus FDDI cards & multicast drivers In-Reply-To: Your message of Mon, 20 Feb 1995 11:08:54 +0100. <199502201009.AA10589@faui43.informatik.uni-erlangen.de> Date: Mon, 20 Feb 1995 13:29:01 +0100 Sender: Francis.Dupont@inria.fr In your previous mail you wrote: > I'm looking for SBus FDDI boards which have multicast capable > drivers for SunOS 4.1.3 U1 and work with the kernel changes > of the "ipmulti 3.3" package. We want to run the mrouted 3.3 > on a machine with FDDI interface. => we use Cisco (ex Crescendo) SBus FDDI boards. They works without problems with IP multicast but: - we have both binary and source releases for SunOS 4.1.3 (with a non-disclosure agreement for the sources). - last summer binary driver was compiled without IP multicast but a new version with support for multicast was announced. - IP multicast support was already in sources then we recompiled them! I believe we should ask to Cisco support (our contact was Buck Gee ) a driver with IP multicast support. Regards Francis.Dupont@inria.fr From list-mgr@ISI.EDU Tue Feb 21 12:20:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 06:21:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 06:20:26 -0800 Received: from ledoux.arbld.unimelb.EDU.AU by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 06:20:24 -0800 Received: (darrenr@localhost) by ledoux.arbld.unimelb.EDU.AU (8.6.9/8.6.4) id BAA21604 for mbone@isi.edu; Tue, 21 Feb 1995 01:20:22 +1100 Date: Tue, 21 Feb 1995 01:20:22 +1100 From: Darren Reed Message-Id: <199502201420.BAA21604@ledoux.arbld.unimelb.EDU.AU> To: mbone Subject: tcpdump 3.0 & multicast tunnels What's the correct way to get tcodump to include/exclude multicast IP packets which are from a multicast IP tunnel ? Looking just now, they all show up with "udp xxx (encap)" on the end... (using BPF) but using "ether multicast" or "ip multicast" doesn't seem to work on these packets, nor is there a way to selectively filter the encapsulated packets. Any clues ? thanks, Darren From list-mgr@ISI.EDU Sun Feb 19 23:41:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 07:38:10 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 07:37:53 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 07:37:51 -0800 Received: by rx7.ee.lbl.gov for mbone@isi.edu (5.65/1.44r) id AA19572; Mon, 20 Feb 95 07:41:20 -0800 Message-Id: <9502201541.AA19572@rx7.ee.lbl.gov> To: Darren Reed Cc: mbone Subject: Re: tcpdump 3.0 & multicast tunnels In-Reply-To: Your message of Tue, 21 Feb 95 01:20:22 X. Date: Mon, 20 Feb 95 07:41:19 PST From: Van Jacobson The encapsulated packets are all ip protocol number 4. So "tcpdump ip proto 4" will get only them & "tcpdump not ip proto 4" will exclude them. - Van From list-mgr@ISI.EDU Sun Feb 19 04:57:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 08:57:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 08:56:46 -0800 Received: from elroy.jpl.nasa.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 08:56:45 -0800 Received: from isolar.UUCP by elroy.jpl.nasa.gov (4.1/SMI-4.1+DXR) id AA01042; Mon, 20 Feb 95 08:56:21 PST Received: by isolar.Tujunga.CA.US (4.1/SATAN-6.6.6) id AA04530; Sun, 19 Feb 95 12:57:01 PST Date: Sun, 19 Feb 95 12:57:01 PST From: earle@isolar.Tujunga.CA.US (Greg Earle) Message-Id: <9502192057.AA04530@isolar.Tujunga.CA.US> To: kre@cs.Mu.OZ.AU Subject: Re: A couple of multicast/av hardware questions Newsgroups: jpl.mail.mbone References: <9502180307.16636@mulga.cs.mu.OZ.AU> In-Reply-To: <9502180307.16636@mulga.cs.mu.OZ.AU> Organization: Personal Usenet site, Tujunga, CA USA Cc: mbone In article <9502180307.16636@mulga.cs.mu.OZ.AU> you write: > 1) Does anyone happen to have one of Sun's "Quad Ethernet" cards, and > multicast support for it. I'm considering getting one, and would like > for it to be able to run multicast (SunOS 4.1.3_U1 or 4.1.4). It's > supposed to come with a driver, so can't be using the standard drivers > for which we have multicast support. Unless something has changed or my memory is getting a lot worse, the Quad Ethernet board is only supported by Solaris 2.3 or later (or maybe 2.2). If you have information to the contrary, etc. ... > 2) I suppose this is a bit early, but does anyone know if the new SS4 > uses the same audio hardware (on its optional audio board) as the SS5, > and so will use the driver Sun haven't worked out how to write, or does > it use one of the ones that works well, or perhaps something new, yet again? Pure supposition on my part, but all I know about the SS4 indicates that it is a stripped-down SS5, so one could assume that the audio chip is the same. - Greg From list-mgr@ISI.EDU Mon Feb 20 18:56:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 09:08:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 09:07:18 -0800 Received: from mailgzrz.TU-Berlin.DE by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 09:06:57 -0800 Received: from tubkom.prz.tu-berlin.de by mailgzrz.TU-Berlin.DE with SMTP (PP); Mon, 20 Feb 1995 17:56:27 +0100 Received: from havoc.prz.tu-berlin.de (havoc.prz.tu-berlin.de [130.149.226.40]) by tubkom.prz.tu-berlin.de (8.6.9/8.6.9) with SMTP id RAA02609; Mon, 20 Feb 1995 17:56:22 +0100 Message-Id: <199502201656.RAA02609@tubkom.prz.tu-berlin.de> Received: by havoc.prz.tu-berlin.de (NX5.67e/NX3.0X) id AA22205; Mon, 20 Feb 95 17:56:50 +0100 Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: multipart/alternative; boundary=NeXT-Mail-2072565443-1 Content-Transfer-Encoding: 7bit Original-Received: by NeXT.Mailer (1.118.2) Pp-Warning: Illegal Received field on preceding line From: Thomas Wolfram Date: Mon, 20 Feb 95 17:56:48 +0100 To: Toerless Eckert Subject: Re: SBus FDDI cards & multicast drivers Cc: mbone, mbone-de@informatik.uni-erlangen.de References: <199502201009.AA10589@faui43.informatik.uni-erlangen.de> Return-Receipt-To: wolf@prz.tu-berlin.de --NeXT-Mail-2072565443-1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, thanks for your answer though it doesn't sound very optimistic. > I've had a hell of an experience in this area. The one word summary is: = ENFW. >=20 > I've had experience with Sun VME FDDI Cards, Sun FDDI 1.0 cards (from = Bantam), > Sun FDDI 3.0 cards (which are from NP) and Cisco boards (interphase). >=20 > For all interfaces you can use the hack from anders clemets to have > the boards running in a machine with multicast. You won't be able to > send multicast over these interfaces though. I wasn't aware that patches are necessary also for "normal" operation (unicast only). Where can I get these patches and are they available for SunOS 4.1.3_U1 too? > If you want to try multicast directly supported on the fddi, these are the > Results: [...sad results deleted...] =20 >=20 > Use solaris with a SunLink FDDI 1.0 interface i would guess. But with Solaris I can't run mrouted 3.3 yet... (Apart from of the fact that I don't have a Bantam board here...) At least I hope to get a tunnel running over FDDI on a SunOS 4.1.3_U1 machine (Sparc 20) with mrouted 3.3.??? As I understand that should be possible with Anders Clemets patches? Thomas -- Thomas Wolfram Germany: 0 30 = 31421171 PRZ TU Berlin abroad: +49 30 = 31421171 EANTC WWW: = http://www.prz.tu-berlin.de:/~wolf = _____________________________________________________________________________ = _____S__I__C____T__R__A__N__S__I__T____G__L__O__R__I__A____M__U__N__D__I_____ --NeXT-Mail-2072565443-1 Content-Type: text/enriched; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, thanks for your answer though it doesn't sound very optimistic. > I've had a hell of an experience in this area. The one word summary is: = ENFW. >=20 > I've had experience with Sun VME FDDI Cards, Sun FDDI 1.0 cards (from = Bantam), > Sun FDDI 3.0 cards (which are from NP) and Cisco boards (interphase). >=20 > For all interfaces you can use the hack from anders clemets to have > the boards running in a machine with multicast. You won't be able to > send multicast over these interfaces though. I wasn't aware that patches are necessary also for "normal" operation (unicast only). Where can I get these patches and are they available for SunOS 4.1.3_U1 too? > If you want to try multicast directly supported on the fddi, these are the > Results: [...sad results deleted...] =20 >=20 > Use solaris with a SunLink FDDI 1.0 interface i would guess. But with Solaris I can't run mrouted 3.3 yet... (Apart from of the fact that I don't have a Bantam board here...) At least I hope to get a tunnel running over FDDI on a SunOS 4.1.3_U1 machine (Sparc 20) with mrouted 3.3.??? As I understand that should be possible with Anders Clemets patches? Thomas -- Thomas Wolfram < Germany: 0 30 = 31421171 PRZ TU Berlin < abroad: +49 30 = 31421171 EANTC WWW: = http://www.prz.tu-berlin.de:/~wolf = _____________________________________________________________________________ = _____S__I__C____T__R__A__N__S__I__T____G__L__O__R__I__A____M__U__N__D__I_____ --NeXT-Mail-2072565443-1-- From list-mgr@ISI.EDU Mon Feb 20 08:35:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 10:35:55 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 10:35:36 -0800 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 10:35:35 -0800 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA13750; Mon, 20 Feb 95 13:35:33 EST Date: Mon, 20 Feb 95 13:35:33 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9502201835.AA13750@itd.nrl.navy.mil> To: mbone Subject: S-Bus FDDI cards for multicast do exist ! Folks, We've been using the NP-brand S-Bus FDDI boards made by NP (i.e. NOT the ones that Sun sells you) with both SunOS 4.1.3 and Solaris 2 for a long time (over 18 months) now without any problems. We have both SAS and DAS S-bus cards from NP; both work fine. We have not used the Clements patches on any system here. On SunOS 4.1.3, we've worked from the distribution on gregorio.stanford.edu and used the NP-supplied device drivers. On Solaris 2.x, we've used the NP-supplied device drivers and stock Solaris 2.x kernel (which includes multicast as a normal service). NP has occasionally built (by accident) a version or two of their device drivers for SunOS 4.1.3 that didn't work properly with multicasting. If you got one of those in your NP box, it will be apparent when you rebuild the multicast kernel and that rebuild fails because symbols aren't defined. In this event, don't despair but instead get in touch with NP directly and explain you've got a device driver that doesn't work with IP multicast. They have an anonymous ftp site on the net (whose name I forget, perhaps npix.com or ftp.npix.com ??) and you can download a fixed device driver at no charge. Sites without sources can use NP's S-Bus FDDI _just fine_ without weird extra hacks. NRL is an existence proof of this. Ran atkinson@itd.nrl.navy.mil From list-mgr@ISI.EDU Mon Feb 20 06:55:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 10:51:35 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 10:51:24 -0800 Received: from utsw.swmed.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 10:51:23 -0800 Received: from visual-ra.swmed.edu by UTSW.SWMED.EDU (PMDF V4.3-13 #3937) id <01HN9U8B8FR48ZE5KI@UTSW.SWMED.EDU>; Mon, 20 Feb 1995 12:50:00 -0500 (CDT) Received: by visual-ra.swmed.edu (4.1/SMI-4.1) id AA07873; Mon, 20 Feb 95 12:55:30 CST Date: Mon, 20 Feb 1995 12:55:30 -0600 (CST) From: roddy@visual-ra.SWMED.EDU (Roddy McColl) Subject: tunneling from Dallas, Texas To: mbone Message-Id: <9502201855.AA07873@visual-ra.swmed.edu> Content-Transfer-Encoding: 7BIT I would like to explore the mbone. My machine is connected to a campus in Dallas, Texas (UT Southwestern Medical Center). Does anyone know of a close point of connection for this site? Roddy McColl UT Southwestern From list-mgr@ISI.EDU Mon Feb 20 03:04:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 11:05:15 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 11:05:01 -0800 Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 11:05:00 -0800 From: bmanning@ISI.EDU Posted-Date: Mon, 20 Feb 1995 11:04:12 -0800 (PST) Message-Id: <199502201904.AA12439@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Mon, 20 Feb 1995 11:04:13 -0800 Subject: Re: tunneling from Dallas, Texas To: roddy@visual-ra.SWMED.EDU (Roddy McColl) Date: Mon, 20 Feb 1995 11:04:12 -0800 (PST) Cc: mbone In-Reply-To: <9502201855.AA07873@visual-ra.swmed.edu> from "Roddy McColl" at Feb 20, 95 12:55:30 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 288 > > > I would like to explore the mbone. My machine is connected to a campus > in Dallas, Texas (UT Southwestern Medical Center). Does anyone know of > a close point of connection for this site? > > Roddy McColl > UT Southwestern > You might try UT-Dallas in Richardson. -- --bill From list-mgr@ISI.EDU Mon Feb 20 07:21:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 11:23:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 11:22:42 -0800 Received: from iphase.com by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 11:22:38 -0800 Received: from megalon.iphase.com by iphase.com (4.1/1.34) id AA05111; Mon, 20 Feb 95 13:22:20 CST Received: from wildcat (wildcat_fddi) by megalon.iphase.com (4.1/SMI-4.1) id AA19806; Mon, 20 Feb 95 13:21:56 CST From: dmoeller@iphase.com (Doug Moeller) Received: by wildcat (4.1//ident-1.0) id AA09462; Mon, 20 Feb 95 13:21:35 CST Message-Id: <9502201921.AA09462@wildcat> Subject: Re: SBus FDDI cards & multicast drivers To: wolf@prz.tu-berlin.de (Thomas Wolfram) Date: Mon, 20 Feb 1995 13:21:35 -0600 (CST) Cc: mbone, mbone-de@informatik.uni-erlangen.de In-Reply-To: <199502192301.AAA24957@tubkom.prz.tu-berlin.de> from "Thomas Wolfram" at Feb 20, 95 00:01:09 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1449 The Interphase SBus 4611 FDDI board works with ipmulti 3.3. -Doug > > > Hi, > > I'm looking for SBus FDDI boards which have multicast capable > drivers for SunOS 4.1.3 U1 and work with the kernel changes > of the "ipmulti 3.3" package. We want to run the mrouted 3.3 > on a machine with FDDI interface. > The "ipmulti 3.3" release contains only patches for the > Sun "Bantam" FDDI boards. > > Maybe someone has a list? > Especially I would like to know whether there are multicast > drivers available for: > > - CMC 950 boards > - Network Peripherals (NP) boards > - Crescendo boards > - Interphase (iphase) boards > > The second important question: if we have only a usual binary > distribution of SunOS (i.e. no source license) is it possible > at all to include support for IP multicast over (non-Bantam) > FDDI in the kernel? (That would be the case if there are source > files which would need recompliation but we cannot do it because > we don't have them in the binary distribution). > > Thank you in advance, > Thomas > -- > Thomas Wolfram Germany: 0 30 31421171 > PRZ TU Berlin abroad: +49 30 31421171 > EANTC WWW: http://www.prz.tu-berlin.de:/~wolf > _____________________________________________________________________________ > _____S__I__C____T__R__A__N__S__I__T____G__L__O__R__I__A____M__U__N__D__I_____ > > From list-mgr@ISI.EDU Tue Feb 21 18:42:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 12:44:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 12:43:45 -0800 Received: from munnari.OZ.AU by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 12:43:41 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16184; Tue, 21 Feb 1995 07:43:11 +1100 (from kre@munnari.OZ.AU) To: earle@isolar.Tujunga.CA.US (Greg Earle) Cc: mbone Subject: Re: A couple of multicast/av hardware questions In-Reply-To: Your message of "Sun, 19 Feb 1995 12:57:01 PST." <9502192057.AA04530@isolar.Tujunga.CA.US> Date: Tue, 21 Feb 1995 07:42:10 +1100 Message-Id: <4835.793312930@munnari.OZ.AU> From: Robert Elz Date: Sun, 19 Feb 95 12:57:01 PST From: earle@isolar.Tujunga.CA.US (Greg Earle) Message-ID: <9502192057.AA04530@isolar.Tujunga.CA.US> Unless something has changed or my memory is getting a lot worse, the Quad Ethernet board is only supported by Solaris 2.3 or later (or maybe 2.2). If you have information to the contrary, etc. ... The quote I have says ... X1058A SBus Quad Ethernet Controller 1.1 (SQEC) SBus Card and Documentation SBus Quad Ethernet Controller (SQEC) and Solaris 1.1.1 and 1.1.2 Driver (why it has all that repeated info I have no idea, but that's what came from the local sales office quote generation software). I first saw this thing in the local "abbreviated" price list in the category "Accessories for SPARCsystems" under "SBus Expansion Options", the generic section, not the "with Solaris 1 Specific Software" nor "with Solaris 2 Specific Software". In there it says... "SBus Quad Ethernet Driver (SQEC) and Solaris 1.1.1 and 1.1.2 driver". From that I assumed support for it was probably bundled in Solaris 2, but an add-on in Solaris 1 (SunOS 4). I see my 2.3 systems have /kernel/drv/qe and qec though since I don't have hardware to test those I'm just guessing. That's why I was a little concerned about finding multicast support for it (SunOS4), it looks like it may be one of those options that almost no-one actually uses, and no-one has SunOS driver support for. I have asked local Sun people about this, of course, no response yet. Pure supposition on my part, but all I know about the SS4 indicates that it is a stripped-down SS5, so one could assume that the audio chip is the same That's what I was assuming too - I was half hoping someone would reply and say "No, Sun realised that one was a disaster, and put back the LX audio", or something... I've heard the SS4 described as both an cut down SS5, or as a souped up Classic. Since the audio is on a separate board, at the minute I'd believe almost anything about it, but it does sound a lot like the SS5 version. Thanks, kre From list-mgr@ISI.EDU Mon Feb 20 05:15:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 13:15:29 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 13:15:12 -0800 Received: from elxr.jpl.nasa.gov (elxr-fddi.jpl.nasa.gov) by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Feb 1995 13:15:10 -0800 Received: (from dave@localhost) by elxr.jpl.nasa.gov (8.6.8/8.6.6) id NAA00228; Mon, 20 Feb 1995 13:15:40 -0800 Date: Mon, 20 Feb 1995 13:15:40 -0800 From: Dave Hayes Message-Id: <199502202115.NAA00228@elxr.jpl.nasa.gov> To: Toerless.Eckert@informatik.uni-erlangen.de Cc: mbone Subject: Re: SBus FDDI cards & multicast drivers >- The Crescendo boards come with no multicast support for 4.1.3 as far > as i could see it. In fact, we have Crescendo FDDI multicast support for 4.1.3_U1. Works fine over here, but I'd like to know if I can go to mrouted 3.3 someday. ------ Dave Hayes -- Institutional NETworks - Section 394 -- JPL/NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh Exaggeration is a standard peculiarity of man. To deprecate is often a form of exaggeration which people do not notice because it appears to be its opposite. From list-mgr@ISI.EDU Mon Feb 20 22:44:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 06:44:40 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 06:42:55 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 06:42:54 -0800 Received: by rx7.ee.lbl.gov for mbone@isi.edu (5.65/1.44r) id AA21055; Tue, 21 Feb 95 06:44:19 -0800 Message-Id: <9502211444.AA21055@rx7.ee.lbl.gov> To: Robert Elz Cc: mbone Subject: Re: A couple of multicast/av hardware questions In-Reply-To: Your message of Tue, 21 Feb 95 07:42:10 X. Date: Tue, 21 Feb 95 06:44:18 PST From: Van Jacobson > one could assume that the audio chip is the same > > That's what I was assuming too - I was half hoping someone would > reply and say "No, Sun realised that one was a disaster, and put > back the LX audio", or something Robert, Actually the SS-5 CS-4231 audio chip is a pretty reasonable piece of hardware -- I think it's far superior to the AT&T DBRI audio chip used in the LX, SS-10 & SS-20. I believe the SS-5 audio problems were due to poor driver software & there is some reason to suspect that in the near future Sun will distribute drivers that work quite well with vat. - Van From list-mgr@ISI.EDU Tue Feb 21 02:02:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:06:08 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:05:29 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:05:28 -0800 Received: from utsw.swmed.edu by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 21 Feb 1995 06:07:07 -0800 Received: from medcat.library.swmed.edu by UTSW.SWMED.EDU (PMDF V4.3-13 #3937) id <01HNAYJNAHN48ZESIU@UTSW.SWMED.EDU>; Tue, 21 Feb 1995 08:04:27 -0500 (CDT) Date: Tue, 21 Feb 1995 08:02:51 -0600 (CST) From: "Mark Thacker, Internet Specialist" Subject: Subscribe Mark Thacker To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT subscribe Mark Thacker ------- Mark Thacker, Internet Specialist Library UT Southwestern Medical at Dallas 5323 Harry Hines Dallas, Texas 75235-9049 Phone: 214-648-2568 Fax: 214-648-2826 From list-mgr@ISI.EDU Tue Feb 21 12:50:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:22:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:22:02 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:22:01 -0800 Received: from faui45.informatik.uni-erlangen.de by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 21 Feb 1995 02:53:12 -0800 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA10105 (5.65c-6/7.3w-FAU); Tue, 21 Feb 1995 11:51:07 +0100 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA24461 (5.65c-6/7.3m-FAU); Tue, 21 Feb 1995 11:51:04 +0100 From: Toerless Eckert Message-Id: <199502211051.AA24461@faui43.informatik.uni-erlangen.de> Subject: Re: SBus FDDI cards & multicast drivers To: dave@elxr.jpl.nasa.gov (Dave Hayes) Date: Tue, 21 Feb 1995 11:50:57 +0100 (MET) Cc: Toerless.Eckert@informatik.uni-erlangen.de, mbone In-Reply-To: <199502202115.NAA00228@elxr.jpl.nasa.gov> from "Dave Hayes" at Feb 20, 95 01:15:40 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > In fact, we have Crescendo FDDI multicast support for 4.1.3_U1. Works > fine over here, but I'd like to know if I can go to mrouted 3.3 someday. Aha, where did you get it from ? Upgrading to 3.3 will not require changes to the multicasting support in the device driver, so what are you waiting for ? Toerless From list-mgr@ISI.EDU Tue Feb 21 10:47:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:23:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:21:48 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:21:46 -0800 Received: from swan.cl.cam.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 21 Feb 1995 03:47:53 -0800 Received: from mallard.cl.cam.ac.uk (user pb (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Tue, 21 Feb 1995 10:48:02 +0000 X-Mailer: exmh version 1.6alpha 2/16/95 To: rem-conf@net.es, mbone Cc: Piete.Brooks@cl.cam.ac.uk, Graham.Titmus@cl.cam.ac.uk, Ross.Anderson@cl.cam.ac.uk Reply-To: Piete.Brooks@cl.cam.ac.uk Subject: Mbone transmission 94/12/05 16:15-17:15 UTC (cl.cam.ac.uk Security) X-Uri: X-Face: &@N3QE9h|>f`igFCkZ'a1`z=nNLXb}k>H(79G"V?@!&*yn)uhPBctF1vc}LD'{OA%$bsX+l [wN,I^G8kKj2NFxQrr@1C4QBC]hq5-%ZkV,^Zl/qE<0`zCQ1nM+]-N<^WG[H)]?d)A:L9AF gOU[BjbaY)uBAMz}h!fm^O0# Mime-Version: 1.0 Content-Type: text/plain Date: Tue, 21 Feb 1995 10:47:48 +0000 From: Piete Brooks Message-Id: <"swan.cl.cam.:136070:950221104811"@cl.cam.ac.uk> We are planning to transmit this week's Security Seminar at TTL 31 -- i.e. just within JIPS (ac.uk) -- unless anyone wants the TTL raised. If so, please let me know your nearest mrouted, and whether you want just the audio, or audio and video. It's meant as a "low key" transmission (without anyone manning the camera, etc). The video will just be of the speaker (slides are likley only be available via the WWW -- not on the video feed). There is also a possibility that we might be transmitting our departmental seminar at a TTL of 31 (as it relates to AC.UK) *IF* we get a suitable link-up between our ATM world and nv (which might involve the X11 screen grabber !) and we can get electronic slides. Again, let me know if you want the TTL raised. SPEAKER: Dieter Gollmann, Royal Holloway, University of London DATE: 21st February 1995 at 4.15pm (16:15 UTC) TITLE: CRYPTOGRAPHIC API'S REVISITED Security APIs promise support for the design of secure systems, divorcing application writers from security experts, solving problems of export restrictions, creating a market for COTS products, etc. In this spirit, we will examine current proposals for cryptographic APIs, raise some conceptual issues regarding their function, and use this discussion as an excuse to refer to the problem of using the right language to talk about security. This seminar will be multicast (audio and video) on the mbone as part of our multimedia test programme. Further information is available at http://www.cl.cam.ac.uk/mbone/#cl. NAME:Dr David Hartley, UKERNA DATE:Wednesday 22nd February 1995 at 4.15pm (16:15 UTC) TITLE:The development of broadband networking services for the academic community Ever since the decisions taken in 1983 to establish the Joint Academic Network (JANET), the UK higher education and research community has enjoyed an advanced service network. Originally supported by the Department for Education's Computer Board, the network and the organisation behind it has survived major changes, not least the demise of the Computer Board itself. Today, JANET is being transformed into SuperJANET, a broadband network designed to create opportunities for the community to develop entirely new applications, some of which are already being prioneered in the Cambridge research environment. The talk will describe the history of service networking in the UK, paying particular attention to the policy-making and funding aspects of the business. The present and projected state of SuperJANET will also be presented. For many years, the academic community's networking programme was supervised by the Joint Network Team, a unit established in the Science and Engineering Research Council. About a year ago the JNT was transferred into a new company, known as the United Kingdom Education and Research Networking Association (UKERNA), owned by the Higher Education Funding Councils. UKERNA has a remit to take responsibility for the networking programme, and is encouragd to undertake a wider set of activities for the benefit of networking in the community. From list-mgr@ISI.EDU Mon Feb 20 08:05:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:26:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:26:06 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:26:05 -0800 Received: from emerald.oz.net by quark.isi.edu (5.65c/5.61+local-20) id ; Mon, 20 Feb 1995 16:08:34 -0800 Received: from billk.oz.net by emerald.oz.net via SMTP (931110.SGI/930416.SGI) for mbone@ISI.EDU id AA08882; Mon, 20 Feb 95 16:05:59 -0800 Date: Mon, 20 Feb 95 16:05:59 -0800 Message-Id: <9502210005.AA08882@emerald.oz.net> X-Sender: billk@oz.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: billk@oz.net (Bill Kinnison) X-Mailer: Unsubscribe, again, third request in last 2 weeks. billk@oz.net Bill Kinnison :-} Voice 206-641-4230 FAX 206-562-1892 From list-mgr@ISI.EDU Tue Feb 21 17:47:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:49:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:49:38 -0800 Received: from faui45.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 07:49:22 -0800 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA00231 (5.65c-6/7.3w-FAU); Tue, 21 Feb 1995 16:47:45 +0100 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA14224 (5.65c-6/7.3m-FAU); Tue, 21 Feb 1995 16:47:42 +0100 From: Toerless Eckert Message-Id: <199502211547.AA14224@faui43.informatik.uni-erlangen.de> Subject: Re: A couple of multicast/av hardware questions To: van@ee.lbl.gov (Van Jacobson) Date: Tue, 21 Feb 1995 16:47:33 +0100 (MET) Cc: kre@munnari.oz.au, mbone In-Reply-To: <9502211444.AA21055@rx7.ee.lbl.gov> from "Van Jacobson" at Feb 21, 95 06:44:18 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Actually the SS-5 CS-4231 audio chip is a pretty reasonable > piece of hardware -- I think it's far superior to the AT&T DBRI ^^^^^^^^^^^^^^^^^^^^^^^^^ Just being curious: could you explain why it's superior ? Thanks Toerless From list-mgr@ISI.EDU Tue Feb 21 16:47:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 08:47:24 -0800 Received: from work.dfrf.nasa.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 08:47:24 -0800 Received: by work.dfrf.nasa.gov (8.6.8/1.35) id QAA05837; Tue, 21 Feb 1995 16:47:33 GMT Date: Tue, 21 Feb 1995 16:47:33 GMT From: sears@work.dfrf.nasa.gov (Dale Sears) Message-Id: <199502211647.QAA05837@work.dfrf.nasa.gov> To: mbone-na Subject: unsubscribe X-Sun-Charset: US-ASCII From list-mgr@ISI.EDU Tue Feb 21 10:51:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 12:51:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 12:51:25 -0800 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 12:51:23 -0800 Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id PAA12642 for ; Tue, 21 Feb 1995 15:51:13 -0500 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Feb 1995 15:51:25 -0500 To: mbone From: Scott Brim Subject: topology change With the death of NSFNET, Cornell is no longer topologically near the center of things. We now have an mbone tunnel to the Pennsauken NAP. I'd like to suggest that our tunnels to Nearnet, MIT and ARPA have their metrics increased so that they go through us only as a fallback. On this end I've set them to 7. How does that sound? Oh, and I think INRIA should stop using us as a backup at all. ...Scott From list-mgr@ISI.EDU Tue Feb 21 04:51:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 12:52:15 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 12:51:56 -0800 Received: from inet1.tek.com by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 12:51:53 -0800 Received: from tektronix.tek.com by inet1.tek.com id ; Tue, 21 Feb 1995 12:52:01 -0800 Received: from dtl.labs.tek.com (crl.labs.tek.com) by tektronix.TEK.COM (4.1/8.2) id AA07751; Tue, 21 Feb 95 12:51:18 PST Received: from icebox.LABS.TEK.COM (icebox.TEK) by dtl.labs.tek.com (4.1/8.0) id AA21560; Tue, 21 Feb 95 12:49:35 PST Received: from icebox (localhost) by icebox.LABS.TEK.COM (5.x/SMI-SVR4) id AA01115; Tue, 21 Feb 1995 12:51:42 -0800 Message-Id: <9502212051.AA01115@icebox.LABS.TEK.COM> To: mbone Cc: tedb@icebox.LABS.TEK.COM, frederic@parc.xerox.COM, speer@eng.sun.COM, maslen@eng.sun.COM Subject: NV and sunvideo board problem? From: Ted Brunner Date: Tue, 21 Feb 1995 12:51:42 -0800 Sender: tedb@icebox.LABS.TEK.COM Hello again. I have a problem using NV. We've been doing some hacking on Solaris 2.3 and 2.4 boxes with SAHI and Efficient Networks ATM cards plugged in. We've been using Sunvideo cards. In the process we've done all sorts of reassignment of parameters on the sunvideo/rtvc card through xil. This has produced an interesting reaction from NV. Whereas NV has worked just fine in the past, it now displays what appears to be an error condition. The nv and the cu-seeme encoding options give a black image, while the cellb works fine. This is true for locally compiled nv, and the bin distribution. If I use vic.rtvc, I get an actual image just fine for the same encoding choices, and others as well. One thought: since nv and cu-seeme are soft encode while cellb is hardware encode, perhaps in our hacking, we have reset some parameter on the sunvideo card for extracting uncompressed images, and NV's startup doesn't straighten it out. Vic's start up does allow vic to work properly, but doesn't "fix" the card so NV can work afterwards. Another thought is some funny interaction with Solaris 2.4, since I can't remember if NV ever worked properly with 2.4 - the history of hacking and system upgrades has been intertwined. Has anyone else had problems with NV, sunvideo and Solaris 2.4? Any light you could shed would be appreciated... Ted Brunner Communication Systems Research Lab Tektronix MS 50-370 ted.brunner@tek.com 14150 SW Karl Braun 503.627.1317 Beaverton OR 97005 From list-mgr@ISI.EDU Tue Feb 21 11:09:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 13:11:29 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 13:11:14 -0800 Received: from vax.darpa.mil (darpa.mil) by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 13:11:11 -0800 Received: from next146.darpa.mil (next146.darpa.mil) by vax.darpa.mil (5.65c/5.61+local-5) id ; Tue, 21 Feb 1995 16:11:10 -0500 Received: by next146.darpa.mil (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA05038; Tue, 21 Feb 95 16:09:45 EST Date: Tue, 21 Feb 1995 16:09:44 -0500 (EST) From: bmiller@csto.snap.org Subject: Re: topology change To: Scott Brim Cc: mbone Message-Id: <950221160944.4776AABmI.bmiller@next146> In-Reply-To: Mime-Version: 1.0 (Generated by Eloquent) Content-Type: text/plain; charset=US-ASCII X-Mailer: Eloquent[2.0]; Eloquent is a Trademark of Take 3 |>I'd like to suggest that our tunnels to Nearnet, MIT and ARPA have |>their metrics increased so that they go through us only as a fallback. |>On this end I've set them to 7. I just reset the ARPA<->Cornell tunnel to 7. Is anyone looking at a wholesale remapping of tunnels given the changing topology? I haven't looked into it in a while (following the "It's working - DON'T TOUCH IT!!" method of scheduling priorities), but I suspect that some of the other tunnels I've got here (sura, jvnc, and concert) could possibly be moved. I won't touch anything until requested... brian From list-mgr@ISI.EDU Tue Feb 21 05:14:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 13:15:45 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 13:15:32 -0800 Received: from elxr.jpl.nasa.gov (elxr-fddi.jpl.nasa.gov) by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 13:15:30 -0800 Received: (from dave@localhost) by elxr.jpl.nasa.gov (8.6.8/8.6.6) id NAA08091; Tue, 21 Feb 1995 13:14:15 -0800 Date: Tue, 21 Feb 1995 13:14:15 -0800 From: Dave Hayes Message-Id: <199502212114.NAA08091@elxr.jpl.nasa.gov> To: Toerless.Eckert@informatik.uni-erlangen.de Cc: mbone Subject: Re: SBus FDDI cards & multicast drivers Toerless.Eckert writes: >I wrote: >> In fact, we have Crescendo FDDI multicast support for 4.1.3_U1. Works >> fine over here, but I'd like to know if I can go to mrouted 3.3 someday. >Aha, where did you get it from ? Crescendo, of course. >Upgrading to 3.3 will not require changes to the multicasting support >in the device driver, so what are you waiting for ? Someone to confirm this, of course. It does require kernel changes, does it not? ------ Dave Hayes -- Institutional NETworks - Section 394 -- JPL/NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh If your own vice happens to be the search for virtue, recognize that it is so. From list-mgr@ISI.EDU Tue Feb 21 11:56:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 13:56:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 13:56:03 -0800 Received: from math.lsa.umich.edu (null.math.lsa.umich.edu) by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 13:56:02 -0800 Received: from hotbox.math.lsa.umich.edu by math.lsa.umich.edu with SMTP id AA23904 (5.67a/IDA-1.5 for mbone@isi.edu); Tue, 21 Feb 1995 16:56:01 -0500 Message-Id: <199502212156.AA23904@math.lsa.umich.edu> To: mbone Subject: config problems Date: Tue, 21 Feb 1995 16:56:00 -0500 From: Bill Niester I am trying to get mrouted3.3 to run on a SparcStation20/51 through the onboard ethernet adapter. The kernel will compile just fine with the 'options MROUTING' and 'options MULTICAST' lines present. However when I go to start mrouted3.3, I get the following message: can't enable DVMRP routing in kernel: Operation not supported on socket Anybody have similar problems or know of what I might have done wrong. I had mrouted3.3 running fine on a sparc2 and I upgraded machines and now I am cut off from the mbone. Any help would be greatly appreciated. You can respond to me directly or to the list. Bill ==================================================================== Bill Niester Email: niester@umich.edu The University of Michigan Phone: (313) 763-1182 Mathematics Department Pager: (313) 210-0167 Systems Manager Address: Rm 425 West Engineering Ann Arbor, MI 48109 =================================================================== From list-mgr@ISI.EDU Fri Feb 24 14:03:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 06:04:49 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 06:04:27 -0800 Received: from ashe.cs.tcd.ie by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 06:04:15 -0800 Message-Id: <199502241404.AA24466@venera.isi.edu> Received: from localhost by ashe.cs.tcd.ie with SMTP (PP) id <28028-0@ashe.cs.tcd.ie>; Fri, 24 Feb 1995 14:04:00 +0000 To: mbone Subject: Configuring mrouted Date: Fri, 24 Feb 1995 14:03:50 +0000 From: Hitesh Tewari Hi, Looking through the archive of mail's sent to this list, I know that the following query has been posted before, though I have not found any solution to it. I am trying to run the mrouted on a SPARC station running SunOS4.13. I get the following error: >mrouted -d debug level 2 mrouted $Revision 1.4 $ installing le0 a\(193.1.66.20 on subnet 193.1.66) as vif #0 can't forward: only one enabled vif The mrouted.conf file contains the following entry tunnel 193.1.66.20 129.11.128.108 metric 1 threshold 24 rate_limit 500 executing the ifconfig command results in > ifconfig le0 le0: flags=863 inet 193.1.66.20 netmask ffffff00 broadcast 193.1.66.0 ether 8:0:20:19:27:2b Can you tell me as to what I am missing or doing wrong. Thanks for your attention. Hitesh. -------- Hitesh Tewari Trinity College Dublin 353-1-702-1542 htewari@cs.tcd.ie Pardon me, I'm lost, can you direct me to the information superhighway? From list-mgr@ISI.EDU Fri Feb 24 06:11:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 08:13:00 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 08:12:33 -0800 Received: from lupine.nsi.nasa.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 08:12:30 -0800 Received: (from mnewell@localhost) by lupine.nsi.nasa.gov (8.6.9/8.6.9) id LAA21302; Fri, 24 Feb 1995 11:11:05 -0500 Date: Fri, 24 Feb 1995 11:11:00 -0500 (EST) From: "Michael C. Newell" To: Hitesh Tewari Cc: mbone Subject: Re: Configuring mrouted In-Reply-To: <199502241404.AA24466@venera.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 24 Feb 1995, Hitesh Tewari wrote: > I am trying to run the mrouted on a SPARC station running SunOS4.13. I get the > following error: > > >mrouted -d > debug level 2 > mrouted $Revision 1.4 $ --------------------^^^ Ouch! That's pretty old... V3.3 is current I think? > installing le0 a\(193.1.66.20 on subnet 193.1.66) as vif #0 > can't forward: only one enabled vif > > The mrouted.conf file contains the following entry > > tunnel 193.1.66.20 129.11.128.108 metric 1 threshold 24 rate_limit 500 -----------------------------------------------------------^^^^^^^^^^^^^^ For pre-V3 mrouted's, this line is a syntax error. An interesting thing about mrouted is that if you have a syntax error in an mrouted.conf line mrouted simply ignores the line without generating any error messages and merrily goes on. We found this out when it took us several hours to notice one of our configs hat the word "threshhold" rather than "threshold"... ;{( Since you're running pre-V3 mrouted, the line will be ignored so you won't have a tunnel => you only have one interface. > executing the ifconfig command results in > > > ifconfig le0 > > le0: flags=863 > inet 193.1.66.20 netmask ffffff00 broadcast 193.1.66.0 > ether 8:0:20:19:27:2b Did you install the new ifconfig tool and multicast patches? You need to do so; this should say "" if you installed the multicast extensions properly. Thanks, Mike +--------------------------------------+------------------------------------+ |Mike Newell | The opinions expressed herein are | |NASA Science Internet Network Systems | my own, and do not necessarily | |Sterling Software, Inc. | reflect those of the NSI program, | |MNewell@nsipo.nasa.gov | Sterling Software, NASA, or anyone | |+1-202-434-8954 | else. | +--------------------------------------+------------------------------------+ From list-mgr@ISI.EDU Fri Feb 24 06:45:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 08:43:18 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 08:42:55 -0800 Received: from davinci.gmu.edu ([199.26.254.51]) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 08:42:53 -0800 Received: by davinci.gmu.edu (931110.SGI/930416.SGI.AUTO) for mbone@isi.edu id AA01512; Fri, 24 Feb 95 11:45:32 -0500 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <9502241645.AA01512@davinci.gmu.edu> Subject: Two questions To: mbone Date: Fri, 24 Feb 1995 11:45:30 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 805 The first question is if there is a way to record wb sessions. We have it set up to record nv and vat already. We would like to be able to record wb along with the first two and play them all back synchronized. The second question is if there is an easy way to start these recording sessions. At present the user has to read information from the sd tool and then manually type in everything into the record sessions. This leads to problems with mistyped numbers and such. We wish it to be automatic in the sense that the user has to input as little information as possible to start the recording sessions. Michael -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Fri Feb 24 18:48:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 08:52:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 08:51:24 -0800 Received: from nic.uakom.sk ([192.108.131.12]) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 08:51:18 -0800 Received: by nic.uakom.sk id AA21333 (5.65c/IDA-1.4.4 for mbone@isi.edu); Fri, 24 Feb 1995 17:48:21 +0100 From: Peter Gajdos Message-Id: <199502241648.AA21333@nic.uakom.sk> Subject: Sun & Cisco To: mbone Date: Fri, 24 Feb 1995 17:48:20 +0100 (MET) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 284 Hi all, does anybody have an experience with tunnel between Mrouted3.3 on Sun with SunOS 4.1.3 and Cisco 7010 with IOS 10.2 ? We have running tunnel between Suns and we'd like to move to Cisco at one side. Thank you very much. --Peter PS: Please reply to gajdos@uakom.sk directly From list-mgr@ISI.EDU Fri Feb 24 01:05:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 09:06:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 09:05:45 -0800 Received: from imicilea.cilea.it by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 09:05:42 -0800 Date: Fri, 24 Feb 1995 09:05:42 -0800 Message-Id: <199502241705.AA02403@venera.isi.edu> Received: from uff29c.cilea.it by IMICILEA.CILEA.IT (IBM VM SMTP V2R2) with TCP; Fri, 24 Feb 95 18:00:19 MET X-Sender: calegari@icil64 X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: calegari@cilea.it (Antonio Calegari) Subject: Re: Sun & Cisco We are also very interested too: please reply to the list too Thank you in advance Antonio >Hi all, > >does anybody have an experience with tunnel between Mrouted3.3 on Sun with >SunOS 4.1.3 and Cisco 7010 with IOS 10.2 ? >We have running tunnel between Suns and we'd like to move to Cisco at one >side. > >Thank you very much. > >--Peter > >PS: Please reply to gajdos@uakom.sk directly > Antonio Calegari CILEA From list-mgr@ISI.EDU Fri Feb 24 17:18:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 09:21:54 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 09:21:27 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 09:21:25 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 24 Feb 1995 09:21:23 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 24 Feb 1995 17:18:58 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: mbenson@davinci.gmu.edu (Michael Benson) Cc: mbone Subject: Re: Two questions In-Reply-To: Your message of "Fri, 24 Feb 95 11:45:30 EST." <9502241645.AA01512@davinci.gmu.edu> Date: Fri, 24 Feb 95 17:18:03 +0000 Message-Id: <479.793646283@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >The second question is if there is an easy way to start these >recording sessions. At present the user has to read information >from the sd tool and then manually type in everything into the >record sessions. This leads to problems with mistyped numbers and >such. We wish it to be automatic in the sense that the user has to >input as little information as possible to start the recording >sessions. I've written a version of sd (called sdr) which will allow this. It's in alpha testing right now while I iron out the bugs and add a few more features. Mark From list-mgr@ISI.EDU Fri Feb 24 02:20:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 10:21:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 10:20:57 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 10:20:56 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14649(2)>; Fri, 24 Feb 1995 10:20:37 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Fri, 24 Feb 1995 10:20:25 -0800 X-Mailer: exmh version 1.5.3 12/28/94 To: Hitesh Tewari Cc: mbone Subject: Re: Configuring mrouted In-Reply-To: Your message of "Fri, 24 Feb 95 06:03:50 PST." <199502241404.AA24466@venera.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Feb 1995 10:20:10 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <95Feb24.102025pst.49859@crevenia.parc.xerox.com> In message <199502241404.AA24466@venera.isi.edu> you write: >I am trying to run the mrouted on a SPARC station running SunOS4.13. I get the >following error: > >>mrouted -d >debug level 2 >mrouted $Revision 1.4 $ This is very old. You should get the 3.3 distribution from one of ftp://ftp.parc.xerox.com/pub/net-research/ipmulti3.3-sunos413x.tar.Z ftp://louie.udel.edu/pub/people/ajit/ipmulti3.3-sunos413x.tar.gz ftp://ftp.adelaide.edu.au/pub/av/multicast/ipmulti3.3-sunos413x.tar.Z and follow the instructions in http://www.eit.com/techinfo/mbone/mbone.faq.html at the bottom about how to install the release 3.3 code. Bill From list-mgr@ISI.EDU Fri Feb 24 05:43:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 13:44:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 13:43:58 -0800 Received: from eitech.eit.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Feb 1995 13:43:57 -0800 Received: from collage (collage.eit.COM) by eitech.eit.com (4.1/SMI-4.1) id AA08437; Fri, 24 Feb 95 13:43:33 PST Date: Fri, 24 Feb 95 13:43:33 PST From: vinay@eit.COM (Vinay Kumar) Message-Id: <9502242143.AA08437@eitech.eit.com> To: fenner@parc.xerox.com Subject: Re: Configuring mrouted Cc: Hitesh.Tewari@cs.tcd.ie, mbone Information on multicast kernel patches and other mbone applications can also be found at, http://www.eit.com/techinfo/mbone/software.html Enjoy, --- Vinay Kumar vinay@eit.com MBone Home Page: http://www.eit.com/techinfo/mbone/ > Date: Fri, 24 Feb 1995 10:20:10 PST > Sender: Bill Fenner > From: Bill Fenner > Content-Length: 634 > > In message <199502241404.AA24466@venera.isi.edu> you write: > >I am trying to run the mrouted on a SPARC station running SunOS4.13. I get the > >following error: > > > >>mrouted -d > >debug level 2 > >mrouted $Revision 1.4 $ > > This is very old. You should get the 3.3 distribution from one of > > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti3.3-sunos413x.tar.Z > ftp://louie.udel.edu/pub/people/ajit/ipmulti3.3-sunos413x.tar.gz > ftp://ftp.adelaide.edu.au/pub/av/multicast/ipmulti3.3-sunos413x.tar.Z > > and follow the instructions in http://www.eit.com/techinfo/mbone/mbone.faq.html > at the bottom about how to install the release 3.3 code. > > Bill > > From list-mgr@ISI.EDU Mon Feb 27 04:07:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Feb 1995 14:08:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Feb 1995 14:07:48 -0800 Received: from octavia.anu.edu.au by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Feb 1995 14:07:46 -0800 Received: by octavia.anu.edu.au (4.1/SMI-4.1) id AA29599; Mon, 27 Feb 95 09:07:41 EST Date: Mon, 27 Feb 95 09:07:41 EST From: markus@octavia.anu.edu.au (Markus Buchhorn) Message-Id: <9502262207.AA29599@octavia.anu.edu.au> To: mbone Subject: Re: Two questions Sorry - No answers, just a thought... > The second question is if there is an easy way to start these > recording sessions. At present the user has to read information > from the sd tool and then manually type in everything into the > record sessions. This leads to problems with mistyped numbers and > such. We wish it to be automatic in the sense that the user has to > input as little information as possible to start the recording > sessions. I always thought that this could be done from within 'sd' - just add a 'record session' button a la 'create session'. This could let you choose to record nv/vat/wb (or similar tools) for the selected session. Then you could also add a 'playback recording' option, since at this stage we create a session (in sd) and playback into that session (from the command line). Now, I don't have the source :-) (nor the time :-( ) to hack this myself, but perhaps others may want to leap in .....? Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] From list-mgr@ISI.EDU Sun Feb 26 07:08:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Feb 1995 15:07:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Feb 1995 15:07:18 -0800 Received: from cs.nps.navy.mil by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Feb 1995 15:07:17 -0800 Received: from ac10.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA03189; Sun, 26 Feb 95 15:06:43 PST Date: Sun, 26 Feb 1995 15:08:12 -0800 (PST) From: Michael Macedonia To: mbone Subject: mbone vr test Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We were conducting tests of the NPSNET virtual environment over the mbone the other day and some folks listening in requested how they can get the program. Below is our notice explaining the procedure. BTW, the test went very well. Net latency was about 100 ms between NPS and GMU in VA. We had vehicle models and humans (using the UP Jack library) for a variety of differt locations. In the next couple weeks we are expanding it to several sites. Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ NPSNET-IV.7J has been updated so that it compiles under the new CC version 4 compiler distributed with IRIX 5.3. At the same time, the code was revamped to compile using gcc also. Some bug fixes and enhancements also have taken place. We are calling the new version npsnetIV.7J.1; however, the directory created will still be called npsnetIV.7J. To distinguish between versions, a file called CHANGES.1 will be in the top level directory and will summarize some of the changes from the base version. Also, the README and INSTALL files have been updated to reflect the new version. You do not need to get a new copy of the basic data files or terrain databases if you have done so after Jan. 8, 1995. (i.e. with the official release of npsnetIV.7J) The compressed tar is available using the WWW at URL: http://cs.nps.navy.mil/research/npsnet/distribution/page.html It is also avialable via anonymous ftp from taurus.cs.nps.navy.mil in pub/barham The G++ libraries are not yet available due to unexpected delays from the contributors. These libraries will be supplied as soon as they are available. This delay means that you can completely compile npsnetIV.7J.1 under g++/gcc; however, during the final link, you will receive some unknown symbols. We are sorry for the delay but it is out of our control. Distribution questions, concerns, bug reports, etc. should be send via email to npsnet@cs.nps.navy.mil. A portion of the new README is enclosed below to summarize the changes. ********** MAJOR CHANGES TO RELEASE IV.7J.1 ********** All scripts written using SH. All Makefiles changed to use SH as the shell and to use a top-level include of Makefile.config instead of passing environment variables. New copyright notices in all files. Added additonal casting of types so that code would compile under the new C++ compiler for Irix 5.3. Configuration file option "HMD" now notifies npsnet to set the monitor mode appropriate for the VIM HMD. A load time and a run time is printed in the shell window by npsnet. Fixed network code to correctly pick a default ethernet interface when the one specified by the user or the config file is invalid. Fixed SHIFT+PADENTER so that all smoke plumes are stopped. Can specify which ethernet interface to use for the simulation using the "-a" commmand line argument. Pressing the key "?" will now display the current networking variables being used by the program. Information about the UPD Port, network mode, etc. is displayed in the shell window that started npsnet. Camera locking has been fixed for all terrain and static objects. The addition of a semi-transparent "NPSNET" credit in the center, top of the screen. The current mode display indicator (previously always shown in the lower right corner) can now be disabled along with other text on the left of the screen using the F3 key. pdudisplay now forces zero termination of incoming markings fields. The following DIS options can be set from the command line using the "-d" argument: timeout=, to set when a networked entity should time out. heartbeat=, to set the minimal rate for sending a PDU for an entity. rotdelta=, to set the orientation threshold for sending a PDU. posdelta=, to set the position threshold for send a PDU. exercise=, as an optional way of setting exericse ID along with "-x". Addition of "-w" command line argument to set the initial window size. Usage is -w x=,y= Example -w x=1024,y=1024 Display of DIS exercise ID on the HUD directly above "Spec". Changed behavior of key. No longer saves entire screen image to /tmp. Now only saves the portion of the screen being used by the graphics window to an auto-numbering file in /tmp. The files are named NPSNET_SCREEN.#.rgb when # is replaced by the first available positive integer such that a previous file does not exist with the same name. Saving to /tmp can be overridden by using the environment variable NPS_PIC_DIR. For example, in the C Shell (CSH): setenv NPS_PIC_DIR /usr/people/joe/pics Running npsnet after setting this environment variable would cause screendumps to be saved in the directory: /usr/people/joe/pics. Fixed bug when HDM/tracker was used, eyepoint would "fly away" for all entities other than a human. From list-mgr@ISI.EDU Sun Feb 26 10:43:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Feb 1995 18:43:47 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Feb 1995 18:43:12 -0800 Received: from gumby.dsd.TRW.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Feb 1995 18:43:11 -0800 Received: from localhost.sp.TRW.COM by gumby.dsd.TRW.COM (4.1/SMI-4.1) id AA22739; Sun, 26 Feb 95 18:43:04 PST Message-Id: <9502270243.AA22739@gumby.dsd.TRW.COM> To: mbone Subject: help with MBONE tunnels Date: Sun, 26 Feb 95 18:43:04 -0800 From: Dan Molinelli we've just moved to a FDDI backbone and i'm having problems getting our MBONE tunnels working. i cannot get any MBONE routes out and back from this tunnel to our main MBONE router. i have mrouted 2.2 running on a SUN OS 4.1.3_U1 via our Internet cisco with ip proto 4 allowed from/to our MBONE feed. this machine is working fine; i can see/respond to all MBONE sessions. we've changed our subnet mask to 7 bits, so our MBONE router from the Internet is: 129.4.51.2. i want to feed machines on our subnet: 129.4.53 so i setup a tunnel to a machine on that subnet (129.4.53.11). we're using 3Com's Netbuilders. since our MBONE router (129.4.51.2) is on the FDDI backbone, i have confidence it works. i can see igmp packets via tcpdump -v ip proto igmp opn both subnets. (i have never been able to see multicast packets with tcpdump -v ip multicast though?) ifconfig shows multicast is up and running fine. i see via '-d 9' debugging, i'm getting rec/send route reports. 'map-mbone' from mrouted 2.2 shows our MBONE connections on the main machine (129.4.51.2). but map-mbone shows null from the tunnel machine on 129.4.53. subnet. below is the `-d 9' head debug from mrouted from both hosts. all looks fine. host 129.4.51.2 is our main MBONE router. host 129.4.53.11 is the tunnel machine to our subnet 129.4.53 . i see no problem with them. using MBONE's netstat looks like the tunnel machine is seeing the route reports - but we not able to send them??? (no udp connections from multicastaddresses?) i've reinstalled the IP mulitcasting patches - but no avail. any help or pointers would be appreciated. thanks dan Daniel Molinelli dan.molinelli@trw.com TRW S&EG/ITS Views expressed here are mine. Los Angeles, CA ===== mrouted debug from 129.4.51.2 (main MBONE router) ==== debug level 99 mrouted version 2.2 installing le0 (129.4.51.2 on subnet 129.4.50) as vif #0 installing tunnel from 129.4.51.2 to 128.125.1.14 as vif #1 installing tunnel from 129.4.51.2 to 129.4.53.11 as vif #2 SENT membership query from 129.4.51.2 to 224.0.0.1 SENT neighbor probe from 129.4.51.2 to 224.0.0.4 SENT neighbor probe from 129.4.51.2 to 128.125.1.14 SENT neighbor probe from 129.4.51.2 to 129.4.53.11 Virtual Interface Table Vif Local-Address Metric Thresh Flags 0 129.4.51.2 subnet: 129.4.50 1 1 querier 1 129.4.51.2 tunnel: 128.125.1.14 1 64 2 129.4.51.2 tunnel: 129.4.53.11 1 64 Multicast Routing Table (1 entry) Origin-Subnet From-Gateway Metric In-Vif Out-Vifs 129.4.50 1 0 1* 2* RECV membership report from 129.4.51.2 to 224.0.0.4 RECV membership query from 129.4.51.2 to 224.0.0.1 RECV route report from 129.4.53.11 to 129.4.51.2 SENT route report from 129.4.51.2 to 129.4.53.11 SENT route report from 129.4.51.2 to 129.4.53.11 ====== mrouted debug from host 129.4.53.11 (tunnel subnet 129.4.53) ====== mrouted $Revision: 1.3 $ installing le0 (129.4.53.11 on subnet 129.4.52) as vif #0 installing tunnel from 129.4.53.11 to 129.4.51.2 as vif #1 SENT membership query from 129.4.53.11 to 224.0.0.1 SENT neighbor probe from 129.4.53.11 to 224.0.0.4 SENT neighbor probe from 129.4.53.11 to 129.4.51.2 Virtual Interface Table Vif Local-Address Metric Thresh Flags 0 129.4.53.11 subnet: 129.4.52 1 1 querier 1 129.4.53.11 tunnel: 129.4.51.2 1 64 Multicast Routing Table (1 entry) Origin-Subnet From-Gateway Metric In-Vif Out-Vifs 129.4.52 1 0 1* RECV membership report from 129.4.53.11 to 224.0.0.4 RECV membership query from 129.4.53.11 to 224.0.0.1 RECV route report from 129.4.51.2 to 129.4.53.11 SENT route report from 129.4. From list-mgr@ISI.EDU Mon Feb 27 11:20:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Feb 1995 23:13:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Feb 1995 23:13:26 -0800 Received: from tkyvax.phys.s.u-tokyo.ac.jp by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Feb 1995 23:13:25 -0800 Received: by tkyvax.phys.s.u-tokyo.ac.jp (MX V4.1 VAX) id 21; Mon, 27 Feb 1995 16:20:54 EST Date: Mon, 27 Feb 1995 16:20:54 EST From: ngai3@tkyvax.phys.s.u-tokyo.ac.jp To: mbone Message-Id: <0098C9E6.8F34CD7A.21@tkyvax.phys.s.u-tokyo.ac.jp> Subject: please unsubscribe me Please unsubsribe me. --- Julian Ngai ngai3@tkyvax.phys.s.u-tokyo.ac.jp From list-mgr@ISI.EDU Mon Feb 27 14:29:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 04:30:50 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 04:29:21 -0800 Received: from ncc.ripe.net by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 04:29:19 -0800 Received: from belegen.ripe.net by ncc.ripe.net with SMTP id AA04752 (5.65a/NCC-2.18); Mon, 27 Feb 1995 13:29:07 +0100 Message-Id: <9502271229.AA04752@ncc.ripe.net> To: "Bill Nowicki" Cc: mbone From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: Re: More nits with multicast 3.3 In-Reply-To: Your message of "Wed, 22 Feb 1995 15:11:05 PST." <9502221511.ZM2370@tree.engr.sgi.com> Date: Mon, 27 Feb 1995 13:29:06 +0100 Sender: GeertJan.deGroot@ripe.net On Wed, 22 Feb 1995 15:11:05 -0800 "Bill Nowicki" wrote: > We ran into a few problems with testing the multicast 3.3 code in > IRIX 6.1. The first one is a long-standing bug, which might also be > in other implementations. The problem comes up on multicast routers > with three or more interfaces. Incoming packets are supposed to be > fanned-out to all other interfaces. This is done by calling m_copy > in phyint_send. This then sets imo->imo_multicast_ttl to the > original ttl minus one, and eventually calls ip_output, which > stuffs in the new decremented ttl. I expect to see a couple more of these. Some time ago, I called in some problems at BSDI which would crash when multiple tunnels were set up. Mike Karels found out that there are a number of places where things are done that are unsafe. Example: the multicast code uses the IP length field internally, and does a htons() just before the packet is queued for transmission. However, it then uses the same mbufs to queue to another interface, and uses the (now byte-swapped) length field again, i.e. it would crash because the packet length is way too large.. There are also a number of race conditions and such. Mike made some changes and sent them back to Steve, if I remember correctly. At this time, 3.3 was already out so these changes are not included there. The best I know, these changes are not restricted by BSDI's licensing conditions as they have been sent back to the original developers. Bill, can you make your changes available? I think that these, and Mike's changes, would make the multicast code much more portable.. Thanks, Geert Jan From list-mgr@ISI.EDU Mon Feb 27 15:34:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 07:47:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 07:36:06 -0800 Received: from swan.cl.cam.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 07:35:41 -0800 Received: from ouse.cl.cam.ac.uk (user pb (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Mon, 27 Feb 1995 15:34:56 +0000 X-Uri: X-Face: &@N3QE9h|>f`igFCkZ'a1`z=nNLXb}k>H(79G"V?@!&*yn)uhPBctF1vc}LD'{OA%$bsX+l [wN,I^G8kKj2NFxQrr@1C4QBC]hq5-%ZkV,^Zl/qE<0`zCQ1nM+]-N<^WG[H)]?d)A:L9AF gOU[BjbaY)uBAMz}h!fm^O0# To: rem-conf@es.net, mbone, cypherpunks@toad.com Cc: Piete.Brooks@cl.cam.ac.uk, Graham.Titmus@cl.cam.ac.uk, Ross.Anderson@cl.cam.ac.uk Reply-To: Piete.Brooks@cl.cam.ac.uk Subject: Mbone transmission 95/02/28 16:15-17:15 UTC (cl.cam.ac.uk Security) Date: Mon, 27 Feb 1995 15:34:29 +0000 From: Piete Brooks Message-Id: <"swan.cl.cam.:225770:950227153501"@cl.cam.ac.uk> Two seminars being transmitted this week:- DEFINING CRYPTOGRAPHIC SCHEMES GENERALLY Tue 28 Feb 95 16:15-17:15ish UTC HIGH SECURITY ELECTRONIC CASH (R) Thu 02 Mar 95 16:15-17:15ish UTC If you are not in the UK and wish to listen then please contact pb@cl.cam.ac.uk and give the following information: 1) nearest mrouted 2) whether you want a video as well as an audio feed. Full details are given below for each seminar. Please note that the second seminar is being transmitted from a recoding that will be made on Wednesday because it is being held in a different lecture theatre to usual. The first is meant as a "low key" transmission (without anyone manning the camera, etc). The video will just be of the speaker (slides are likley only be available via the WWW [if she writes them in time :-) ] -- not on the video). *** *** *** *** *** University of Cambridge Computer Laboratory SEMINAR SERIES SPEAKER: Birgit Pfitzmann, University of Hildesheim DATE: 28 February 1995 at 4.15pm (16:15 UTC) PLACE: Room TP4, Computer Laboratory TITLE: DEFINING CRYPTOGRAPHIC SCHEMES GENERALLY It is important to have formal notions of what a cryptographic scheme is, so that there is a clear interface between its designers and users. Most "small" schemes, such as digital signatures, have a satisfactory formal definition; but new kinds of signature scheme (such as fail-stop signatures) each needed a new definition from scratch. New properties could not be defined as additions, and many variants therefore remain without formal definitions. This includes most "large" schemes such as payment systems. This talk discusses approaches to defining cryptographic schemes generally, and gives an overview of a general definition of digital signature schemes. It turns out that signature schemes are best defined by a separation of service, structure, and degree of security, with a service specification in temporal logic. Additional properties of special types of schemes can then be defined in an orthogonal way. Possibilities and problems with applying this approach to other schemes, and the definition of secure multi-party function evaluation, will also be discussed. *** *** *** *** *** This seminar will be multicast (audio and video) on the mbone as part of our multimedia test programme. Further information is available at http://www.cl.cam.ac.uk/mbone/#cl. *** *** *** *** *** University of Cambridge Computer Laboratory SEMINAR SERIES SPEAKER: Birgit Pfitzmann, University of Hildesheim DATE: Wednesday 1st March at 4.15pm [ *NOT* being transmitted live ] TRANSMISSION: Thursday 2nd March at 4.15pm (16:15 UTC) PLACE: Hopkinson Lecture Theatre TITLE: HIGH SECURITY ELECTRONIC CASH Electronic cash means prepaid digital payment systems. An important aspect is high security for all parties concerned, with the least possible requirements that they trust other parties (multi-party security). If one aims at the market of small everyday payments that is currently dominated by cash, then payments are offline and privacy is an important issue. Cryptologic payment protocols with these properties are implemented in CAFE (Conditional Access for Europe), a project sponsored by the European Community. Furthermore, these protocols are less dependent on tamper-resistance than most digital payment systems. The basic devices used in CAFE are so-called electronic wallets, whose outlook is quite similar to pocket calculators or Personal Digital Assistants. Other features are loss tolerance, multiple currencies, and an open architecture. Real hardware systems will be built using technology suitable for mass production, and there will be a field trial on the premises of the European Commission this year. Apart from the particular CAFE features, an overview of existing and emerging electronic cash systems and some of the cryptographic techniques used will be presented. *** *** *** *** *** From list-mgr@ISI.EDU Mon Feb 27 06:28:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 14:35:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 14:35:28 -0800 Received: from agent.com (dumbo.agent.com) by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 14:35:25 -0800 Received: by agent.com (4.1/SMI-4.1) id AA05971; Mon, 27 Feb 95 14:28:37 PST Date: Mon, 27 Feb 95 14:28:37 PST From: fcc@agent.com (Fah-Chun John Cheong) Message-Id: <9502272228.AA05971@agent.com> To: mbone Subject: Request for MBone Tunnel Cc: mbone@sprint.net, randyb@INTERNEX.NET, rberger@INTERNEX.NET We at Agent Computing Inc. wish to join the MBone. Our mrouter is a SunOS-4.1.3 machine with multicast-3.3 kernel patched. The mrouter IP address is: 198.68.126.78 Traceroute suggests that our IP-service provider Internex gets their feed (Internet feed, not MBone) from SprintLink. Can anyone help me establish an MBone tunnel to our domain mrouter ? This is very much needed for an upcoming demo as well. All help will be highly appreciated. Cheers, Fah-Chun fcc@agent.com From list-mgr@ISI.EDU Tue Feb 28 20:27:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 15:20:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 15:20:17 -0800 Received: from christ.acu.EDU.AU by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 15:20:14 -0800 Received: from [192.148.227.72] (P_Mul_LC.mercy.acu.EDU.AU) by christ.acu.edu.au with SMTP id AA07762 (5.65c/IDA-1.3.5/LTU-1.0 for mbone@ISI.EDU); Tue, 28 Feb 1995 10:21:06 -0400 Message-Id: <199502281421.AA07762@christ.acu.edu.au> X-Sender: mul400@christ.acu.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Feb 1995 10:27:32 +1000 To: mbone From: P.Mulready@mercy.acu.edu.au (Pam Mulready) Subject: please unsubscribe me Please unsubsribe me. --- Julian Ngai ngai3@tkyvax.phys.s.u-tokyo.ac.jp / Pamela Mulready / AUSTRALIAN CATHOLIC UNIVERSITY /| /==============================/====================================/_/ / EDUCATIONAL TECHNOLOGY / VICTORIA DIVISION / / / / / / / 251 Mt. Alexander Rd. / P.Mulready@mercy.acu.edu.au / / / Ascot Vale, 3032 / Tel (613) 373 3517 / / / Tel (613)373 3517 / Messagebank 613 506 2600 / / / Fax (613) 373 3420 / Fax (613) 373 3420 / / /______________________________/____________________________________/ / |_____________________________/\____________________________________|/ From list-mgr@ISI.EDU Mon Feb 27 08:12:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 16:13:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 16:12:52 -0800 Received: from cmgm.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 16:12:51 -0800 Received: (gbrand@localhost) by cmgm.Stanford.EDU (8.6.10/8.6.4) id QAA13994 for mbone@isi.edu; Mon, 27 Feb 1995 16:12:50 -0800 From: George Brandetsas Message-Id: <199502280012.QAA13994@cmgm.Stanford.EDU> Subject: unsubscribe To: mbone Date: Mon, 27 Feb 1995 16:12:49 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 22 Please unsubscribe me From list-mgr@ISI.EDU Mon Feb 27 10:36:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 18:41:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 18:40:47 -0800 Received: from paris.ics.uci.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Feb 1995 18:40:46 -0800 Received: from openlab-06.ics.uci.edu by paris.ics.uci.edu id aa24651; 27 Feb 95 18:36 PST To: mbone Subject: Turing Lectures Date: Mon, 27 Feb 1995 18:36:43 -0800 From: Nanda Kutty Message-Id: <9502271836.aa24651@paris.ics.uci.edu> Hi. Will the Turing lectures be broadcast on the mbone ? nanda Irvine, California. From list-mgr@ISI.EDU Tue Feb 28 17:26:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 28 Feb 1995 09:28:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 28 Feb 1995 09:28:25 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 28 Feb 1995 09:28:24 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 28 Feb 1995 09:28:20 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 28 Feb 1995 17:27:51 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: k-hopper@uchicago.edu Cc: mbone Subject: Re: [Q] how to choose a multicast address ? In-Reply-To: Your message of "Thu, 16 Feb 95 10:13:38 CST." <199502161613.KAA04772@heliostat.uchicago.edu> Date: Tue, 28 Feb 95 17:26:49 +0000 Message-Id: <8218.793992409@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk > We are successfully multicasting around our > campus using vic/vat. > > How do we choose an APPROPRIATE multicast > address ? and port ? for campus > experimentation ? > > We have set our ttl down as low as possible ( > 64 seems to work O.K.) to be good network > citizens, but the choice of 230.2.230.99/33298 > was arbitrary. Is there a proper algorithm to > use ? I didn't see any reply to your message (I was just working through my mail backlog). The simplest way to do address allocation is to use sd, which will choose and address for you. If you want to choose one yourself, for conferencing it should strictly be 224.2.*.* because that's what IANA allocated for mmconferencing, though no-one's really too bothered right now. The port is arbitrary (so long as it's above 1024). The ttl scopes generally in use are: threshold scope suggested ttl with stay in scope <16 site 15 48 region 47 64 continent 63 128 world 127 192 lo-rate 191 Thus you should be using thresholds of 1 between your mrouted's within your site and then send with a ttl of 15 for local traffic. Mark From list-mgr@ISI.EDU Thu Mar 2 07:09:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 1 Mar 1995 01:03:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 1 Mar 1995 01:01:34 -0800 Received: from oznet02.ozemail.com.au by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 1 Mar 1995 01:01:30 -0800 Received: from ozemail.com.au (cerebus.ozemail.com.au [203.2.194.97]) by oznet02.ozemail.com.au (8.6.10/8.6.5) with SMTP id UAA19160 for ; Wed, 1 Mar 1995 20:00:47 +1100 Received: from NetWare MHS (SMF70) by ozemail.com.au via C2SMTP 3.19.b10E MHS to SMTP Gateway; Wed, 1 Mar 95 19:56:17 +1100 Message-Id: <1995MAR1.11382@ozemail.com.au> Date: Wed, 1 Mar 95 20:09:02 +1100 From: "OLLENCIO D'SOUZA" Sender: "OLLENCIO D'SOUZA" Return-Receipt-To: Organization: OzEmail Pty Ltd To: rem-conf@net.es, mbone, ross.anderson@cl.cam.ac.uk, piete.brooks@cl.cam.ac.uk (Piete.Brooks), graham.titmus@cl.cam.ac.uk Subject: Re: Mbone transmission 94/12/05 16:15-17:15 UTC (cl.cam.ac.uk Security) X-Mailer: Connect2-SMTP 3.19.b10E MHS to SMTP Gateway Piete Brooks, I am interested in receiving a test feed if possible. Would you give me some information on how? I am still on the Dos/Windows platform (NETSCAPE WWW) but wish to gear up to do some experiments on the MBONE. I'd appreciate your help. Regards Olly From list-mgr@ISI.EDU Wed Mar 1 17:46:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 1 Mar 1995 09:51:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 1 Mar 1995 09:51:09 -0800 Received: from louie.udel.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 1 Mar 1995 09:51:08 -0800 Received: from snow-white-fddi.udel.edu by louie.udel.edu id ab06830; 1 Mar 95 12:48 EST Received: from louie.udel.edu by snow-white.ee.udel.edu id aa27494; 1 Mar 95 12:47 EST Received: from snow-white.ee.udel.edu by beauregard.udel.edu id aa06514; 1 Mar 95 17:46 GMT To: mbone Cc: huffman@eecis.udel.edu Subject: FDDI object modules on HP machines. Date: Wed, 01 Mar 1995 17:46:07 +0000 From: Ajit Thyagarajan Message-Id: <9503011746.aa06514@beauregard.udel.edu> We are trying to enable multicast on a HP workstation which has a FDDI and an Ethernet interface. We can get multicast to work on the Ethernet, but our object modules for FDDI dont seem to have multicast compiled in them. Atleast, if we try and build a kernel with those object modules compiled, multicast doesn't work on either interface! Does anyone know if there are FDDI object modules with multicast compiled for HP machines? We are trying to enable multicast on a 9.0.1 kernel. Thanks, Ajit Thyagarajan From list-mgr@ISI.EDU Wed Mar 1 13:36:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 1 Mar 1995 15:34:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 1 Mar 1995 15:34:21 -0800 Received: from FARNSWORTH.MIT.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 1 Mar 1995 15:34:19 -0800 Received: from localhost by farnsworth.mit.edu with SMTP id AA10970; Wed, 1 Mar 1995 18:36:10 -0500 Message-Id: <9503012336.AA10970@farnsworth.mit.edu> To: rem-conf@es.net, mbone, nomad@farnsworth.mit.edu Subject: Internet Economics Workshop Date: Wed, 01 Mar 95 18:36:04 -0500 From: bailey@farnsworth.mit.edu X-Mts: smtp To whom it may concern: We at the Research Program on Communications Policy will hold a meeting at MIT on March 9th and 10th from 9am to 5:30pm (Eastern time) on Thurs. and 9am to 4:30pm (Eastern time) on Friday. We hope to broadcast this workshop over the Internet via MBONE. We have already secured the equipment and were given the green light by MITnet to proceed. They have been helping us with the connection to the Internet cloud. However, it has just been brought to my attention that you need to be alerted to our intentions. I'm sorry for the late notification. Please let me know if there are any specific questions you may have. Thanks. --Joe Bailey From list-mgr@ISI.EDU Thu Mar 2 14:56:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 2 Mar 1995 07:29:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 2 Mar 1995 07:28:54 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 2 Mar 1995 07:28:53 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 2 Mar 1995 07:28:49 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 2 Mar 1995 14:56:27 +0000 To: mbone Subject: _The_ mbone audio session has gone Date: Thu, 02 Mar 95 14:56:23 +0000 Message-Id: <1994.794156183@cs.ucl.ac.uk> From: Jon Crowcroft what happened? the session (default vat address/port etc) is no longer announced - its like someone turned off MTV, except less useful:-) Is Van/LBL still on the map? cheers jon From list-mgr@ISI.EDU Thu Mar 2 11:54:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 2 Mar 1995 15:54:54 -0800 Received: from everest.cclabs.missouri.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 2 Mar 1995 15:54:52 -0800 Received: from sgi11.phlab.missouri.edu (sgi11.phlab.missouri.edu [128.206.115.41]) by everest.cclabs.missouri.edu (8.6.10/8.6.6-Arete-2) with SMTP id RAA08012 for ; Thu, 2 Mar 1995 17:54:51 -0600 Date: Thu, 2 Mar 1995 17:54:51 -0600 (CST) From: "Paul 'Shag' Walmsley" X-Sender: ccshag@sgi11.phlab.missouri.edu To: mbone-na Subject: Trouble configuring mrouted 2.2 on IRIX 5.2 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Essentially, I can't associate a non-standard metric and/or threshold with a tunnel without mrouted completely ignoring that tunnel on startup. For example, if I have the line tunnel 1.2.3.4 4.5.6.7 ... the tunnel comes up fine, but if I use tunnel 1.2.3.4 4.5.6.7 1 32 or even just tunnel 1.2.3.4 4.5.6.7 1 1 - the tunnel refuses to come up. If I do a mrouted -d 3, it isn't even listed in the output. Can anybody clue me in on a fix for this? - Paul "Shag" Walmsley "I'll drink a toast to bold evolution any day!" From list-mgr@ISI.EDU Thu Mar 2 09:17:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 2 Mar 1995 17:17:53 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 2 Mar 1995 17:17:51 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14566(5)>; Thu, 2 Mar 1995 17:17:43 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Thu, 2 Mar 1995 17:17:39 -0800 X-Mailer: exmh version 1.5.3 12/28/94 From: Bill Fenner To: "Paul 'Shag' Walmsley" Cc: mbone-na Subject: Re: Trouble configuring mrouted 2.2 on IRIX 5.2 In-Reply-To: Your message of "Thu, 02 Mar 95 15:54:51 PST." Message-Id: <95Mar2.171739pst.49859@crevenia.parc.xerox.com> Date: Thu, 2 Mar 1995 17:17:37 PST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 Mar 95 17:17:37 -0800 From: Bill Fenner In message you write: >if I use > >tunnel 1.2.3.4 4.5.6.7 1 32 > >- the tunnel refuses to come up. Try tunnel 1.2.3.4 4.5.6.7 metric 1 threshold 32 the mrouted.conf parsing has been much improved in the upcoming 3.4 release. Bill From list-mgr@ISI.EDU Thu Mar 2 12:39:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 2 Mar 1995 18:40:27 -0800 Received: from LPL.Arizona.EDU (hindmost.LPL.Arizona.EDU) by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 2 Mar 1995 18:40:25 -0800 Received: from seds.LPL.Arizona.EDU by LPL.Arizona.EDU (4.1/SMI-4.1) id AA05720; Thu, 2 Mar 95 19:40:24 MST Received: by seds.LPL.Arizona.EDU (5.x/SMI-SVR4) id AA27431; Thu, 2 Mar 1995 19:39:46 -0700 Date: Thu, 2 Mar 1995 19:39:46 -0700 (MST) From: Chris Lewicki X-Sender: chrisl@seds To: mbone-na Subject: New to the 'bone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello all, I'm not sure I'm subscribed to this list yet, but the independent people I've been contacting have told me I should post to the list. Here's the case: I've got a Sparcstation 10Sx, running Solaris 2.4 and mrouted 2.2 built from the source. I've retrieved sd, nv, vat, wb and all that from ftp.ee.lbl.gov, and verified that those do indeed work within the domain. What I don't understand, though, is why I'm not seeing anyone else out there. Like the (sparse) documentation says, I loaded up sd, waited a minute, then two, then five, then ten, etc... and nothing shows up. I've contacted sprint (our network provider) and had them direct a tunnel my way, and that appears to be working, but from talking with someone, it appears that I may only have a "route" and not necessarily a "feed." My mrouted.conf has this in it: tunnel 128.196.64.66 144.228.8.227 metric 1 threshold 64 and my ethernet interface is configured to multicast (ifconfig -a): le0: flags=863 mtu 1500 and mrouted does appear to be talking about something with sprint: seds:[626] /root/bin # mrouted -d 3 debug level 3 mrouted version 2.2 installing le0 (128.196.64.66 on subnet 128.196.64) as vif #0 installing tunnel from 128.196.64.66 to 144.228.8.227 as vif #1 SENT membership query from 128.196.64.66 to 224.0.0.1 SENT neighbor probe from 128.196.64.66 to 224.0.0.4 SENT neighbor probe from 128.196.64.66 to 144.228.8.227 Virtual Interface Table Vif Local-Address Metric Thresh Flags 0 128.196.64.66 subnet: 128.196.64 1 1 querier 1 128.196.64.66 tunnel: 144.228.8.227 1 64 Multicast Routing Table (1 entry) Origin-Subnet From-Gateway Metric In-Vif Out-Vifs 128.196.64 1 0 1* RECV membership query from 128.196.64.66 to 224.0.0.1 RECV membership query from 128.196.64.66 to 224.0.0.1 RECV route report from 144.228.8.227 to 128.196.64.66 SENT route report from 128.196.64.66 to 144.228.8.227 SENT route report from 128.196.64.66 to 144.228.8.227 and if it matters, my route to ns2.sprintlink.net is: 1 Butch-LPL-NET.Telcom.Arizona.EDU (128.196.64.253) 3 ms 2 ms 2 ms 2 Gabby.Telcom.Arizona.EDU (128.196.128.1) 4 ms 4 ms 4 ms 3 Westgate.Telcom.Arizona.EDU (192.80.43.2) 3 ms 4 ms 4 ms 4 sl-ana-3-S1/0-T1.sprintlink.net (144.228.73.25) 17 ms 28 ms 16 ms 5 sl-ana-2-F0/0.sprintlink.net (144.228.70.2) 29 ms 16 ms 18 ms 6 sl-stk-6-H2/0-T3.sprintlink.net (144.228.10.25) 24 ms 28 ms 24 ms 7 ns2.sprintlink.net (199.2.252.10) 65 ms 26 ms 30 ms (I think the first is a Cisco router) ...but still nothing. I think I've read everything out there, so does anyone have any insight as to what my problem might be? As I said, I may not be on the list yet, so please post replies directly to this address. ------------------------------------------------------------------------------ Christopher A. Lewicki + (602) 621-4662 + Maintainer of SEDS.LPL.Arizona.EDU Near Earth Asteroid Rendezvous (NEAR) XRS/GRS Team UA SEDS President SEDS-USA Director of Special Projects *** Brother, can you spare a 2.2 Gig Scsi-II Hard Drive? (Seriously!) *** From list-mgr@ISI.EDU Fri Mar 3 03:47:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 3 Mar 1995 07:50:58 -0800 Received: from fnal.fnal.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 3 Mar 1995 07:50:56 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HNP13MJEZ400C2EJ@FNAL.FNAL.GOV>; Fri, 03 Mar 1995 09:48:55 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA01146; Fri, 3 Mar 95 09:47:56 CST Date: Fri, 03 Mar 1995 09:47:56 -0600 From: Matt Crawford Subject: Re: New to the 'bone In-Reply-To: Your message of Thu, 02 Mar 95 19:39:46 MST. Sender: crawdad@munin.fnal.gov To: Chris Lewicki Cc: mbone-na Message-Id: <9503031547.AA01146@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{; Fri, 3 Mar 1995 07:53:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 3 Mar 1995 07:52:58 -0800 Received: from davinci.gmu.edu ([199.26.254.51]) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 3 Mar 1995 07:52:56 -0800 Received: by davinci.gmu.edu (931110.SGI/930416.SGI.AUTO) for mbone@isi.edu id AA11936; Fri, 3 Mar 95 10:55:38 -0500 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <9503031555.AA11936@davinci.gmu.edu> Subject: Status of vat,nv,wb for PC/MAC To: mbone Date: Fri, 3 Mar 1995 10:55:36 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 385 Does anyone know the current status of vat,nv,wb,etc. for the PC? I know that there are packages out there now that allow the PC to mutlicast but don't know how far along the mbone tools are. Michael -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Fri Mar 3 10:50:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 3 Mar 1995 12:48:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 3 Mar 1995 12:48:01 -0800 Received: from davinci.gmu.edu ([199.26.254.51]) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 3 Mar 1995 12:47:57 -0800 Received: by davinci.gmu.edu (931110.SGI/930416.SGI.AUTO) for mbone@isi.edu id AA12599; Fri, 3 Mar 95 15:50:16 -0500 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <9503032050.AA12599@davinci.gmu.edu> Subject: Possible multicasting on PC To: vinay@eit.com Date: Fri, 3 Mar 1995 15:50:14 -0500 (EST) Cc: mbone X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 593 Several people have asked for information on a product that supports mutlicasting on the PC. I have no experience with this product nor any relationship to the company. Perhaps someone else has some experience with it. Anyway here is the information. > > TGV has a new windows tcp/ip product that supports multicast. You can > contact sales@tgv.com (1 800 848-3440). > ----- End Included Message ----- -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Fri Mar 3 06:54:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 3 Mar 1995 14:55:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 3 Mar 1995 14:54:26 -0800 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 3 Mar 1995 14:54:24 -0800 Received: from icsib77.ICSI.Berkeley.EDU (whd@icsib77.ICSI.Berkeley.EDU [128.32.201.203]) by icsia.ICSI.Berkeley.EDU (8.6.10/HUB+V8$Revision: 1.22 $) with ESMTP id OAA28972; Fri, 3 Mar 1995 14:54:18 -0800 From: whd@ICSI.Berkeley.EDU (Wieland Holfelder) Received: (whd@localhost) by icsib77.ICSI.Berkeley.EDU (8.6.10/1.8) id OAA02607; Fri, 3 Mar 1995 14:54:14 -0800 Message-Id: <199503032254.OAA02607@icsib77.ICSI.Berkeley.EDU> Subject: wb/receive only/solaris To: mbone (Multicast Backbone) Date: Fri, 3 Mar 1995 14:54:12 -0800 (PST) Cc: wb@ee.lbl.gov X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1170 There was this discussion going on about wb crashing on Solaris a couple days ago. I'd like to put my $0.02 into this discussion. I just found out, that wb (wb version 1.59 on a SS10 with Solaris 2.4) actually only crashes (with a core dump), if one specify a ttl with -t on the commandline!? If I start wb without specifying a ttl (which defaults to 16) I can switch back an forth between receive only and send mode. Since wb is started with a "-t" flag anytime you start it from sd no matter what value the actual ttl has, wb crashes always when one trys to switch the receive only mode. Because this only happens when one *do* specify a ttl I guess it might be a bug in wb? But maybe it just happens then and it is in fact a bug in Solaris? -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder International Computer Science Institute Email: whd@icsi.berkeley.edu 1947 Center Street Suite 600 Fax : +1-510-642-6865 Berkeley, CA 94704-1198 Phone: +1-510-642-4274 Ext. 302 URL: http://www.icsi.berkeley.edu/~whd ------------------------------------------------------------------------------- From list-mgr@ISI.EDU Sat Mar 4 09:15:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 4 Mar 1995 09:17:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 4 Mar 1995 09:14:24 -0800 Received: from degaulle.hil.unb.ca by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 4 Mar 1995 09:14:21 -0800 Received: (spencer@localhost) by DeGaulle.hil.unb.ca (8.6.10/8.6.5) id NAA17684; Sat, 4 Mar 1995 13:15:19 -0400 Date: Sat, 4 Mar 1995 13:15:18 -0400 (AST) From: "Dwight E. Spencer" X-Sender: spencer@DeGaulle To: Wieland Holfelder Cc: Multicast Backbone , wb@ee.lbl.gov Subject: Re: wb/receive only/solaris In-Reply-To: <199503032254.OAA02607@icsib77.ICSI.Berkeley.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 3 Mar 1995, Wieland Holfelder wrote: > I just found out, that wb (wb version 1.59 on a SS10 with Solaris 2.4) > actually only crashes (with a core dump), if one specify a ttl with -t > Because this only happens when one *do* specify a ttl I guess it might > be a bug in wb? But maybe it just happens then and it is in fact a bug > in Solaris? > > -- Wieland I've been using wb (started from sd, with a ttl specified) on a ss20m with solaris 2.3 for about 5 months now. No problems. Of course I don't use it that much, but I'll try some tests with it. dwight. ------------------------------------------------------------------------------ Dwight E. Spencer University of New Brunswick Email: spencer@unb.ca, dwight@www.unb.ca Http://www.unb.ca/staff/dspencer.html Computing Services Department ..... Phone: (506) 453 4573 Harriet Irving Library ............. (506) 453 4740 (ext. 6889) University of New Brunswick WWW Project: ........ Email to: www@www.unb.ca From list-mgr@ISI.EDU Mon Mar 6 11:02:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 08:12:14 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 08:11:54 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 08:11:53 -0800 Received: from ceres.fokus.gmd.de by quark.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Mar 1995 01:07:04 -0800 Message-Id: <199503060907.AA07218@quark.isi.edu> Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Mon, 6 Mar 1995 10:02:46 +0100 X-Mailer: exmh version 1.5.3 12/28/94 To: mbone Subject: Talk: QOS in High-Speed Networks Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Mar 1995 10:02:28 +0100 From: Henning Schulzrinne We will be attempting an MBONE broadcast of the following talk. Due to the time of day, we'll limit TTL to intra-Europe. If you are up already and would like to get the ttl raised (or lowered, due to conflicts), please let me know. The talk will be distributed using RTP for both audio and video (nevot and vic). Sorry for the short notice - the talk was somewhat of a surprise to us as well... Date: Monday, March 6, 1995 Time: 14:00 Central European Time, 1300h GMT, 800h EST, 500h PST Analysis and Design Issues for Quality of Service in High Speed Networks Yannis Viniotis North Carolina State University High speed network applications pose a variety of QoS requirements on the ATM network, such as, for example, delay guarantees, small delay variations, small cell loss rates, etc. In the first part of this talk we address the issue of QoS analysis: given a network control (such as link scheduling, call admission, buffer management, etc) we determine what kind of QoS can be achieved, for given network loads. Feasibility results of this type are known as conservation laws. We then use these results to address a design issue: given a desired level of QoS, we develop control algorithms that are proven to satisfy the given quality of service requirement. The implementation aspects of such algorithms are discussed; fast heuristics with good, predictable performance are also identified, for situations where speed of execution is critical. ---- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 182 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin URL: http://www.fokus.gmd.de/htbin/info/step/hgs From list-mgr@ISI.EDU Mon Mar 6 14:08:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 08:11:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 08:10:04 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 08:10:03 -0800 Received: from ceres.fokus.gmd.de by quark.isi.edu (5.65c/5.61+local-20) id ; Mon, 6 Mar 1995 04:10:58 -0800 Message-Id: <199503061210.AA14522@quark.isi.edu> Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Mon, 6 Mar 1995 13:08:25 +0100 X-Mailer: exmh version 1.5.3 12/28/94 To: mbone From: Henning Schulzrinne Subject: MBONE transmission: Prof. Viniotis on QOS for HSN Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Mar 1995 13:08:06 +0100 Sender: schulzrinne@fokus.gmd.de Date: March 6, 1995 (today) Time: 1400h CET, 1300 GMT, 800 EST Scope: Europe (unless somebody wants it lowered/raised) Format: audio (RTP using nevot), video (vic) Sorry for the late announcement; apparently my mailer swallowed an earlier version. We may make a recording as well. Analysis and Design Issues for Quality of Service in High Speed Networks Yannis Viniotis North Carolina State University High speed network applications pose a variety of QoS requirements on the ATM network, such as, for example, delay guarantees, small delay variations, small cell loss rates, etc. In the first part of this talk we address the issue of QoS analysis: given a network control (such as link scheduling, call admission, buffer management, etc) we determine what kind of QoS can be achieved, for given network loads. Feasibility results of this type are known as conservation laws. We then use these results to address a design issue: given a desired level of QoS, we develop control algorithms that are proven to satisfy the given quality of service requirement. The implementation aspects of such algorithms are discussed; fast heuristics with good, predictable performance are also identified, for situations where speed of execution is critical. From list-mgr@ISI.EDU Mon Mar 6 08:16:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 10:19:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 10:18:42 -0800 Received: from ftp.com by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 10:18:41 -0800 Received: from ftp.com by ftp.com ; Mon, 6 Mar 1995 13:18:30 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 6 Mar 1995 13:18:30 -0500 Received: from solensky.beehive.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA08125; Mon, 6 Mar 95 13:16:42 EST Date: Mon, 6 Mar 95 13:16:42 EST Message-Id: <9503061816.AA08125@mailserv-D.ftp.com> To: mbenson@davinci.gmu.edu Subject: Re: Possible multicasting on PC From: solensky@ftp.com (Frank T Solensky) Cc: vinay@eit.com, mbone Sender: solensky@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Mon Mar 6 13:16:30 1995] Originating-Client: beehive.ftp.com Content-Length: 647 > From: mbenson@davinci.gmu.edu (Michael Benson) > Date: Fri, 3 Mar 1995 15:50:14 -0500 (EST) > > Several people have asked for information on a product that supports > mutlicasting on the PC. I have no experience with this product nor any > relationship to the company. Perhaps someone else has some experience > with it. Anyway here is the information. > > > > > TGV has a new windows tcp/ip product that supports multicast. You can > > contact sales@tgv.com (1 800 848-3440). > > ----- End Included Message ----- Another is FTP Software. Sales phone # is 1-800-282-4FTP (4387); email is 'sales@ftp.com'. I'm partisan. -- Frank From list-mgr@ISI.EDU Mon Mar 6 02:42:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 10:40:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 10:40:06 -0800 Received: from feta.cisco.com by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 10:40:05 -0800 Received: from [171.69.60.153] (sphillips-mac.cisco.com [171.69.60.153]) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA11435; Mon, 6 Mar 1995 10:39:28 -0800 X-Sender: stu@feta.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 6 Mar 1995 10:42:06 -0800 To: solensky@ftp.com (Frank T Solensky), mbenson@davinci.gmu.edu From: stu@cisco.com (Stu Phillips) Subject: Re: Possible multicasting on PC Cc: vinay@eit.com, mbone At 10:16 AM 3/6/95, Frank T Solensky wrote: >> From: mbenson@davinci.gmu.edu (Michael Benson) >> Date: Fri, 3 Mar 1995 15:50:14 -0500 (EST) >> >> Several people have asked for information on a product that supports >> mutlicasting on the PC. I have no experience with this product nor any >> relationship to the company. Perhaps someone else has some experience >> with it. Anyway here is the information. >> >> > >> > TGV has a new windows tcp/ip product that supports multicast. You can >> > contact sales@tgv.com (1 800 848-3440). >> > ----- End Included Message ----- > >Another is FTP Software. Sales phone # is 1-800-282-4FTP (4387); >email is 'sales@ftp.com'. > And finally there is the Microsoft Wolverine TCP/IP stack that is the common technology for Windows for Workgroups, Windows 95 (be nice!), and Windows NT.... all support IP Multicasting via IGMP and the Berkeley style socket extensions. I've tried this version and it works fine. Stu From list-mgr@ISI.EDU Mon Mar 6 21:27:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 13:28:45 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 13:28:30 -0800 Received: from ashe.cs.tcd.ie by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 13:28:26 -0800 Message-Id: <199503062128.AA21310@venera.isi.edu> Received: from localhost by ashe.cs.tcd.ie with SMTP (PP) id <03833-0@ashe.cs.tcd.ie>; Mon, 6 Mar 1995 21:28:11 +0000 To: mbone Subject: vat Date: Mon, 06 Mar 1995 21:27:58 +0000 From: Hitesh Tewari Hi, I have just reconfigured the kernel on a second machine in our lab and all seems to have gone fine. I am looking at a good video feed using the 'nv' tool. But I am having terrible problems trying to launch the 'vat' tool. I have copied the binaries from the original system to the new one. The system hangs for a while and then comes back with the following error: > vat: unknown host 'medlicott' medlicott is the name of the new machine. Yet if I use the old (slower) machine 'vat' runs without a hitch. Any ideas as to what I am missing or doing worng. Hitesh. ------- Hitesh Tewari Trinity College Dublin 353-1-702-1542 htewari@cs.tcd.ie From list-mgr@ISI.EDU Mon Mar 6 23:10:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 15:13:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 15:12:53 -0800 Received: from swan.cl.cam.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 15:12:36 -0800 Received: from smew.cl.cam.ac.uk (user pb (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Mon, 6 Mar 1995 23:10:33 +0000 To: rem-conf@es.net, mbone Cc: Piete.Brooks@cl.cam.ac.uk, Graham.Titmus@cl.cam.ac.uk, Ross.Anderson@cl.cam.ac.uk Subject: Mbone transmission 95/03/06 16:15-17:15 UTC (cl.cam.ac.uk Security) X-Uri: X-Face: &@N3QE9h|>f`igFCkZ'a1`z=nNLXb}k>H(79G"V?@!&*yn)uhPBctF1vc}LD'{OA%$bsX+l [wN,I^G8kKj2NFxQrr@1C4QBC]hq5-%ZkV,^Zl/qE<0`zCQ1nM+]-N<^WG[H)]?d)A:L9AF gOU[BjbaY)uBAMz}h!fm^O0# Date: Mon, 06 Mar 1995 23:10:23 +0000 From: Piete Brooks Message-Id: <"swan.cl.cam.:078170:950306231037"@cl.cam.ac.uk> Back to one "low key" seminar this week If you are not in the UK and wish to listen then please contact pb@cl.cam.ac.uk giving your nearest mrouted & whether you want a video as well as an audio feed *** *** *** *** *** University of Cambridge Computer Laboratory SEMINAR SERIES SPEAKER: Kenny Paterson, Royal Holloway, University of london DATE: Tuesday 7th March at 4.15pm PLACE: Room TP4, Computer Laboratory TITLE: THE DISCRETE FOURIER TRANSFORM AND LINEAR COMPLEXITY Nonlinear filtering of m-sequences is a popular way of obtaining keystream sequences for stream ciphers. When carefully applied, the method yields sequences with high periods, good local statistics and high linear complexity. Here, we apply the Discrete Fourier Transform technique of Massey and Serconek to the nonlinear filtering of m-sequences, and derive Rueppel's root presence test in a new and transparent way. The test's application is extended to exhibit a large class of filtering functions having a good lower bound on the linear complexity of their output sequences. *** *** *** *** *** This seminar will be multicast (audio and video) on the mbone as part of our multimedia test programme. Further information is available at http://www.cl.cam.ac.uk/mbone/#cl. From list-mgr@ISI.EDU Mon Mar 6 16:07:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 16:07:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 16:06:29 -0800 Received: from degaulle.hil.unb.ca by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 16:06:26 -0800 Received: (spencer@localhost) by DeGaulle.hil.unb.ca (8.6.10/8.6.5) id UAA02879; Mon, 6 Mar 1995 20:07:21 -0400 Date: Mon, 6 Mar 1995 20:07:21 -0400 (AST) From: "Dwight E. Spencer" X-Sender: spencer@DeGaulle To: Hitesh Tewari Cc: mbone Subject: Re: vat In-Reply-To: <199503062128.AA21310@venera.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 6 Mar 1995, Hitesh Tewari wrote: > copied the binaries from the original system to the new one. The system hangs > for a while and then comes back with the following error: > > > vat: unknown host 'medlicott' > > > medlicott is the name of the new machine. I had a similar problem, and I had put the name in the nameserver, as follows: This machine, with it's full name `hostname`.`domainname` (medlicott.cs.tcd.ie?) I believe must be in a nameserver for vat to do the nslookup on it's host. that, or perhaps put your hole name in your /etc/hosts (I"m not sure if I tried this or not now): your.ip.addr localhost medlicott medlicott.blah.blah dwight ------------------------------------------------------------------------------ Dwight E. Spencer University of New Brunswick Email: spencer@unb.ca, dwight@www.unb.ca Http://www.unb.ca/staff/dspencer.html Computing Services Department ..... Phone: (506) 453 4573 Harriet Irving Library ............. (506) 453 4740 (ext. 6889) University of New Brunswick WWW Project: ........ Email to: www@www.unb.ca From list-mgr@ISI.EDU Wed Mar 8 01:53:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 20:57:00 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 20:55:43 -0800 Received: from peladon.rmit.EDU.AU by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 6 Mar 1995 20:54:58 -0800 Received: from exxilon.xx.rmit.EDU.AU by peladon.rmit.EDU.AU with SMTP id AA11290 (5.65c/IDA-1.4.4 for ); Tue, 7 Mar 1995 15:53:57 +1100 Received: (richard@localhost) by exxilon.xx.rmit.EDU.AU (8.6.10/8.6.4/ram5) id PAA16939; Tue, 7 Mar 1995 15:53:18 +1000 From: "Richard A. Muirden" Message-Id: <199503070553.PAA16939@exxilon.xx.rmit.EDU.AU> Subject: CU-SeeMe Survey - please fill in To: cu-seeme-announce-l@cornell.edu, rem-conf@es.net, mbone, aiwg-mbone@aarnet.edu.au Date: Tue, 7 Mar 1995 15:53:18 +1000 (EST) Cc: ajp@RMIT.EDU.AU X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2178 Hello. [ I'm sorry if this isn't totally relevant to some readers of these lists but I wanted to get as many respondants as possible and catch as many users of CU-SeeMe as possible. Apologies for the distribution if you feel it is incorrect ] I am investigating Audio and Video usage on the internet for a paper and would apprieciate it if you could spend a minute or two to answer these few questions. Questions apply to users of the CU-SeeMe program on the internet. Responses will help to determine a general usage level as well as possibilities for the future. Thank you in advance. -Richard --------------------------------------------------------------------------- All you need do is place an 'X' in the spot that best fits your answer to the question. You can simply reply to this post, or submit via email to richard@rmit.EDU.AU. Question 1: How often would you say you use CU-SeeMe? [ ] Every day [ ] A few times a week [ ] At least once a month [ ] When I am bored [ ] When I hear something good is on [ ] Rarely Question 2: How much time would you spend per session? [ ] less than 1 hour [ ] 1 hour [ ] 2 hours [ ] 3 hours [ ] 4 or more hours Question 3: Do you SEND video/audio on a regular basis? [ ] Yes [ ] No Question 4: Do you connect to an international reflector (ie: cornell) or a local site? [ ] Sometimes [ ] All the time [ ] Never (if you answered anything but 'never' to Question 4) Question 5: If CU-SeeMe reflectors were linked up would you use a local reflector to connect to to save bandwidth? [ ] Yes [ ] No Question 6: When you use CU-SeeMe do you ever consider issues such as Network usage and loading, and bandwidth considerations? [ ] Yes [ ] No Thank you for participating! -- Richard A. Muirden, Sys. Admin |Fan of Shostakovich, "Star Trek" and the Boeing Mailto: richard@rmit.EDU.AU |777 (launch: May 15, 1995 - United Airlines). Phone: (+61 3) 660 3814 |I created alt.fan.shostakovich! Fly: UA,AN,WN http://www.rmit.edu.au/richard |Can *YOU* beat my 106 Shost CD's? :-) * 1995: Remembering 20 years since the death of Shostakovich (1906-75) * From list-mgr@ISI.EDU Tue Mar 7 08:35:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 00:40:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 00:39:43 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 00:39:42 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 7 Mar 1995 00:39:39 -0800 Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 7 Mar 1995 08:35:37 +0000 To: stu@cisco.com (Stu Phillips) Cc: solensky@ftp.com (Frank T Solensky), mbenson@davinci.gmu.edu, vinay@eit.com, mbone Subject: Re: Possible multicasting on PC In-Reply-To: Your message of "Mon, 06 Mar 95 10:42:06 PST." Date: Tue, 07 Mar 95 08:35:29 +0000 Message-Id: <1179.794565329@cs.ucl.ac.uk> From: Jon Crowcroft beware minor differences in the multicast socket() semantics in the different stacks below - these caught us out working on RTP based applications - in particular, the confusion over what bind() and connect() do on multicast UDP sockets... >At 10:16 AM 3/6/95, Frank T Solensky wrote: >>> From: mbenson@davinci.gmu.edu (Michael Benson) >>> Date: Fri, 3 Mar 1995 15:50:14 -0500 (EST) >>> >>> Several people have asked for information on a product that supports >>> mutlicasting on the PC. I have no experience with this product nor any >>> relationship to the company. Perhaps someone else has some experience >>> with it. Anyway here is the information. >>> >>> > >>> > TGV has a new windows tcp/ip product that supports multicast. You can >>> > contact sales@tgv.com (1 800 848-3440). >>> > ----- End Included Message ----- >> >>Another is FTP Software. Sales phone # is 1-800-282-4FTP (4387); >>email is 'sales@ftp.com'. >> > >And finally there is the Microsoft Wolverine TCP/IP stack that is the >common technology for Windows for Workgroups, Windows 95 (be nice!), and >Windows NT.... all support IP Multicasting via IGMP and the Berkeley style >socket extensions. > >I've tried this version and it works fine. > >Stu > > jon From list-mgr@ISI.EDU Wed Mar 8 09:48:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 05:52:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 05:49:00 -0800 Received: from vitruvius.arbld.unimelb.EDU.AU by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 05:48:56 -0800 Received: (darrenr@localhost) by vitruvius.arbld.unimelb.EDU.AU (8.6.9/8.6.4) id XAA20770 for mbone@isi.edu; Tue, 7 Mar 1995 23:48:35 +1000 From: Darren Reed Message-Id: <199503071348.XAA20770@vitruvius.arbld.unimelb.EDU.AU> Subject: icmp unreachables... To: mbone Date: Tue, 7 Mar 1995 23:48:34 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 230 I still see these from time to time (like now) for mbone stuff.. currently 194.80.34.24 and 128.3.188.98 are sending icmp unreaches to a host listening on the shuttle vat session... are these routers misbehaving here ? darren From list-mgr@ISI.EDU Tue Mar 7 01:03:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 09:04:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 09:04:33 -0800 Received: from aphid.fhcrc.org by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 09:04:33 -0800 Received: from fred.fhcrc.org by aphid.fhcrc.org (5.0/SMI-SVR4) id AA18231; Tue, 7 Mar 1995 09:10:45 +0800 Received: from [140.107.32.78] (mparker-mac) by fred.fhcrc.org (4.1/SMI-4.1) id AA28691; Tue, 7 Mar 95 09:01:13 PST Message-Id: <9503071701.AA28691@fred.fhcrc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 7 Mar 1995 09:03:16 -0800 To: "Richard A. Muirden" , cu-seeme-announce-l@cornell.edu, rem-conf@es.net, mbone, aiwg-mbone@aarnet.edu.au From: mparker@fred.fhcrc.org (Michael Parker) Subject: Re: CU-SeeMe Survey - please fill in Cc: ajp@rmit.edu.au Content-Length: 2296 At 3:53 PM 3/7/95 +1000, Richard A. Muirden wrote: >Hello. > >[ > > I'm sorry if this isn't totally relevant to some readers of these lists > but I wanted to get as many respondants as possible and catch as many > users of CU-SeeMe as possible. Apologies for the distribution if you feel > it is incorrect > >] > >I am investigating Audio and Video usage on the internet for a paper and >would apprieciate it if you could spend a minute or two to answer these >few questions. Questions apply to users of the CU-SeeMe program on the >internet. Responses will help to determine a general usage level as >well as possibilities for the future. > >Thank you in advance. > >-Richard > >--------------------------------------------------------------------------- >All you need do is place an 'X' in the spot that best fits your answer to >the question. You can simply reply to this post, or submit via email to >richard@rmit.EDU.AU. > >Question 1: How often would you say you use CU-SeeMe? > >[ ] Every day >[ ] A few times a week >[ ] At least once a month >[ ] When I am bored >[ X] When I hear something good is on >[ ] Rarely > >Question 2: How much time would you spend per session? > >[ X] less than 1 hour >[ ] 1 hour >[ ] 2 hours >[ ] 3 hours >[ ] 4 or more hours > >Question 3: Do you SEND video/audio on a regular basis? > >[ ] Yes >[ X] No > >Question 4: Do you connect to an international reflector (ie: cornell) or > a local site? > >[ X] Sometimes >[ ] All the time >[ ] Never > >(if you answered anything but 'never' to Question 4) >Question 5: If CU-SeeMe reflectors were linked up would you use a local > reflector to connect to to save bandwidth? > >[X ] Yes >[ ] No > >Question 6: When you use CU-SeeMe do you ever consider issues such as > Network usage and loading, and bandwidth considerations? > >[ ] Yes >[X ] No > > >Thank you for participating! > >-- >Richard A. Muirden, Sys. Admin |Fan of Shostakovich, "Star Trek" and the Boeing >Mailto: richard@rmit.EDU.AU |777 (launch: May 15, 1995 - United Airlines). >Phone: (+61 3) 660 3814 |I created alt.fan.shostakovich! Fly: UA,AN,WN >http://www.rmit.edu.au/richard |Can *YOU* beat my 106 Shost CD's? :-) > * 1995: Remembering 20 years since the death of Shostakovich (1906-75) * From list-mgr@ISI.EDU Tue Mar 7 08:08:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 10:10:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 10:09:33 -0800 Received: from amsaa-cleo.arl.mil by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 10:09:32 -0800 Date: Tue, 7 Mar 95 13:08:55 EST From: "Wallace E. Hughes Jr., AMSAA/CID/SIMB, phone:410-278-5336" To: mbone Subject: MROUTED TROUBLE ON an SGI, IRIX 4.0.5F. Message-Id: <9503071308.aa18046@AMSAA-CLEO.ARL.MIL> I am trying to set my SGI indigo up to recieve mrouted stuff. I have created an mrouted.conf file pointing to the correct tunnel, and have mrouted in /usr/etc. And when I run it nothing happens. I followed the instructions for installing mrouted, ran ar rv /usr/sysgen/boot/bsd.a ip_input.o and when I type autoconfig -f, I get autoconfig -f /usr/sysgen/root/usr/bin/ld: Archive: bsd.a has no table of contents, add one with 'ar ts' lboot: ld returned 256--failed and the new kernel is not created. Any suggestions? (the above was mrouted-2.2 and the OS is Irix 4.0.5F.) Thanks, Wally Hughes. From list-mgr@ISI.EDU Tue Mar 7 04:42:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 12:42:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 12:42:18 -0800 Received: from decu13.Triumf.CA by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 12:42:17 -0800 Received: by decu13.triumf.ca (5.65/DEC-Ultrix/4.3) id AA12410; Tue, 7 Mar 1995 12:42:12 -0800 Date: Tue, 7 Mar 1995 12:42:26 -0800 (PST) From: Andrew Daviel To: mbone Subject: Multicast patching SunOS 4.1.4 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm trying to make a multicast kernel for SunOS 4.1.4, which we upgraded to following a disk crash, skipping 4.1.3. Someone told me I could use the sunos413_U1 patch kit, which I have tried. We only have binaries. The patch seems to go OK until the kernel build, when I get loading vmunix ld: Undefined symbol _legal_vif_num *** Error code 2 I found legal_vif_num in netinet/ip_mroute.c, netinet/ip_output.c but as I don't have the source that's not much help. It seems conditional on RSVP_IFS, as if somehow I have a binary of ip_output compiled with -DRSVP_IFS and one of ip_mroute compiled without. Insights? Please email me direct as, though I have "successfully subscribed to canet-mbone" I don't seem to be getting the mbone list yet. Andrew Daviel email: advax@triumf.ca TRIUMF voice: 604-222-7376 4004 Wesbrook Mall fax: 604-222-7307 Vancouver BC http://andrew.triumf.ca/~andrew Canada V6T 2A3 49D14.7N 123D13.6W From list-mgr@ISI.EDU Tue Mar 7 06:38:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 14:41:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 14:40:41 -0800 Received: from sgi.sgi.com (SGI.COM) by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 14:40:40 -0800 Received: from xingping.engr.sgi.com by sgi.sgi.com via SMTP (950221.405.SGI.8.6.10/910110.SGI) id OAA24969; Tue, 7 Mar 1995 14:40:23 -0800 Received: by xingping.engr.sgi.com (931110.SGI/911001.SGI) for @sgi.sgi.com:mbone@isi.edu id AA17232; Tue, 7 Mar 95 14:38:56 -0800 Date: Tue, 7 Mar 95 14:38:56 -0800 From: arc@xingping.engr.sgi.com (Andrew Cherenson) Message-Id: <9503072238.AA17232@xingping.engr.sgi.com> To: wally@ARL.MIL Subject: Re: MROUTED TROUBLE ON an SGI, IRIX 4.0.5F. Cc: mbone "wally@ARL.MIL" writes: >I am trying to set my SGI indigo up to recieve mrouted stuff. >I have created an mrouted.conf file pointing to the >correct tunnel, and have mrouted in /usr/etc. And when >I run it nothing happens. I followed the instructions >for installing mrouted, ran >ar rv /usr/sysgen/boot/bsd.a ip_input.o > >and when I type autoconfig -f, I get autoconfig -f >/usr/sysgen/root/usr/bin/ld: >Archive: bsd.a has no table of contents, add one with >'ar ts' >lboot: ld returned 256--failed > >and the new kernel is not created. > >Any suggestions? >(the above was mrouted-2.2 and the OS is Irix 4.0.5F.) > >Thanks, >Wally Hughes. From the ftp://ftp.sgi.com/sgi/ipmcast/IRIX4/README file: If you have IDO 4.1 (or later) installed, the autoconfig may fail with the message: Archive: bsd.a has no table of contents, add one with 'ar ts' Do the following as root: cd /usr/sysgen/root/usr/bin mv ld ld.orig cp /usr/bin/ld . autoconfig -f reboot From list-mgr@ISI.EDU Wed Mar 8 20:29:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 17:06:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 17:05:16 -0800 Received: from mullian.ee.mu.OZ.AU by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 7 Mar 1995 17:05:09 -0800 Received: by mullian.ee.mu.OZ.AU id AA02478 (5.67b/IDA-1.5 for mbone@ISI.EDU); Wed, 8 Mar 1995 10:29:53 +1000 (rfc931-sender: @) Date: Wed, 8 Mar 1995 10:29:53 +1000 From: Hu Youdy Message-Id: <199503080029.AA02478@mullian.ee.mu.OZ.AU> To: mbone Subject: Re. information of MPEC Does anyone know any good books for MPEG (especially MPEG 2) and related video compression and transportation? Thanks. From list-mgr@ISI.EDU Tue Mar 7 19:51:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 03:53:21 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 03:51:24 -0800 Received: from amy1.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 03:51:23 -0800 Received: (from mandami@localhost) by amy1.Stanford.EDU (8.6.8/8.6.6) id DAA05738 for mbone@isi.edu; Wed, 8 Mar 1995 03:51:22 -0800 From: Meng-Day Yu Message-Id: <199503081151.DAA05738@amy1.Stanford.EDU> Subject: subscribe To: mbone Date: Wed, 8 Mar 1995 03:51:22 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 10 subscribe From list-mgr@ISI.EDU Wed Mar 8 05:03:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 07:08:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 07:05:27 -0800 Received: from seawifs.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 07:05:26 -0800 Received: by seawifs.gsfc.nasa.gov (950215.SGI.8.6.10/931108.SGI.AUTO.ANONFTP) id KAA23912; Wed, 8 Mar 1995 10:03:47 -0500 From: gene@seawifs.gsfc.nasa.gov (Gene Feldman) Message-Id: <199503081503.KAA23912@seawifs.gsfc.nasa.gov> Subject: JASON VI MBONE Broadcast...put yourself on the map To: rem-conf@es.net, mbone Date: Wed, 8 Mar 1995 10:03:44 -0500 (EST) Cc: todd@jason.org, gene@seawifs.gsfc.nasa.gov (Gene Feldman), tim@jason.org, tricom1234@aol.com X-Mailer: ELM [version 2.4 PL0] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 837 For those of you who are planning to watch the live broadcast of the JASON VI Expedition to Hawai'i on the MBONE tomorrow at 1300 EST (1800 UTC) we would really like to know who our audience is and where you are watching from. To do this, we have put together an interactive locator map that allows you to enter your location and have it added to a world map showing all the sites participating in the MBONE event. The locator map is available on the World Wide Web at the following URL: http://seawifs.gsfc.nasa.gov/JASON_MULTICAST.html Please enter your locations anytime between now and the end of the broadcast tomorrow to be included. Thanks very much and hope you can join us tomorrow. Gene Feldman and Norman Kuring NASA/Goddard Space Flight Center Todd Viola JASON Foundation for Education Madelyn Smith Tricom Associates From list-mgr@ISI.EDU Wed Mar 8 08:13:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 10:15:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 10:13:07 -0800 Received: from noc.sura.net by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 10:13:06 -0800 Received: from aotearoa.sura.net (aotearoa.sura.net [128.167.254.175]) by noc.sura.net (8.6.8.1/8.6.6) with ESMTP id NAA03770; Wed, 8 Mar 1995 13:13:00 -0500 Received: from localhost (localhost [127.0.0.1]) by aotearoa.sura.net (8.6.10/8.6.10) with SMTP id NAA13356; Wed, 8 Mar 1995 13:13:40 -0500 Message-Id: <199503081813.NAA13356@aotearoa.sura.net> X-Authentication-Warning: aotearoa.sura.net: Host localhost didn't use HELO protocol To: Frank Peters Cc: MBONE Subject: Re: Still no mbone traffic...I think :-) In-Reply-To: Your message of "Tue, 07 Mar 1995 14:36:07 CST." <199503072036.OAA08233@Jester.CC.MsState.Edu> Date: Wed, 08 Mar 1995 13:13:40 -0500 From: Erik Sherk Frank, I have reached the limit of my experience and can't find the problem. Perhaps some of the mboners can help... Hi all, We are having problems with a mbone tunnel. The mrouted thinks that the tunnel mbone:[~] mrinfo 130.207.244.27 130.207.244.27 (houdini-fddi.gatech.edu) [version 2.2]: 130.207.244.27 -> 130.207.244.1 (gt-firewall-ext-fddi.gatech.edu) [1/1] 130.207.166.154 -> 0.0.0.0 (?) [1/1/disabled] 130.207.244.27 -> 192.77.156.3 (mbone-east.ans.net) [1/16/tunnel] -> 130.207.244.27 -> 130.18.164.1 (Jester.CC.MsState.Edu) [1/32/tunnel] <- 130.207.244.27 -> 128.167.208.2 (jkv2-jkv1-pe.sura.net) [1/64/tunnel] 130.207.244.27 -> 147.120.152.128 (?) [1/32/tunnel/down] 130.207.244.27 -> 130.70.40.25 (alpha.noc.usl.edu) [1/64/tunnel] 130.207.244.27 -> 131.144.78.5 (Video.Rock.PeachNet.EDU) [1/16/tunnel/down] 130.207.244.27 -> 198.72.65.10 (?) [1/16/tunnel] 130.207.244.27 -> 128.140.2.212 (cssun.mathcs.emory.edu) [1/32/tunnel] 130.207.244.27 -> 198.79.7.9 (beavis.atglab.bls.com) [1/32/tunnel] 130.207.244.27 -> 130.207.84.11 (cae.cad.gatech.edu) [1/8/tunnel/down] 130.207.244.27 -> 130.207.9.11 (siwenna.cc.gatech.edu) [1/8/tunnel] 130.207.244.27 -> 130.207.8.17 (appalachian.cc.gatech.edu) [1/8/tunnel] 130.207.244.27 -> 130.207.224.80 (morta.eedsp.gatech.edu) [1/8/tunnel] 130.207.244.27 -> 199.77.192.10 (?) [1/6/tunnel/down] 130.207.244.27 -> 130.207.213.18 (khan.gcatt.gatech.edu) [1/6/tunnel/down] mbone:[~] mbone:[~] mrinfo 130.18.164.1 130.18.164.1 (Jester.CC.MsState.Edu) [version 2.2]: 130.18.164.1 -> 0.0.0.0 (?) [1/1/querier] -> 130.18.164.1 -> 130.207.244.27 (houdini-fddi.gatech.edu) [1/32/tunnel] <- But we don't see any multicast routes? Below, is a sample of 'mrouted -d'. Anyone have any ideas? Thanks... Erik > Hi, > > We are now running mrouted 2.2, which appears to be the latest version > for Solaris platforms. It has changed the behaviour somewhat but we > still aren't seeing any mbone data. > > Now when I run mrouted -d I get the output at the end of this message > (the banner stuff comes immediately and the update lines accumulate > every few seconds). But sd seems to be seeing no data. > > ----- mrouted -d output > debug level 2 > mrouted version 2.2 > installing le0 (130.18.164.1 on subnet 130.18) as vif #0 > installing tunnel from 130.18.164.1 to 130.207.244.27 as vif #1 > > Virtual Interface Table > Vif Local-Address Metric Thresh Flags > 0 130.18.164.1 subnet: 130.18 1 1 querier > 1 130.18.164.1 tunnel: 130.207.244.27 1 32 > > Multicast Routing Table (1 entry) > Origin-Subnet From-Gateway Metric In-Vif Out-Vifs > 130.18 1 0 1* > > update 140 starting at 0 of 1145 > update 124 starting at 140 of 1633 > update 126 starting at 264 of 1634 > update 126 starting at 390 of 1634 > update 126 starting at 516 of 1634 > update 126 starting at 642 of 1634 > update 126 starting at 768 of 1634 From list-mgr@ISI.EDU Wed Mar 8 09:11:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 11:15:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 11:12:13 -0800 Received: from andy.dia.atd.net by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 11:12:12 -0800 Received: (from crobson@localhost) by andy.dia.atd.net (8.6.9/8.6.9) id OAA00600; Wed, 8 Mar 1995 14:11:57 -0500 Date: Wed, 8 Mar 1995 14:11:57 -0500 (EST) From: Chris Robson ATDNet Admin Subject: Re: Multicast patching SunOS 4.1.4 To: Andrew Daviel Cc: mbone In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Andy, MBoners I too am just now building a sunOS 4.1.4 machine and want to now if Andy's problem has a fix tks...chris ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Chris Robson www: http://www.dia.atd.net/DIAHomePage.html vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv On Tue, 7 Mar 1995, Andrew Daviel wrote: > I'm trying to make a multicast kernel for SunOS 4.1.4, which we upgraded > to following a disk crash, skipping 4.1.3. > > Someone told me I could use the sunos413_U1 patch kit, which I have tried. > We only have binaries. The patch seems to go OK until the kernel build, > when I get > loading vmunix > ld: Undefined symbol > _legal_vif_num > *** Error code 2 > > I found legal_vif_num in netinet/ip_mroute.c, netinet/ip_output.c but as I > don't have the source that's not much help. It seems conditional on > RSVP_IFS, as if somehow I have a binary of ip_output compiled with -DRSVP_IFS > and one of ip_mroute compiled without. > > Insights? > > Please email me direct as, though I have "successfully subscribed to > canet-mbone" I don't seem to be getting the mbone list yet. > > > Andrew Daviel email: advax@triumf.ca > TRIUMF voice: 604-222-7376 > 4004 Wesbrook Mall fax: 604-222-7307 > Vancouver BC http://andrew.triumf.ca/~andrew > Canada V6T 2A3 49D14.7N 123D13.6W > > > From list-mgr@ISI.EDU Wed Mar 8 09:04:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 13:06:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 13:05:52 -0800 Received: from fnal.fnal.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 13:05:51 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HNWBLB65M800DSXV@FNAL.FNAL.GOV>; Wed, 08 Mar 1995 15:05:03 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA07762; Wed, 8 Mar 95 15:04:01 CST Date: Wed, 08 Mar 1995 15:04:01 -0600 From: Matt Crawford Subject: Re: Still no mbone traffic...I think :-) In-Reply-To: Your message of Wed, 08 Mar 95 13:13:40 EST. <199503081813.NAA13356@aotearoa.sura.net> Sender: crawdad@munin.fnal.gov To: Erik Sherk Cc: Frank Peters , MBONE Message-Id: <9503082104.AA07762@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{; Wed, 8 Mar 1995 13:24:35 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 13:24:16 -0800 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 13:24:11 -0800 Posted-Date: Wed 8 Mar 95 13:23:59 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Wed, 8 Mar 95 13:24:06 PST Date: Wed 8 Mar 95 13:23:59 PST From: Stephen Casner Subject: New mcast_install; and Re: Multicast patching SunOS 4.1.4 To: MBONE Cc: crobson@andy.dia.atd.net, andrew@andrew.triumf.ca Message-Id: <794697839.0.CASNER@XFR.ISI.EDU> In-Reply-To: Mail-System-Version: Dual purpose message: 1. Several people have complained that the 3.3 multicast release does not contain an incremental patches for those who had previously installed the 2.0 release. A week or two ago, I added an "uninstall" feature to the mcast_install script which simply reverses the patches in the .diff files. That way, you can pick up a copy of the 2.0 release again, uninstall the patches, and then apply the 3.3 release. No attempt is made to restore the original .o files since the installation of the 3.3 release will just replace them anyway. Some of the patch hunks may fail in the uninstall if you have made other independent patches, but in that case an incremental patch probably would have failed also. This new feature is implemented as a new first question asked by the script. A couple of people have now tested this script, so it is time to release it: ftp.isi.edu:mbone/mcast_install 2. The answer to the compilation problem below is simple: you must include "options RSVP_ISI" in your kernel config file because ip_output.o was compiled that way. If you use the mcast_install script, it will ask if you want to include RSVP_ISI and you should answer 'y' (the default). However, if you have already done most of the install and just want to fix this problem, then after you manually change your config, be sure to do "make clean" before "make" rather than just recompiling the affected modules. Otherwise you will make a kernel that appears to work fine but sends IGMP messages with large TTL rather than TTL 1 as they are supposed to be. Several people have done this. This problem has been mentioned on this list a few times, but hasn't made it into the documentation. Archives of the mbone list may be found at: ftp.isi.edu:mbone/mbone.mail* -- Steve > I'm trying to make a multicast kernel for SunOS 4.1.4, which we upgraded > to following a disk crash, skipping 4.1.3. > > Someone told me I could use the sunos413_U1 patch kit, which I have tried. > We only have binaries. The patch seems to go OK until the kernel build, > when I get > loading vmunix > ld: Undefined symbol > _legal_vif_num > *** Error code 2 ------- From list-mgr@ISI.EDU Wed Mar 8 05:38:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 13:38:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 13:38:18 -0800 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 13:38:17 -0800 Posted-Date: Wed 8 Mar 95 13:38:10 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Wed, 8 Mar 95 13:38:11 PST Date: Wed 8 Mar 95 13:38:10 PST From: Stephen Casner Subject: Re: Still no mbone traffic...I think :-) To: sherk@sura.net, fwp@jester.cc.msstate.edu Cc: MBONE Message-Id: <794698690.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199503081813.NAA13356@aotearoa.sura.net> Mail-System-Version: Erik, Two thoughts: the mrouted -d output did not show any trouble, but what about mrouted -d at the gatech end? Second, if the Solaris machine is 2.4, there is a bug that must be patched. One of the Sun guys posted to the mbone list a month or two ago. The archive is on ftp.isi.edu:mbone/mbone.mail* -- Steve ------- From list-mgr@ISI.EDU Wed Mar 8 06:26:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 14:28:54 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 14:28:13 -0800 Received: from baker.nwnet.net by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 14:28:11 -0800 Received: by baker.nwnet.net (5.65/UW-NDC Revision: 2.29 ) id AA05299; Wed, 8 Mar 95 14:26:04 -0800 Date: Wed, 8 Mar 1995 14:26:04 -0800 (PST) From: David Comay To: Erik Sherk Cc: Frank Peters , MBONE Subject: Re: Still no mbone traffic...I think :-) In-Reply-To: <199503081813.NAA13356@aotearoa.sura.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII erik, what version of solaris is the machine in question running. if it is 2.4, there is a patch that needs to be applied - it can be found in ftp://playground.sun.com/pub/multicast/patches/101969-06.tar SPARC ftp://playground.sun.com/pub/multicast/patches/101970-06.tar X86 if the version is 2.3, then there is a bug that occasionally crops up for which there is no released patch as of yet. the symptoms are that the tunnel shows as being up, there are routes in the routing table (use `netstat -Mr' to display the multicast routing table) but no actual multicast traffic traverses on to the solaris machine's interfaces. in this situation, a `netstat -Ms' will show an increasing datagrams with no room for tunnel options counter. a workaround is to set the kernel variable last_encap_src to zero ala echo last_encap_src/W0 | adb -wk /dev/ksyms /dev/mem thanks to erik nordmark of sun for this information. dsc From list-mgr@ISI.EDU Wed Mar 8 11:01:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 15:02:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 15:01:50 -0800 Received: from Jester.CC.MsState.Edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 15:01:48 -0800 Received: (fwp@localhost); by Jester.CC.MsState.Edu (8.6.8.1/7.0m-FWP-MsState); id RAA00511; Wed, 8 Mar 1995 17:01:29 -0600 Date: Wed, 8 Mar 1995 17:01:29 -0600 From: Frank Peters Message-Id: <199503082301.RAA00511@Jester.CC.MsState.Edu> To: sherk@sura.net, dsc@nwnet.net Subject: Re: Still no mbone traffic...I think :-) Cc: MBONE X-Sun-Charset: US-ASCII > what version of solaris is the machine in question running. if it is 2.4, > there is a patch that needs to be applied - it can be found in > > ftp://playground.sun.com/pub/multicast/patches/101969-06.tar SPARC > ftp://playground.sun.com/pub/multicast/patches/101970-06.tar X86 > Very interesting. I knew that "the latest version of patch 101969" was required (I'm running 2.4). Since we have a support contract I went to the official support system and retrieved and installed this patch. But... The latest version of this patch available through Sun official channels is 101969-*05* and that is the version of this patch which I had installed. I just checked the online patch system (sunsolve1.sun.com) and version 05 is still the latest version of this patch available from Sun. I retrieved the referenced patch from playground.sun.com and installed it and it does indeed fix our problem. Here's the interesting thing though. The 101969-06 patch from playground.sun.com is dated 08/Nov/95. The 101969-05 patch from the official Sun patch archive at sunsolve1.sun.com is dated Dec/02/94. So why is the lower numbered patch newer (and, apparently, doesn't include some patches present in the 101969-06 revision). The only explanation that I can think of is that 101969-06 was withdrawn due to problems in the field. D oes anyone know of problems with patch 101969-06 that might have lead to its removal from the field by Sun? From list-mgr@ISI.EDU Wed Mar 8 07:20:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 15:21:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 15:20:33 -0800 Received: from gumby.dsd.TRW.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 15:20:32 -0800 Received: from localhost.sp.TRW.COM by gumby.dsd.TRW.COM (4.1/SMI-4.1) id AA01611; Wed, 8 Mar 95 15:20:24 PST Message-Id: <9503082320.AA01611@gumby.dsd.TRW.COM> To: Stephen Casner Cc: MBONE Subject: Re: New mcast_install; and Re: Multicast patching SunOS 4.1.4 In-Reply-To: Your message of "Wed, 08 Mar 95 13:23:59 PST." <794697839.0.CASNER@XFR.ISI.EDU> Date: Wed, 08 Mar 95 15:20:23 -0800 From: Dan Molinelli steve/etal i wanted to thank you for the new versions of mcast_install and mcast_uninstall. i took your advice to my problem of getting MBONE tunnel to different 7-bit subnets which was to upgrade to mrouted.3.3. when i upgraded (thanks for mcast_uninstall) all worked fine!! wew!! later dan Daniel Molinelli dan.molinelli@trw.com TRW S&EG/ITS Views expressed here are mine. Los Angeles, CA From list-mgr@ISI.EDU Wed Mar 8 07:54:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 15:57:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 15:56:44 -0800 Received: from baker.nwnet.net by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 15:56:43 -0800 Received: by baker.nwnet.net (5.65/UW-NDC Revision: 2.29 ) id AA06642; Wed, 8 Mar 95 15:54:55 -0800 Date: Wed, 8 Mar 1995 15:54:54 -0800 (PST) From: David Comay To: Frank Peters Cc: sherk@sura.net, MBONE Subject: Re: Still no mbone traffic...I think :-) In-Reply-To: <199503082301.RAA00511@Jester.CC.MsState.Edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 8 Mar 1995, Frank Peters wrote: > > what version of solaris is the machine in question running. if it is 2.4, > > there is a patch that needs to be applied - it can be found in > > > > ftp://playground.sun.com/pub/multicast/patches/101969-06.tar SPARC > > ftp://playground.sun.com/pub/multicast/patches/101970-06.tar X86 > > > > Very interesting. I knew that "the latest version of patch 101969" was > required (I'm running 2.4). Since we have a support contract I went to > the official support system and retrieved and installed this patch. > > > Does anyone know of problems with patch 101969-06 that might have lead > to its removal from the field by Sun? > frank, i'm afraid i'm no help here, although the fixes for multicast routing are NOT mentioned in the patch's README for revision 5 of the patch - only in revision 6. i know a number of folks have had success with revision 6 of the patch under solaris 2.4, but why it hasn't appeared on the official patch server is a mystery :-) dsc From list-mgr@ISI.EDU Wed Mar 8 14:23:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 23:12:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 23:10:25 -0800 Received: from decu13.triumf.ca ([142.90.100.8]) by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 8 Mar 1995 23:10:22 -0800 Received: by decu13.triumf.ca (5.65/DEC-Ultrix/4.3) id AA22302; Wed, 8 Mar 1995 22:23:36 -0800 Date: Wed, 8 Mar 1995 22:23:52 -0800 (PST) From: Andrew Daviel To: mbone Subject: Mirrors of ftp.isi.edu ? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Are there any mirrors of the mbone list archives? Every time I've tried ftp to ftp.isi.edu, I've got "too many anon. users", ranging from about 9:30 PST to 00:00 PST. Just now (22:30 PST) I couldn't get an answer from ping. Andrew Daviel email: advax@triumf.ca TRIUMF voice: 604-222-7376 4004 Wesbrook Mall fax: 604-222-7307 Vancouver BC http://andrew.triumf.ca/~andrew Canada V6T 2A3 49D14.7N 123D13.6W From list-mgr@ISI.EDU Fri Mar 10 02:56:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 9 Mar 1995 00:57:18 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 9 Mar 1995 00:56:57 -0800 Received: from han.hana.nm.kr by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 9 Mar 1995 00:56:52 -0800 Received: from ring.kotel.co.kr by han.hana.nm.kr (4.1/KUM-0.1) id AA06544; Thu, 9 Mar 95 17:57:50 KST Received: from h2o.kotel.co.kr by ring.kotel.co.kr (4.1/RING-0.1) id AA11630; Thu, 9 Mar 95 17:42:29 KST Received: by h2o.kotel.co.kr (8.6.9H1/8.6.4) id RAA18229 From: Kim Young-Sik Message-Id: <199503091756.RAA18229@h2o.kotel.co.kr> Subject: Re: Mirrors of ftp.isi.edu ? To: andrew@andrew.triumf.ca (Andrew Daviel) Date: Thu, 9 Mar 1995 17:56:02 +0900 (JST) Cc: mbone In-Reply-To: from "Andrew Daviel" at Mar 8, 95 10:23:52 pm X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 935 According to Andrew Daviel: > Are there any mirrors of the mbone list archives? Every time I've tried > ftp to ftp.isi.edu, I've got "too many anon. users", ranging from about > 9:30 PST to 00:00 PST. Just now (22:30 PST) I couldn't get an answer from > ping. > We do it. Try to ftp://ftp.kornet.nm.kr/pub/mbone -- _/ _/ _/_/_/ _/ _ _/ _/ _/ _/_/_/_/ Kim, YoungSik _/ _/ _/ _/_/ _/ _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ _/ _/ _/_/_/_/ Korea Telecom Research Center _/ _/ _/ _/ _/ _/_/ _/ High Speed Networking Team _/ _/ _/_/_/ _/ _/ _/ _/_/_/_/ _/ E-mail: kimys@h2o.kotel.co.kr _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Voice : +82-2-526-5231 http://h2o.kotel.co.kr/~kimys/kimys.html From list-mgr@ISI.EDU Thu Mar 9 09:53:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 9 Mar 1995 01:54:01 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 9 Mar 1995 01:53:33 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 9 Mar 1995 01:53:28 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id JAA00581; Thu, 9 Mar 1995 09:53:16 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id JAA13131; Thu, 9 Mar 1995 09:53:13 GMT Date: Thu, 9 Mar 1995 09:53:13 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Chris Robson ATDNet Admin Cc: Andrew Daviel , mbone Subject: Re: Multicast patching SunOS 4.1.4 In-Reply-To: Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 8 Mar 1995, Chris Robson ATDNet Admin wrote: > Andy, MBoners > > I too am just now building a sunOS 4.1.4 machine and want to now if > Andy's problem has a fix > > tks...chris > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Chris Robson > www: http://www.dia.atd.net/DIAHomePage.html > vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv > > On Tue, 7 Mar 1995, Andrew Daviel wrote: > > > I'm trying to make a multicast kernel for SunOS 4.1.4, which we upgraded > > to following a disk crash, skipping 4.1.3. > > > > Someone told me I could use the sunos413_U1 patch kit, which I have tried. > > We only have binaries. The patch seems to go OK until the kernel build, > > when I get > > loading vmunix > > ld: Undefined symbol > > _legal_vif_num > > *** Error code 2 > > > > I found legal_vif_num in netinet/ip_mroute.c, netinet/ip_output.c but as I > > don't have the source that's not much help. It seems conditional on > > RSVP_IFS, as if somehow I have a binary of ip_output compiled with -DRSVP_IFS > > and one of ip_mroute compiled without. > > > > Insights? > > > > Please email me direct as, though I have "successfully subscribed to > > canet-mbone" I don't seem to be getting the mbone list yet. You MUST define RSVP_ISI. Some of the object files have dependencies which require that rsvp be compiled into the kernel. You will not lose out in any way by compiling in this support. You need to add the line: options RSVP_ISI to your kernel config and then remove the build tree from your previous attempt at making the kernel. This step is important because if you don't you will end up with a vmunix with broken multicast. I have been running a machine with 4.1.4 for some weeks now without any problems yet but it would be nice to have a proper release of the multicast stuff for 4.1.4. I expect this will be the case for the next release. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Thu Mar 9 04:34:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 9 Mar 1995 06:37:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 9 Mar 1995 06:36:20 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 9 Mar 1995 06:36:18 -0800 Received: from seawifs.gsfc.nasa.gov by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 9 Mar 1995 06:36:14 -0800 Received: by seawifs.gsfc.nasa.gov (950215.SGI.8.6.10/931108.SGI.AUTO.ANONFTP) id JAA17345; Thu, 9 Mar 1995 09:34:54 -0500 From: gene@seawifs.gsfc.nasa.gov (Gene Feldman) Message-Id: <199503091434.JAA17345@seawifs.gsfc.nasa.gov> Subject: Last Chance for JASON VI MBONE Broadcast To: rem-conf@es.net, mbone Date: Thu, 9 Mar 1995 09:34:52 -0500 (EST) Cc: todd@jason.org, gene@seawifs.gsfc.nasa.gov, tim@jason.org, tricom1234@aol.com X-Mailer: ELM [version 2.4 PL0] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 862 This is the last call for those of you who are planning to watch the live broadcast of the JASON VI Expedition to Hawai'i on the MBONE today at 1300 EST (1800 UTC). We would really like to know who our audience is and where you are watching from. To do this, we have put together an interactive locator map that allows you to enter your location and have it added to a world map showing all the sites participating in the MBONE event. The locator map is available on the World Wide Web at the following URL: http://seawifs.gsfc.nasa.gov/JASON_MULTICAST.html Please enter your locations anytime between now and the end of the broadcast tomorrow to be included. Thanks very much and hope you can join us later today. Gene Feldman and Norman Kuring NASA/Goddard Space Flight Center Todd Viola JASON Foundation for Education Madelyn Smith Tricom Associates From list-mgr@ISI.EDU Thu Mar 9 14:43:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 9 Mar 1995 22:44:16 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 9 Mar 1995 22:44:00 -0800 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 9 Mar 1995 22:43:58 -0800 Posted-Date: Thu 9 Mar 95 22:43:50 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 9 Mar 95 22:43:52 PST Date: Thu 9 Mar 95 22:43:50 PST From: Stephen Casner Subject: Re: Mirrors of ftp.isi.edu ? To: andrew@andrew.triumf.ca, MBONE Message-Id: <794817830.0.CASNER@XFR.ISI.EDU> In-Reply-To: Mail-System-Version: Andrew, > Are there any mirrors of the mbone list archives? Every time I've tried > ftp to ftp.isi.edu, I've got "too many anon. users", ranging from about > 9:30 PST to 00:00 PST. Just now (22:30 PST) I couldn't get an answer from > ping. Thanks for the warning about this. I did not realize it was a problem. If anyone else out there has also had similar trouble accessing ftp.isi.edu, please send mail to me personally (not to the list) and I will use it to go argue with our systems administrators. I say "recently" because before we got our T3 connection to MCInet on January 20, our general connectivity to the Internet had become pretty poor. Since then, I think it has been good. -- Steve ------- From list-mgr@ISI.EDU Fri Mar 10 20:14:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 10 Mar 1995 10:17:56 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 10 Mar 1995 10:16:53 -0800 Received: from mgate.uni-hannover.de by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 10 Mar 1995 10:15:16 -0800 Received: from helios.tnt.uni-hannover.de by mgate.uni-hannover.de with SMTP (PP); Fri, 10 Mar 1995 19:16:29 +0100 Received: from ikarus.tnt.uni-hannover.de by helios.tnt.uni-hannover.de (4.1/SMI-4.1) id AA14018; Fri, 10 Mar 95 19:14:19 +0100 Date: Fri, 10 Mar 95 19:14:19 +0100 From: bloemer@tnt.uni-hannover.de (Arnold Bloemer) Message-Id: <9503101814.AA14018@helios.tnt.uni-hannover.de> To: rem-conf@es.net, mbone Subject: MBone Demo on ARD (greatest german tv channel), Sa. 12:30 - 13:10 There will be a computer show tomorrow (Saturday) from 12:30 GMT until 13:10 GMT about CeBIT'95. It is the only show about CeBIT'95 in ARD, the greatest german tv channel and we have got a time slot, because we will broadcast the program on MBone directly from the studio. There will be an interview about MBone and I have to give a MBone Demo. We will broadcast the show on our CeBIT'95 channels. I will have only 3 1/2 minutes in the show for interview and demo. In the demo the tv station would of course like to see and hear a short sentence from somebody far away from Germany. The dream would be to have a MBone interview partner in Australia, because Australia is partner country for CeBIT'95, but any other country would be great too. The tv show could be very important for MBone public relation here in Germany. So I would be very grateful if you could arrange to participate in the show. Please send me a mail if you know that you will participate. I would like to do tests in the morning during our forum times and shortly before the show starts. Thank you very much, Arnold ________________________________________________________________________________ Dipl.-Ing. Arnold Bloemer Universitaet Hannover Institut fuer Theoretische Nachrichtentechnik bloemer@tnt.uni-hannover.de und Informationsverarbeitung (TNT) fax: +49 511 762-5333 Appelstrasse 9A phone: +49 511 762-5320 D-30167 Hannover http://www.tnt.uni-hannover.de/wiss/bloemer.html Germany ________________________________________________________________________________ From list-mgr@ISI.EDU Fri Mar 10 15:26:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 10 Mar 1995 19:26:22 -0800 Received: from POSAUNE.TAMU.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 10 Mar 1995 19:26:21 -0800 Received: by posaune.tamu.edu (NX5.67e/NX3.0M) id AA00518; Fri, 10 Mar 95 21:26:20 -0600 Message-Id: <9503110326.AA00518@posaune.tamu.edu> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Date: Fri, 10 Mar 95 21:26:18 -0600 To: mbone-na Subject: mrouted 2.2 on Solaris 2.4 bug? I'm setting up our MBONE feed using mrouted 2.2 on a Sparc 1 running Solaris 2.4. There appears to be a bug in the kernel in that the DVMRP init kernel call is not setting up the interface to receive all multicasts. I've confirmed that mrouted is sending IGMP queries and machines are replying. However the IGMP reports never make it to mrouted itself. Everything else appears to be working because I hardcoded in a call to forward 224.2.127.255 regardless of IGMP messaging and I now receive sd advertisements ok. Is this a known bug or am I missing something? Does anybody have a fix? Please cc: me directly on responses; my request to subscribe to mbone-na hasn't been processed yet. Thanks. Dave --- David K. Hess Network Analyst David-Hess@tamu.edu Computing and Information Services - Network Group (409) 845-0372 (work) Texas A&M University From list-mgr@ISI.EDU Fri Mar 10 12:19:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 10 Mar 1995 20:19:46 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 10 Mar 1995 20:19:44 -0800 Received: from cumberland.parc.xerox.com ([13.2.117.8]) by alpha.xerox.com with SMTP id <14409(5)>; Fri, 10 Mar 1995 20:19:38 PST Received: by cumberland.parc.xerox.com id <97>; Fri, 10 Mar 1995 20:19:29 -0800 From: Bill Fenner To: dhess@net.tamu.edu, mbone-na Subject: Re: mrouted 2.2 on Solaris 2.4 bug? Message-Id: <95Mar10.201929pst.97@cumberland.parc.xerox.com> Date: Fri, 10 Mar 1995 20:19:26 PST You probably want: Bugid: 1178985 Multicast routing broken in Solaris 2.4 The patchid 101969-06 (sparc) and 101970-06 (x86). The patches are on playground.sun.com in /pub/multicast/. Bill From list-mgr@ISI.EDU Sat Mar 11 13:51:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 11 Mar 1995 05:57:30 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 11 Mar 1995 05:52:20 -0800 Received: from mailsun.aber.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 11 Mar 1995 05:52:12 -0800 Received: from mailhost.aber.ac.uk (actually host andromedabb.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Sat, 11 Mar 1995 13:51:59 +0000 To: bloemer@tnt.uni-hannover.de (Arnold Bloemer) Cc: rem-conf@es.net, mbone, dap@aber.ac.uk Subject: Re: MBone Demo on ARD (greatest german tv channel), Sa. 12:30 - 13:10 In-Reply-To: Your message of Fri, 10 Mar 1995 19:14:19 +0100. <9503101814.AA14018@helios.tnt.uni-hannover.de> Date: Sat, 11 Mar 1995 13:51:27 +0000 Message-Id: <25687.794929887@mailhost.aber.ac.uk> From: D E PRICE Dear Arnold, Well, I sat and watched but the audio was breaking up quite badly and my video program kept crashing every five minutes..... Anyway, I hope the ARD viewers liked what happened... Bye Dave Price From list-mgr@ISI.EDU Sat Mar 11 17:25:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 11 Mar 1995 07:25:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 11 Mar 1995 07:25:35 -0800 Received: from mailgzrz.TU-Berlin.DE by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 11 Mar 1995 07:25:31 -0800 Received: from tubkom.prz.tu-berlin.de by mailgzrz.TU-Berlin.DE with SMTP (PP); Sat, 11 Mar 1995 16:25:20 +0100 Received: from bluemoon.prz.tu-berlin.de (bluemoon.prz.tu-berlin.de [130.149.62.17]) by tubkom.prz.tu-berlin.de (8.6.9/8.6.9) with SMTP id QAA00558 for ; Sat, 11 Mar 1995 16:25:14 +0100 Message-Id: <199503111525.QAA00558@tubkom.prz.tu-berlin.de> Received: by bluemoon.prz.tu-berlin.de (1.37.109.4/15.6) id AA02412; Sat, 11 Mar 95 16:25:16 +0100 From: wolf@prz.tu-berlin.de Subject: No Space Shuttle video... To: mbone Date: Sat, 11 Mar 1995 16:25:16 +0100 (MEZ) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 630 Hi, anybody knows why NASA doesn't send the Video of STS-67 anymore? We (at the show net "NewsNet'95" at "CeBIT" show in Hannover/Germany) receive the audio quite well, but there is no video send in the video channel. Thanks, Thomas -- Thomas Wolfram Germany: 0 30 31421171 PRZ TU Berlin abroad: +49 30 31421171 EANTC WWW: http://www.prz.tu-berlin.de:/~wolf _____________________________________________________________________________ _____S__I__C____T__R__A__N__S__I__T____G__L__O__R__I__A____M__U__N__D__I_____ From list-mgr@ISI.EDU Mon Mar 13 14:06:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 13 Mar 1995 04:12:49 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 13 Mar 1995 04:12:25 -0800 Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 13 Mar 1995 04:12:07 -0800 Message-Id: <199503131212.AA22715@venera.isi.edu> Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Mon, 13 Mar 1995 13:07:30 +0100 X-Mailer: exmh version 1.5.3 12/28/94 To: rem-conf@es.net, mbone From: Henning Schulzrinne Subject: Infocom'95 MBONE multicast Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Mar 1995 13:06:59 +0100 Sender: schulzrinne@fokus.gmd.de Infocom'95 in Boston (April 4 through 6) will be partially transmitted via MBONE (audio and video). All track-A sessions, two panels and the keynote address will be transmitted. Details are below: April 4, 8:30 -- 10:00 am EST (13:30 -- 15:00 GMT) The Information Revolution, a Historical Perspective Sandy Fraser, AT&T Bell Laboratories. The conference opens with a Keynote Address by Sandy Fraser, associate vice president of Information Sciences Research at AT&T Bell Laboratories. His talk, ``The Information Revolution: A Historical Perspective,'' compares recent events with events that took place during the industrial revolution. Fraser pursues a personal research program in computing and computer communications, and supports initiatives that promise new business directions for AT&T. His present activity focuses on digital audio, billing, and home networks. He is the inventor of Datakit Virtual Circuit Switch and the Spider ring network, both of which are cell-based networks that anticipated the development of the ATM. He was the originator of the UNIX Circuit Design Aids System, which automated prototype circuit board assembly from schematic capture through wiring with an on-line wire-wrap machine. He has also been assistant director of research at Cambridge University where he wrote the file system for the Atlas 2 computer, England's first time sharing system. He is also a fellow of the IEEE. Two panels will also be broadcast: -- The Role of Satellites in the Future Communication Infrastructure (chaired by Anthony Ephremides) (Wednesday, April 5, 5:30 pm - 7:00 pm EST) -- Reservation or no reservation (chaired by Lixia Zhang; panelists: Dave Clark, MIT; Steve Deering, Xerox PARC; Domenico Ferrari, University of California at Berkeley; Christian Huitema, INRIA, France; Scott Shenker, Xerox PARC ) (Thursday, April 6, 10:30 am - 12:00 pm EST) We hope to accomodate questions and comments from the remote audience. Remote participants who want to ask questions will be asked to 'raise their hand' through a whiteboard session, as described on the Infocom'95 WWW page. Information about Infocom'95 and its program is available at http://www.research.att.com/~hgs/infocom95/program.html Depending on requests, we'll be doing tape rebroadcast after hours. Since Infocom'95 partially overlaps with the Danvers IETF 'next door', we'll be coordinating/reducing bandwidth usage as necessary. From list-mgr@ISI.EDU Mon Mar 13 13:00:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 13 Mar 1995 17:00:41 -0800 Received: from POSAUNE.TAMU.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 13 Mar 1995 17:00:39 -0800 Received: by posaune.tamu.edu (NX5.67e/NX3.0M) id AA01612; Mon, 13 Mar 95 19:00:39 -0600 Message-Id: <9503140100.AA01612@posaune.tamu.edu> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Date: Mon, 13 Mar 95 19:00:37 -0600 To: mbone-na Subject: Question about vat.... I scanned through the archive and didn't see much about this.... I'm getting garbled audio on most channels coming into our campus using vat. When looking at the stats it says that we are "missing" about 25% of the packets (misordered is around 12% but I assume this is a side effect of the "missing" counter, correct?). What is curious though is that when vat starts up and hasn't grabbed /dev/audio (due to permissions problems) the missing count stays at 0. Is vat checking for "missing" packets when /dev/audio is not opened? Or are the writes to /dev/audio killing vat's performance and causing packets to be dropped? I've run vat from a Sparc 1, Sparc 1+ and Sparc Classic all with the same results. I'm running Solaris 2.3 and 2.4. I checked for relevant patches and haven't come up with much (especially under 2.4). Once again, my subscription to mbone-na has not gone through so please cc: me on responses. Thanks. --- David K. Hess Network Analyst David-Hess@tamu.edu Computing and Information Services - Network Group (409) 845-0372 (work) Texas A&M University From list-mgr@ISI.EDU Tue Mar 14 06:17:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 13 Mar 1995 22:20:08 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 13 Mar 1995 22:18:44 -0800 Received: from louie.udel.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 13 Mar 1995 22:18:43 -0800 Received: from snow-white-fddi.udel.edu by louie.udel.edu id aa23568; 14 Mar 95 1:18 EST Received: from louie.udel.edu by snow-white.ee.udel.edu id aa08808; 14 Mar 95 1:17 EST Received: from snow-white.ee.udel.edu by beauregard.udel.edu id aa22712; 14 Mar 95 6:17 GMT To: mbone Subject: New mrouted (version 3.4) available Date: Tue, 14 Mar 1995 06:17:03 +0000 From: Ajit Thyagarajan Message-Id: <9503140617.aa22712@beauregard.udel.edu> This is to announce the availability of version 3.4 of mrouted. This is an interim release to fix some bugs that were important enough not to wait for the planned version 3.5 full release of the multicast routing extensions. This interim release includes only mrouted and no kernel changes. This version (3.4) of mrouted will work *only* with a kernel built using the ipmulti3.3-sunos413x.tar.gz and is meant to replace the version of mrouted in that release. You can pick up mrouted-3.4 at the following location: ftp.udel.edu:pub/mbone/mrouted-3.4.tar.gz There is a README-3.4 file in the same directory which explains everything about this release. If there are any questions or problems, please let me know. Ajit Thyagarajan From list-mgr@ISI.EDU Mon Mar 13 23:32:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 14 Mar 1995 07:34:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 14 Mar 1995 07:32:47 -0800 Received: from trout.nosc.mil by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 14 Mar 1995 07:32:46 -0800 Received: from jaws.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA02491; Tue, 14 Mar 95 07:32:34 PST Received: by jaws.nosc.mil (NX5.67e/NX3.0S) id AA00577; Tue, 14 Mar 95 07:32:32 -0800 Message-Id: <9503141532.AA00577@jaws.nosc.mil> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Ron Broersma Date: Tue, 14 Mar 95 07:32:29 -0800 To: Ajit Thyagarajan Subject: Re: New mrouted (version 3.4) available Cc: mbone Reply-To: ron@nosc.mil References: <9503140617.aa22712@beauregard.udel.edu> Ajit, mrouted doesn't like one of my networks. I get the following error: Mar 14 07:11:51 mbone mrouted[212]: warning - ignoring fa0, has invalid address (204.235.67.2) and/or mask (fffff000) Mar 14 07:11:51 mbone mrouted[212]: invalid phyint name 'fa0' in /etc/mrouted.conf I looked at the code and indeed it does not like the mask chosen for this network. It appears that the mrouted code has not been updated to be "classless". Can this be fixed? I think you just need to relax and/or remove most of the checks in the inet_valid_subnet routine in inet.c. No, this isn't something that just showed up in 3.4. We just happened to be readdressing our ATM network this morning and also saw your 3.4 announcement at the same time. --Ron From list-mgr@ISI.EDU Tue Mar 14 15:50:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 14 Mar 1995 07:58:40 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 14 Mar 1995 07:58:14 -0800 Received: from louie.udel.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 14 Mar 1995 07:58:12 -0800 Received: from snow-white-fddi.udel.edu by louie.udel.edu id aa14411; 14 Mar 95 10:53 EST Received: from louie.udel.edu by snow-white.ee.udel.edu id aa20010; 14 Mar 95 10:53 EST Received: from snow-white.ee.udel.edu by beauregard.udel.edu id aa22982; 14 Mar 95 15:50 GMT To: ron@nosc.mil Cc: mbone Subject: Re: New mrouted (version 3.4) available In-Reply-To: Your message of "Tue, 14 Mar 1995 07:32:29 PST." <9503141532.AA00577@jaws.nosc.mil> Date: Tue, 14 Mar 1995 15:50:20 +0000 From: Ajit Thyagarajan Message-Id: <9503141550.aa22982@beauregard.udel.edu> In message <9503141532.AA00577@jaws.nosc.mil>you wrote: >Ajit, > >mrouted doesn't like one of my networks. I get the following error: > >Mar 14 07:11:51 mbone mrouted[212]: warning - ignoring fa0, has invalid >address (204.235.67.2) and/or mask (fffff000) >Mar 14 07:11:51 mbone mrouted[212]: invalid phyint name 'fa0' in /etc/mrouted.conf > >I looked at the code and indeed it does not like the mask chosen for this >network. It appears that the mrouted code has not been updated to be >"classless". Can this be fixed? I think you just need to relax and/or >remove most of the checks in the inet_valid_subnet routine in inet.c. > >No, this isn't something that just showed up in 3.4. We just happened to >be readdressing our ATM network this morning and also saw your 3.4 >announcement at the same time. Thanks for pointing it out. This is being taken care of in the 3.5 release which should be out very soon. The 3.4 release was mainly to fix some urgent problems with 3.3 and so that Steve Casner can release his mtrace tool for debugging multicast traffic. The README-3.4 gives a description of some of the problems being fixed. Ajit From list-mgr@ISI.EDU Tue Mar 14 07:34:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 14 Mar 1995 09:35:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 14 Mar 1995 09:35:08 -0800 Received: from relay.hp.com by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 14 Mar 1995 09:34:59 -0800 Received: from it_750.ch.apollo.hp.com by relay.hp.com with SMTP (1.37.109.15/15.5+ECS 3.3) id AA273892498; Tue, 14 Mar 1995 09:34:58 -0800 Message-Id: <199503141734.AA273892498@relay.hp.com> Received: from dcetv.ch.apollo.hp.com by it_750.ch.apollo.hp.com for mbone@ISI.EDU id AA17160; Tue, 14 Mar 1995 12:34:57 -0500 X-Mailer: exmh version 1.5.3 12/28/94 To: Ajit Thyagarajan Cc: mbone Subject: Re: New mrouted (version 3.4) available In-Reply-To: Your message of "Tue, 14 Mar 1995 06:17:03 GMT." <9503140617.aa22712@beauregard.udel.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Mar 1995 12:34:56 -0500 From: John Brezak > > This is to announce the availability of version 3.4 of mrouted. This > is an interim release to fix some bugs that were important enough not > to wait for the planned version 3.5 full release of the multicast > routing extensions. This interim release includes only mrouted and no > kernel changes. This version (3.4) of mrouted will work *only* with a > kernel built using the ipmulti3.3-sunos413x.tar.gz and is meant to > replace the version of mrouted in that release. > > You can pick up mrouted-3.4 at the following location: > > ftp.udel.edu:pub/mbone/mrouted-3.4.tar.gz > > There is a README-3.4 file in the same directory which explains > everything about this release. > > If there are any questions or problems, please let me know. > > Ajit Thyagarajan > Here is a patch to 3.4 (Please consider these for the 3.5 release - Thanx) - Compile on SYSV based systems - Compile for NetBSD and FreeBSD (4.4Lite based systems) - Include changes for "clean" shutdown - Include Van's changes to mrinfo so that localhost is implied with no args *** defs.h.orig Tue Mar 14 08:27:22 1995 --- defs.h Tue Mar 14 12:31:59 1995 *************** *** 32,37 **** --- 32,38 ---- #include "vif.h" #include "route.h" #include "prune.h" + #include "pathnames.h" /* * Miscellaneous constants and macros. *************** *** 83,91 **** --- 84,94 ---- extern char s2[]; extern char s3[]; + #if !defined(__FreeBSD__) && !defined(__NetBSD__) extern int errno; extern int sys_nerr; extern char * sys_errlist[]; + #endif extern void log(); *** igmp.c.orig Tue Mar 14 08:25:54 1995 --- igmp.c Tue Mar 14 08:44:39 1995 *************** *** 41,46 **** --- 41,48 ---- k_set_loop(FALSE); /* disable multicast loopback */ ip = (struct ip *)send_buf; + ip->ip_hl = sizeof(struct ip) >> 2; + ip->ip_v = IPVERSION; ip->ip_tos = 0; ip->ip_off = 0; ip->ip_p = IPPROTO_IGMP; *************** *** 178,189 **** case DVMRP_PROBE: accept_probe(src, dst, ! (char *)(igmp+1), igmpdatalen, group); return; case DVMRP_REPORT: accept_report(src, dst, ! (char *)(igmp+1), igmpdatalen, group); return; case DVMRP_ASK_NEIGHBORS: --- 180,191 ---- case DVMRP_PROBE: accept_probe(src, dst, ! (char *)(igmp+1), igmpdatalen, ntohl(group)); return; case DVMRP_REPORT: accept_report(src, dst, ! (char *)(igmp+1), igmpdatalen, ntohl(group)); return; case DVMRP_ASK_NEIGHBORS: *************** *** 254,260 **** --- 256,266 ---- u_long group; int datalen; { + #if defined(__FreeBSD__) || defined(__NetBSD__) + static struct sockaddr_in sdst = {sizeof sdst, AF_INET}; + #else static struct sockaddr_in sdst = {AF_INET}; + #endif struct ip *ip; struct igmp *igmp; *** main.c.orig Tue Mar 14 08:31:53 1995 --- main.c Tue Mar 14 08:57:56 1995 *************** *** 24,33 **** extern char *configfilename; ! static char pidfilename[] = "/etc/mrouted.pid"; ! static char dumpfilename[] = "/usr/tmp/mrouted.dump"; ! static char cachefilename[] = "/usr/tmp/mrouted.cache"; ! static char genidfilename[] = "/usr/tmp/mrouted.genid"; int cache_lifetime = DEFAULT_CACHE_LIFETIME; int max_prune_lifetime = DEFAULT_CACHE_LIFETIME * 2; --- 24,33 ---- extern char *configfilename; ! static char pidfilename[] = _PATH_MROUTED_PID; ! static char dumpfilename[] = _PATH_MROUTED_DUMP; ! static char cachefilename[] = _PATH_MROUTED_CACHE; ! static char genidfilename[] = _PATH_MROUTED_GENID; int cache_lifetime = DEFAULT_CACHE_LIFETIME; int max_prune_lifetime = DEFAULT_CACHE_LIFETIME * 2; *************** *** 41,47 **** */ static void fasttimer(); static void timer(); ! static void hup(); static void dump(); static void fdump(); static void cdump(); --- 41,48 ---- */ static void fasttimer(); static void timer(); ! static void cleanup(); ! static void done(); static void dump(); static void fdump(); static void cdump(); *************** *** 60,66 **** --- 61,71 ---- struct timezone tzp; u_long prev_genid; + #ifdef SYSV + setvbuf(stderr, NULL, _IOLBF, 0); + #else setlinebuf(stderr); + #endif if (geteuid() != 0) { fprintf(stderr, "must be root\n"); *************** *** 107,117 **** --- 112,127 ---- (void)open("/", 0); (void)dup2(0, 1); (void)dup2(0, 2); + #ifdef TIOCNOTTY t = open("/dev/tty", 2); if (t >= 0) { (void)ioctl(t, TIOCNOTTY, (char *)0); (void)close(t); } + #else + if (setsid() < 0) + perror("setsid"); + #endif } else fprintf(stderr, "debug level %u\n", debug); *************** *** 125,131 **** --- 135,145 ---- log(LOG_NOTICE, 0, "mrouted version %d.%d", PROTOCOL_VERSION, MROUTED_VERSION); + #ifdef SYSV + srand48(time(NULL)); + #else srandom(gethostid()); + #endif /* * Get generation id *************** *** 168,175 **** (void)signal(SIGALRM, fasttimer); (void)signal(SIGHUP, restart); ! (void)signal(SIGTERM, hup); ! (void)signal(SIGINT, hup); (void)signal(SIGUSR1, fdump); (void)signal(SIGUSR2, cdump); if (debug != 0) --- 182,189 ---- (void)signal(SIGALRM, fasttimer); (void)signal(SIGHUP, restart); ! (void)signal(SIGTERM, done); ! (void)signal(SIGINT, done); (void)signal(SIGUSR1, fdump); (void)signal(SIGUSR2, cdump); if (debug != 0) *************** *** 311,325 **** /* * On hangup signal, let everyone know we're going away. */ ! static void hup() { ! log(LOG_INFO, 0, "hup"); expire_all_routes(); report_to_all_neighbors(ALL_ROUTES); ! exit(1); } - /* * Dump internal data structures to stderr. */ --- 325,344 ---- /* * On hangup signal, let everyone know we're going away. */ ! static void done() { ! log(LOG_INFO, 0, "done - quitting"); ! cleanup(); ! _exit(1); ! } ! ! static void cleanup() ! { expire_all_routes(); report_to_all_neighbors(ALL_ROUTES); ! k_stop_dvmrp(); } /* * Dump internal data structures to stderr. */ *************** *** 384,389 **** --- 403,410 ---- */ dvmrp_genid++; pruning = 1; + + atexit(cleanup); init_igmp(); k_init_dvmrp(); /* enable DVMRP routing in kernel */ *** mapper.c.orig Tue Mar 14 08:45:39 1995 --- mapper.c Tue Mar 14 08:46:36 1995 *************** *** 862,867 **** --- 862,870 ---- int addrlen = sizeof(addr); addr.sin_family = AF_INET; + #if defined(__FreeBSD__) || defined(__NetBSD__) + addr.sin_len = sizeof addr; + #endif addr.sin_addr.s_addr = dvmrp_group; addr.sin_port = htons(2000); /* any port over 1024 will do... */ if ((udp = socket(AF_INET, SOCK_DGRAM, 0)) < 0 *** mrinfo.c.orig Tue Mar 14 08:35:05 1995 --- mrinfo.c Tue Mar 14 08:47:06 1995 *************** *** 277,287 **** --- 277,299 ---- } + void + usage() + { + fprintf(stderr, + "Usage: mrinfo [-t timeout] [-r retries] router\n"); + exit(1); + } + int main(argc, argv) int argc; char *argv[]; { + #ifdef SYSV + setvbuf(stderr, NULL, _IOLBF, 0); + #else setlinebuf(stderr); + #endif if (geteuid() != 0) { fprintf(stderr, "must be root\n"); *************** *** 292,320 **** switch (argv[0][1]) { case 'd': if (!get_number(&debug, DEFAULT_DEBUG, &argv, &argc)) ! goto usage; break; case 'r': if (!get_number(&retries, -1, &argv, &argc)) ! goto usage; break; case 't': if (!get_number(&timeout, -1, &argv, &argc)) ! goto usage; break; default: ! goto usage; } argv++, argc--; } ! if (argc > 1 || (argc == 1 && !(target_addr = host_addr(argv[0])))) { ! usage: fprintf(stderr, ! "Usage: mrinfo [-t timeout] [-r retries] router\n"); ! exit(1); ! } if (target_addr == 0) ! goto usage; if (debug) fprintf(stderr, "Debug level %u\n", debug); --- 304,334 ---- switch (argv[0][1]) { case 'd': if (!get_number(&debug, DEFAULT_DEBUG, &argv, &argc)) ! usage(); break; case 'r': if (!get_number(&retries, -1, &argv, &argc)) ! usage(); break; case 't': if (!get_number(&timeout, -1, &argv, &argc)) ! usage(); break; default: ! usage(); } argv++, argc--; } ! if (argc > 1) ! usage(); ! if (argc == 1) ! target_addr = host_addr(argv[0]); ! else ! target_addr = host_addr("127.0.0.1"); ! if (target_addr == 0) ! usage(); if (debug) fprintf(stderr, "Debug level %u\n", debug); *************** *** 326,331 **** --- 340,348 ---- int addrlen = sizeof(addr); addr.sin_family = AF_INET; + #if defined(__FreeBSD__) || defined(__NetBSD__) + addr.sin_len = sizeof addr; + #endif addr.sin_addr.s_addr = target_addr; addr.sin_port = htons(2000); /* any port over 1024 will * do... */ *** mtrace.c.orig Tue Mar 14 08:37:18 1995 --- mtrace.c Tue Mar 14 08:48:03 1995 *************** *** 99,105 **** --- 99,109 ---- int addrlen = sizeof(addr); u_long lcl_addr = 0; /* in NET order */ + #ifdef SYSV + u_long qid = ((u_long)lrand48() >> 8); + #else u_long qid = ((u_long)random() >> 8); + #endif u_long qsrc = NULL; u_long qgrp = NULL; u_long qdst = NULL; *************** *** 209,214 **** --- 213,221 ---- /* Obtain the local address from which to send out packets */ addr.sin_family = AF_INET; + #if defined(__FreeBSD__) || defined(__NetBSD__) + addr.sin_len = sizeof addr; + #endif addr.sin_addr.s_addr = qgrp; addr.sin_port = htons(2000); *************** *** 268,274 **** struct timezone tzp; int count, recvlen, dummy = 0; ! register u_long src, group, smask; struct ip *ip; struct igmp *igmp; struct tr_resp *resp; --- 275,281 ---- struct timezone tzp; int count, recvlen, dummy = 0; ! register u_long src = 0, group, smask; struct ip *ip; struct igmp *igmp; struct tr_resp *resp; *** prune.c.orig Tue Mar 14 08:29:17 1995 --- prune.c Tue Mar 14 12:13:38 1995 *************** *** 21,27 **** --- 21,31 ---- /* * dither cache lifetime to obtain a value between x and 2*x */ + #ifdef SYSV + #define CACHE_LIFETIME(x) ((x) + (lrand48() % (x))) + #else #define CACHE_LIFETIME(x) ((x) + (random() % (x))) + #endif #define CHK_GS(x, y) { \ switch(x) { \ *************** *** 540,546 **** --- 544,558 ---- *p++ = ((char *)&(kt->kt_origin))[i]; for (i = 0; i < 4; i++) *p++ = ((char *)&(kt->kt_mcastgrp))[i]; + #ifdef BYTE_ORDER + #if BYTE_ORDER == BIG_ENDIAN for (i = 0; i < 4; i++) + #else /* BYTE_ORDER == LITTLE_ENDIAN */ + for (i = 3; i >= 0; i--) + #endif + #else + for (i = 0; i < 4; i++) + #endif *p++ = ((char *)&(kt->kt_prsent_timer))[i]; datalen += 12; *************** *** 600,606 **** ((char *)&prun_src)[i] = *p++; for (i = 0; i< 4; i++) ((char *)&prun_dst)[i] = *p++; ! for (i = 0; i< 4; i++) ((char *)&prun_tmr)[i] = *p++; kt = find_src_grp(prun_src, prun_dst); --- 612,626 ---- ((char *)&prun_src)[i] = *p++; for (i = 0; i< 4; i++) ((char *)&prun_dst)[i] = *p++; ! #ifdef BYTE_ORDER ! #if BYTE_ORDER == BIG_ENDIAN ! for (i = 0; i < 4; i++) ! #else /* BYTE_ORDER == LITTLE_ENDIAN */ ! for (i = 3; i >= 0; i--) ! #endif ! #else ! for (i = 0; i < 4; i++) ! #endif ((char *)&prun_tmr)[i] = *p++; kt = find_src_grp(prun_src, prun_dst); *** vif.c.orig Tue Mar 14 08:48:08 1995 --- vif.c Tue Mar 14 08:48:43 1995 *************** *** 570,575 **** --- 570,578 ---- int addrlen = sizeof(addr); addr.sin_family = AF_INET; + #if defined(__FreeBSD__) || defined(__NetBSD__) + addr.sin_len = sizeof addr; + #endif addr.sin_addr.s_addr = dst; addr.sin_port = htons(2000); /* any port over 1024 will do... */ if ((udp = socket(AF_INET, SOCK_DGRAM, 0)) < 0 *************** *** 653,658 **** --- 656,664 ---- int addrlen = sizeof(addr); addr.sin_family = AF_INET; + #if defined(__FreeBSD__) || defined(__NetBSD__) + addr.sin_len = sizeof addr; + #endif addr.sin_addr.s_addr = dst; addr.sin_port = htons(2000); /* any port over 1024 will do... */ if ((udp = socket(AF_INET, SOCK_DGRAM, 0)) < 0 *** /dev/null Tue Mar 14 12:14:07 1995 --- pathnames.h Tue Mar 14 08:43:06 1995 *************** *** 0 **** --- 1,25 ---- + /* + * The mrouted program is covered by the license in the accompanying file + * named "LICENSE". Use of the mrouted program represents acceptance of + * the terms and conditions listed in that file. + * + * The mrouted program is COPYRIGHT 1989 by The Board of Trustees of + * Leland Stanford Junior University. + * + * + * $Id: pathnames.h,v 1.1 1994/01/11 20:16:00 brezak Exp $ + */ + + #define _PATH_MROUTED_CONF "/etc/mrouted.conf" + + #if defined(__FreeBSD__) || defined(__NetBSD__) + #define _PATH_MROUTED_PID "/var/run/mrouted.pid" + #define _PATH_MROUTED_DUMP "/var/tmp/mrouted.dump" + #define _PATH_MROUTED_CACHE "/var/run/mrouted.cache" + #define _PATH_MROUTED_GENID "/var/run/mrouted.genid" + #else + #define _PATH_MROUTED_PID "/etc/mrouted.pid" + #define _PATH_MROUTED_DUMP "/usr/tmp/mrouted.dump" + #define _PATH_MROUTED_CACHE "/etc/mrouted.cache" + #define _PATH_MROUTED_GENID "/etc/mrouted.genid" + #endif =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5140 From list-mgr@ISI.EDU Tue Mar 14 01:40:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 14 Mar 1995 09:46:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 14 Mar 1995 09:46:38 -0800 Received: from Sun.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 14 Mar 1995 09:46:36 -0800 Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA04593; Tue, 14 Mar 95 09:44:01 PST Received: from jurassic.Eng.Sun.COM (jurassic-52.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16295; Tue, 14 Mar 1995 09:40:28 -0800 Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA23248; Tue, 14 Mar 1995 09:40:20 -0800 Received: by bobo.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA06066; Tue, 14 Mar 1995 09:40:11 -0800 Date: Tue, 14 Mar 1995 09:40:11 -0800 From: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Message-Id: <199503141740.JAA06066@bobo.Eng.Sun.COM> To: ron@nosc.mil, ajit@louie.udel.edu Subject: Re: New mrouted (version 3.4) available Cc: mbone Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" > I looked at the code and indeed it does not like the mask chosen for this > network. It appears that the mrouted code has not been updated to be > "classless". Can this be fixed? I think you just need to relax and/or > remove most of the checks in the inet_valid_subnet routine in inet.c. It is not sufficient to fix mrouted. The kernel is "classfull" as well in that it uses in_netof() for the hash in the route cache. This means that supernet routes will not work. It would be good to fix both the kernel and mrouted so that they can live in a classless world. Erik From list-mgr@ISI.EDU Wed Mar 15 11:29:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 01:38:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 01:37:36 -0800 Received: from mgate.uni-hannover.de by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 01:36:25 -0800 Received: from helios.tnt.uni-hannover.de by mgate.uni-hannover.de with SMTP (PP); Wed, 15 Mar 1995 10:31:16 +0100 Received: from ikarus.tnt.uni-hannover.de by helios.tnt.uni-hannover.de (4.1/SMI-4.1) id AA19996; Wed, 15 Mar 95 10:29:06 +0100 Date: Wed, 15 Mar 95 10:29:06 +0100 From: bloemer@tnt.uni-hannover.de (Arnold Bloemer) Message-Id: <9503150929.AA19996@helios.tnt.uni-hannover.de> To: mbone, rem-conf@es.net Subject: TV Show from CeBIT'95 in MBone, Today at 15:00 GMT Cc: ten@ipsun.ras.ru, Stefan.Hild@cl.cam.ac.uk, mcneil@rum.ee.umanitoba.ca, Lance.Berc@src.dec.com, setala@axil.mdata.fi, robert@psy.uq.oz.au Today we will broadcast our last tv show from CeBIT'95. We will try to overlay the audio with an english translation. On last Saturday we had a great succes, when we demonstrated MBone in german tv. Many thanks again to all, who participated, especially to Wieland Hoffelder in Berkeley and Mark Prior in Adelaide, who participated via MBone interactively in our tv show. Today the tv station would like to shortly summarize the tv MBone activities. It would be very good if we good finally present again MBone members participating in the show via MBone and sitting far away from Germany. So if you can spend the time please go online, if possible send video and write some nice comments about the show on our whiteboard. Because we will only have a few minutes in the show it would be good to know about participants who we could talk with and who could send video during the show. Test for the show will start at 14:45 GMT. If you would like to become a little bit more famous at least in Germany please reply to this mail or just go online at approximately 14:45 GMT. Arnold ________________________________________________________________________________ Dipl.-Ing. Arnold Bloemer Universitaet Hannover Institut fuer Theoretische Nachrichtentechnik bloemer@tnt.uni-hannover.de und Informationsverarbeitung (TNT) fax: +49 511 762-5333 Appelstrasse 9A phone: +49 511 762-5320 D-30167 Hannover http://www.tnt.uni-hannover.de/wiss/bloemer.html Germany ________________________________________________________________________________ From list-mgr@ISI.EDU Wed Mar 15 14:52:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 06:53:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 06:53:15 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 06:53:14 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 15 Mar 1995 06:53:06 -0800 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 15 Mar 1995 14:52:31 +0000 To: mbone Subject: bagnet@baglady.atg.apple.com is sernding more on mbone audio Date: Wed, 15 Mar 95 14:52:27 +0000 Message-Id: <14510.795279147@cs.ucl.ac.uk> From: Jon Crowcroft using 64kbps of continuous bandwidth to send an audio rendition of a repetetive message in morse code is a very poor use of internet resources, and information theory tells us that its probably the wrong approach to getting Apple's user friendly image across whereas this email isn't. jon From list-mgr@ISI.EDU Wed Mar 15 06:33:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 08:34:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 08:33:28 -0800 Received: from oit.gatech.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 08:33:27 -0800 Received: (from ccoprmm@localhost) by oit.gatech.edu (8.6.11/8.6.11) id LAA10503 for mbone@isi.edu; Wed, 15 Mar 1995 11:33:26 -0500 From: Michael.Mealling@oit.gatech.edu (Michael Mealling) Message-Id: <199503151633.LAA10503@oit.gatech.edu> Subject: BellSouth Conference Keynote speaker: Adam Curry To: mbone Date: Wed, 15 Mar 1995 11:33:25 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 450 BellSouth is broadcasting a special presentation of Adam Curry showing off the Internet. This session should last from 12:00 EST to 1:30 EST. If you have any questions please forward them to ron.stanton@svtlab.bls.com. -MM -- ------------------------------------------------------------------------------
Michael Mealling
michael.mealling@oit.gatech.edu
From list-mgr@ISI.EDU Wed Mar 15 19:16:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 09:17:26 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 09:16:47 -0800 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 09:16:46 -0800 Received: from by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AB12356; Wed, 15 Mar 95 09:16:32 PST Message-Id: <9503151716.AB12356@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Mar 1995 18:16:36 +0100 To: mbone From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Hopwise Reliable Multicast Cc: Jon Knight , ammar@cc.gatech.edu (Mostafa Ammar) Some time ago (November '94?) I distributed a note to this list that discussed an approach that I was pursuing to distribute WWW pages using multicast. I continued to flesh out some of these ideas and put them into a paper for the WWW'95 conference upcoming in Darmstadt. This paper can be found at: http://www-atp.llnl.gov/atp/papers/HRM/HRM.html or in Europe on a mirror site at www-ks.rus.uni-stuttgart.de The idea is very simple, so perhaps you need not read the paper to comment. It suggests: 1. Mirroring of WWW pages explicitly on servers so that for popular pages, there is a server for them on all the relatively large LANs (e.g. universities, companies, etc.). This approach is focused on pages like those for magazines that are popular and relatively static once "published". See, for example, the media page in the comp-comm.html set (in the signature below) for example publications such as those from CMP and Ziff-Davis. However, many popular WWW pages are cantidates. 2. The part that may be of more interest to the readers of this list is the idea of "Hopwise Reliable Multicast." Basically it is suggested that for applications that don't have strong time constraints (e.g. probably NOT real time multimedia that has seen the bulk of the focus to date on MBone) TCP can be used on a hop by hop basis across a multicast distribution tree such as that constructed by cooperation among mrouted processes on the current MBone. In fact I propose using an extended version of mrouted for setting up (at least) the TCP connections. I believe pretty strongly (at present anyway) in the value of this type of multicast for non real time applications requiring the reliability of a "transport" protocol. I would like to take the position of defending it (hopefully initially privately) from comments/criticism by those on this list. Anyone that is serious about commenting will probably gain some insight by reading or at least scanning the paper, but I will be happy to entertain non serious comments. I recommend this "Hopwise Reliable" approach also for other non realtime reliable multicast applications (software mirroring, Usenet news [?], etc.). Any comments are naturally appreciated. If there are responces I will undertake to summarize the comments to the list after a reasonable period of time. I should confess here that there is little possibility that I will be able to do any serious implementation work on this approach in the near future. I expect to be moving soon from Germany back to the US and I am not sure what my work situation will be when I return. However, if anyone finds this approach interesting I will be happy to work with them, support them, whatever. James E. (Jed) Donnelley - http://www-atp.llnl.gov/atp/jed.html Advanced Telecom. Prog. - http://www-atp.llnl.gov/atp/atp.html LAWRENCE LIVERMORE LAB. - http://www.llnl.gov/ Until 4/95 at Uni-Stuttgart - http://www.uni-stuttgart.de/ jed@llnl.gov - http://www-atp.llnl.gov/atp/comp-comm.html <- Enter also the more general: http://www-atp.llnl.gov/atp/link.html and http://www-ca.llnl.gov/california/calif-map.html From list-mgr@ISI.EDU Wed Mar 15 06:23:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 10:28:00 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 10:27:23 -0800 Received: from newton.ncsa.uiuc.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 10:27:22 -0800 Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA11098 (5.65a/IDA-1.4.2 for mbone@isi.edu); Wed, 15 Mar 95 12:25:54 -0600 Return-Path: Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1) id AA01816; Wed, 15 Mar 95 12:23:52 CST Message-Id: <9503151823.AA01816@void.ncsa.uiuc.edu> Subject: WWW Fall '94 Tapes (fwd) To: mbone Date: Wed, 15 Mar 1995 12:23:52 -0600 (CST) From: Daniel Simms X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1585 Sorry for the delay, but the original note got lost somehow. These are the times and dates of the tapes to be rebroadcast. If there are any problems, please mail me (dsimms@ncsa.uiuc.edu) about it. For Europe: Tape Date Local Time Universal Time "First Plenary Session" Mon Mar 20 05:00:00 CST 11:00:00 GMT "Security on the web" Tue Mar 21 04:00:00 CST 10:00:00 GMT "Commerce" Tue Mar 21 05:30:00 CST 11:30:00 GMT "Publishing" Wed Mar 22 04:00:00 CST 10:00:00 GMT "Authoring" Wed Mar 22 05:30:00 CST 11:30:00 GMT "HTML & SGML" Thu Mar 23 04:00:00 CST 10:00:00 GMT "WWW / Mosaic" Thu Mar 23 05:30:00 CST 11:30:00 GMT For West Coast, Austrailia, East Asia: Tape Date Local Time Universal Time "Plenary Session" Mon Mar 20 16:00:00 CST 22:00:00 GMT "Security on the web" Tue Mar 21 16:00:00 CST 22:00:00 GMT "Commerce" Tue Mar 21 17:30:00 CST 23:30:00 GMT "Publishing" Wed Mar 22 16:00:00 CST 22:00:00 GMT "Authoring" Wed Mar 22 17:30:00 CST 23:30:00 GMT "HTML & SGML" Thu Mar 23 16:00:00 CST 22:00:00 GMT "WWW / Mosaic" Thu Mar 23 17:30:00 CST 23:30:00 GMT Cheers, dan -- Daniel Simms "A common mistake that people make when trying to design dsimms@uiuc.edu something completely foolproof [is] to underestimate the (217) 328-7060 ingenuity of complete fools" -Ford Prefect From list-mgr@ISI.EDU Wed Mar 15 09:46:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 11:46:56 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 11:46:23 -0800 Received: from noc.sura.net by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 11:46:22 -0800 Received: from aotearoa.sura.net (aotearoa.sura.net [128.167.254.175]) by noc.sura.net (8.6.8.1/8.6.6) with ESMTP id OAA23099 for ; Wed, 15 Mar 1995 14:46:21 -0500 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by aotearoa.sura.net (8.6.10/8.6.10) with SMTP id OAA01613 for ; Wed, 15 Mar 1995 14:46:20 -0500 Message-Id: <199503151946.OAA01613@aotearoa.sura.net> X-Authentication-Warning: aotearoa.sura.net: Host LOCALHOST didn't use HELO protocol To: mbone Subject: Network monitoring tool Date: Wed, 15 Mar 1995 14:46:20 -0500 From: Erik Sherk Hi, Some time ago I saw a note about a network monitoring tool that sniffed the local wire and printed out a "top" type display breaking down the traffic by services and protocol. Someone had hacked it to report multicast traffic. Does anyhone remember the name of the program? Thanks... Erik From list-mgr@ISI.EDU Wed Mar 15 09:46:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 11:46:56 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 11:46:23 -0800 Received: from noc.sura.net by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 11:46:22 -0800 Received: from aotearoa.sura.net (aotearoa.sura.net [128.167.254.175]) by noc.sura.net (8.6.8.1/8.6.6) with ESMTP id OAA23099 for ; Wed, 15 Mar 1995 14:46:21 -0500 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by aotearoa.sura.net (8.6.10/8.6.10) with SMTP id OAA01613 for ; Wed, 15 Mar 1995 14:46:20 -0500 Message-Id: <199503151946.OAA01613@aotearoa.sura.net> X-Authentication-Warning: aotearoa.sura.net: Host LOCALHOST didn't use HELO protocol To: mbone Subject: Network monitoring tool Date: Wed, 15 Mar 1995 14:46:20 -0500 From: Erik Sherk Hi, Some time ago I saw a note about a network monitoring tool that sniffed the local wire and printed out a "top" type display breaking down the traffic by services and protocol. Someone had hacked it to report multicast traffic. Does anyhone remember the name of the program? Thanks... Erik From list-mgr@ISI.EDU Wed Mar 15 10:47:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 12:51:00 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 12:50:44 -0800 Received: from Princeton.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 12:50:41 -0800 Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.115/princeton) id AA19012; Wed, 15 Mar 95 15:47:21 -0500 Received: from flagstaff.Princeton.EDU by ponyexpress.princeton.edu (8.6.9/1.7/newPE) id PAA06749; Wed, 15 Mar 1995 15:47:20 -0500 Received: by flagstaff.Princeton.EDU (4.1/Phoenix_Cluster_Client) id AA27765; Wed, 15 Mar 95 15:47:19 EST Message-Id: <9503152047.AA27765@flagstaff.Princeton.EDU> From: rshigeta@phoenix.Princeton.EDU (Ronald T. Shigeta) Date: Wed, 15 Mar 1995 15:47:18 EST X-Mailer: Mail User's Shell (7.2.2 3/2/90) To: mbone Subject: unsubscribe unsubscribe unsubscribe mbone unsubscribe me! Ron -- | Ron Shigeta rshigeta@phoenix.Princeton.edu | Frick Labs | Princeton University From list-mgr@ISI.EDU Wed Mar 15 14:40:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 18:43:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 18:42:11 -0800 Received: from fnal.fnal.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 18:42:08 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HO6FEEXU5C00FFQB@FNAL.FNAL.GOV>; Wed, 15 Mar 1995 20:41:57 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA06925; Wed, 15 Mar 95 20:40:52 CST Date: Wed, 15 Mar 1995 20:40:52 -0600 From: Matt Crawford Subject: rlss2.riken.go.jp is sending IGMP membership reports with TTL > 1 Sender: crawdad@munin.fnal.gov To: postmaster@rlss2.riken.go.jp Cc: mbone Message-Id: <9503160240.AA06925@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ 1. This is generally a sign that the kernel was built with inconsistent options for the multicast code. Rebuilding the kernel after a "make clean" may fix it. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From list-mgr@ISI.EDU Wed Mar 15 18:08:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 20:08:56 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 20:08:41 -0800 Received: from amber.ccs.neu.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 20:08:40 -0800 Received: from funhouse.drave.org (funhouse.drave.org [129.10.117.106]) by amber.ccs.neu.edu (8.6.10/8.6.4) with SMTP id XAA09234; Wed, 15 Mar 1995 23:08:35 -0500 Date: Wed, 15 Mar 1995 23:08:35 -0500 Message-Id: <199503160408.XAA09234@amber.ccs.neu.edu> X-Sender: ivan@amber.ccs.neu.edu X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Erik Sherk , mbone From: ivan@ccs.neu.edu (Ivan Judson) Subject: Re: Network monitoring tool ipwatch does that as I remember, I have a copy if the author doesn't respond... --Ivan At 02:46 PM 3/15/95 -0500, Erik Sherk wrote: >Hi, > Some time ago I saw a note about a network monitoring tool >that sniffed the local wire and printed out a "top" type display >breaking down the traffic by services and protocol. Someone had >hacked it to report multicast traffic. Does anyhone remember the >name of the program? Thanks... > >Erik > > > > Ivan R. Judson "This is my mind; welcome to hell." Math/Computer Science ivan@ccs.neu.edu Argonne National Lab judson@mcs.anl.gov From list-mgr@ISI.EDU Wed Mar 15 18:08:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 20:08:56 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 20:08:41 -0800 Received: from amber.ccs.neu.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 15 Mar 1995 20:08:40 -0800 Received: from funhouse.drave.org (funhouse.drave.org [129.10.117.106]) by amber.ccs.neu.edu (8.6.10/8.6.4) with SMTP id XAA09234; Wed, 15 Mar 1995 23:08:35 -0500 Date: Wed, 15 Mar 1995 23:08:35 -0500 Message-Id: <199503160408.XAA09234@amber.ccs.neu.edu> X-Sender: ivan@amber.ccs.neu.edu X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Erik Sherk , mbone From: ivan@ccs.neu.edu (Ivan Judson) Subject: Re: Network monitoring tool ipwatch does that as I remember, I have a copy if the author doesn't respond... --Ivan At 02:46 PM 3/15/95 -0500, Erik Sherk wrote: >Hi, > Some time ago I saw a note about a network monitoring tool >that sniffed the local wire and printed out a "top" type display >breaking down the traffic by services and protocol. Someone had >hacked it to report multicast traffic. Does anyhone remember the >name of the program? Thanks... > >Erik > > > > Ivan R. Judson "This is my mind; welcome to hell." Math/Computer Science ivan@ccs.neu.edu Argonne National Lab judson@mcs.anl.gov From list-mgr@ISI.EDU Thu Mar 16 01:06:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 03:07:35 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 03:06:41 -0800 Received: from noc.sura.net ([192.80.214.100]) by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 03:06:40 -0800 Received: from aotearoa.sura.net (aotearoa.sura.net [128.167.254.175]) by noc.sura.net (8.6.8.1/8.6.6) with ESMTP id GAA16704; Thu, 16 Mar 1995 06:06:31 -0500 Received: from localhost (localhost [127.0.0.1]) by aotearoa.sura.net (8.6.10/8.6.10) with SMTP id GAA02570; Thu, 16 Mar 1995 06:06:30 -0500 Message-Id: <199503161106.GAA02570@aotearoa.sura.net> X-Authentication-Warning: aotearoa.sura.net: Host localhost didn't use HELO protocol To: ivan@ccs.neu.edu (Ivan Judson) Cc: mbone Subject: Re: Network monitoring tool In-Reply-To: Your message of "Wed, 15 Mar 1995 23:08:35 EST." <199503160408.XAA09234@amber.ccs.neu.edu> Date: Thu, 16 Mar 1995 06:06:30 -0500 From: Erik Sherk Ivan, I think you got it! Could you send me a URL? Thanks... Erik P.S. Thanks to all the others who sent pointers to usefull software.... > > ipwatch does that as I remember, I have a copy if the author doesn't respond. .. > > --Ivan > > At 02:46 PM 3/15/95 -0500, Erik Sherk wrote: > >Hi, > > Some time ago I saw a note about a network monitoring tool > >that sniffed the local wire and printed out a "top" type display > >breaking down the traffic by services and protocol. Someone had > >hacked it to report multicast traffic. Does anyhone remember the > >name of the program? Thanks... > > > >Erik > > > > > > > > > Ivan R. Judson "This is my mind; welcome to hell." > Math/Computer Science ivan@ccs.neu.edu > Argonne National Lab judson@mcs.anl.gov > From list-mgr@ISI.EDU Thu Mar 16 06:16:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 06:17:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 06:16:56 -0800 Received: from ns.riken.go.jp by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 06:16:54 -0800 Received: from rikax1.riken.go.jp by ns.riken.go.jp (8.6.8.1/TISN-1.3M/R2) id XAA00428; Thu, 16 Mar 1995 23:16:52 +0900 Received: by rikax1.riken.go.jp (MX V4.1 AXP) id 95; Thu, 16 Mar 1995 23:17:30 JST Date: Thu, 16 Mar 1995 23:17:29 JST From: "Takashi Ichihara " To: MBONE Cc: ichihara@rikax1.riken.go.jp Message-Id: <0098D77C.929AB139.95@rikax1.riken.go.jp> Subject: Re: rlss2.riken.go.jp is sending IGMP membership reports with TTL > 1 Matt Crawford writes: >rlss2.riken.go.jp is sending IGMP membership reports with TTL > 1. >This is generally a sign that the kernel was built with inconsistent >options for the multicast code. Rebuilding the kernel after a >"make clean" may fix it. Thank you for the information and suggestion. We are sorry for causing problem. We have temporary disconnected the rlss2.riken.go.jp from the mbone, until the problem has been cleared. Best Regard Takashi Ichihara Radiation lab/Accelerator Research Facility RIKEN (The Institute of Physical and Chemical Research) 2-1, Hirosawa, Wako, 351-01, Japan (Internet/Bintet) Ichihara@rikvax.riken.go.jp (HEPnet/span) RIKEN::ICHIHARA (41910::Ichihara) From list-mgr@ISI.EDU Thu Mar 16 04:22:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 06:23:35 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 06:22:56 -0800 Received: from amber.ccs.neu.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 06:22:54 -0800 Received: from bodum.ccs.neu.edu (bodum.ccs.neu.edu [129.10.113.198]) by amber.ccs.neu.edu (8.6.10/8.6.4) with SMTP id JAA24236; Thu, 16 Mar 1995 09:22:51 -0500 Date: Thu, 16 Mar 1995 09:22:51 -0500 Message-Id: <199503161422.JAA24236@amber.ccs.neu.edu> X-Sender: ivan@amber.ccs.neu.edu X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Erik Sherk From: ivan@ccs.neu.edu (Ivan Judson) Subject: Re: Network monitoring tool Cc: mbone Wow, I've gotten alot of mail about this already -- Since I was silly enough to forget one, here's where it is: ftp://ftp.ccs.neu.edu/pub/people/ivan/ipwatch-1.3.tar.Z --Ivan PS the original authors address is in the ipwatch.c file, but if you hack on it, send me the diffs? I'll roll them in and maybe get this pretty'd up or something. At 06:06 AM 3/16/95 -0500, Erik Sherk wrote: >Ivan, > I think you got it! Could you send me a URL? Thanks... > >Erik > >P.S. Thanks to all the others who sent pointers to usefull software.... >> >> ipwatch does that as I remember, I have a copy if the author doesn't respond. >.. >> >> --Ivan >> >> At 02:46 PM 3/15/95 -0500, Erik Sherk wrote: >> >Hi, >> > Some time ago I saw a note about a network monitoring tool >> >that sniffed the local wire and printed out a "top" type display >> >breaking down the traffic by services and protocol. Someone had >> >hacked it to report multicast traffic. Does anyhone remember the >> >name of the program? Thanks... >> > >> >Erik >> > >> > >> > >> > >> Ivan R. Judson "This is my mind; welcome to hell." >> Math/Computer Science ivan@ccs.neu.edu >> Argonne National Lab judson@mcs.anl.gov >> > > Ivan R. Judson "This is my mind; welcome to hell." Math/Computer Science ivan@ccs.neu.edu Argonne National Lab judson@mcs.anl.gov From list-mgr@ISI.EDU Thu Mar 16 04:51:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 06:53:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 06:52:03 -0800 Received: from cayman.Cayman.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 06:52:02 -0800 Received: from cancun.Cayman.COM (cancun.Cayman.COM [143.137.137.2]) by cayman.Cayman.COM (8.6.8.1/ECB-MAIN-1.16) with ESMTP id JAA19672 for ; Thu, 16 Mar 1995 09:52:01 -0500 Received: (churchb@localhost) by cancun.Cayman.COM (8.6.8.1/ECB-SUB-1.2) id JAA25822 for mbone@isi.edu; Thu, 16 Mar 1995 09:51:59 -0500 From: Ben Church Message-Id: <199503161451.JAA25822@cancun.Cayman.COM> Subject: Please unsubscribe an old address To: mbone Date: Thu, 16 Mar 1995 09:51:58 -0500 (EST) X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 34 unsubscribe mbone josh@cayman.com From list-mgr@ISI.EDU Thu Mar 16 08:55:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 16:56:01 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 16:56:00 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14582(3)>; Thu, 16 Mar 1995 16:55:51 PST Received: by crevenia.parc.xerox.com id <49859>; Thu, 16 Mar 1995 16:55:42 -0800 From: Bill Fenner To: mbone-na Subject: Someone at 139.169.65.140 is advertising Mbone Audio Message-Id: <95Mar16.165542pst.49859@crevenia.parc.xerox.com> Date: Thu, 16 Mar 1995 16:55:39 PST Someone inside Johnson Space Center (no way to know who, since there is no PTR record for 140.65.169.139.in-addr.arpa and the host rejects finger, telnet and smtp attempts) is advertising MBone Audio as if they were the creator of the session, causing two copies of MBone Audio to appear on peoples' sd screens. The most likely cause of this is .sd_cache corruption (perhaps by editing it manually without knowing what all the fields mean). In any case, it would probably best for whomever this person is to quit sd, remove their .sd_cache file, and restart sd. Bill From list-mgr@ISI.EDU Fri Mar 17 01:48:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 17:51:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 17:50:59 -0800 Received: from maila.surrey.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 16 Mar 1995 17:50:55 -0800 Received: from ee.surrey.ac.uk (actually ainur-gate.ee.surrey.ac.uk) by maila.surrey.ac.uk with SMTP (PP); Fri, 17 Mar 1995 01:50:47 +0000 Received: from eros.ee.surrey.ac.uk by ainur.ee.surrey.ac.uk via Ethernet with SMTP id aa03156; 17 Mar 95 1:50 GMT Subject: subscribe To: mbone Date: Fri, 17 Mar 1995 01:48:38 +0000 (GMT) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 69 From: A.Sadka@ee.surrey.ac.uk Sender: A.Sadka@ee.surrey.ac.uk Message-Id: <9503170148.aa07734@eros.ee.surrey.ac.uk> would u add me on the mailing list please ? thanx in advance, Abdul. From list-mgr@ISI.EDU Thu Mar 16 10:00:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 05:30:32 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 05:28:56 -0800 Received: from amsaa-cleo.arl.mil by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 05:28:55 -0800 Date: Thu, 16 Mar 95 15:00:19 EST From: "Wallace E. Hughes Jr., AMSAA/CID/SIMB, phone:410-278-5336" To: Ivan Judson Cc: Erik Sherk , mbone Subject: Re: Network monitoring tool Message-Id: <9503161500.aa04328@AMSAA-CLEO.ARL.MIL> >Wow, I've gotten alot of mail about this already -- >Since I was silly enough to forget one, here's where it >is: >ftp://ftp.ccs.neu.edu/pub/people/ivan/ipwatch-1.3.tar.Z >--Ivan Ivan, The net directory is missing, and the associated files: ipwatch.h:22: net/nit.h: No such file or directory ipwatch.h:23: net/nit_if.h: No such file or directory ipwatch.h:24: net/nit_buf.h: No such file or directory wally From list-mgr@ISI.EDU Fri Mar 17 13:41:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 05:43:17 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 05:42:56 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 05:42:53 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id NAA12810; Fri, 17 Mar 1995 13:41:24 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id NAA07812; Fri, 17 Mar 1995 13:41:21 GMT Date: Fri, 17 Mar 1995 13:41:20 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: "Wallace E. Hughes Jr., AMSAA/CID/SIMB, phone:410-278-5336" Cc: Ivan Judson , Erik Sherk , mbone Subject: Re: Network monitoring tool In-Reply-To: <9503161500.aa04328@AMSAA-CLEO.ARL.MIL> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 16 Mar 1995, Wallace E. Hughes Jr., AMSAA/CID/SIMB, phone:410-278-5336 wrote: > >Wow, I've gotten alot of mail about this already -- > > >Since I was silly enough to forget one, here's where it > >is: > > >ftp://ftp.ccs.neu.edu/pub/people/ivan/ipwatch-1.3.tar.Z > > >--Ivan > > Ivan, > > The net directory is missing, and the associated files: > > ipwatch.h:22: net/nit.h: No such file or directory > ipwatch.h:23: net/nit_if.h: No such file or directory > ipwatch.h:24: net/nit_buf.h: No such file or directory They look like standard include files which you would find in /usr/include/net. At least they do on my machine running SunOS. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Fri Mar 17 15:42:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 05:46:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 05:45:38 -0800 Received: from felix.crihan.fr (felix-f.crihan.fr) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 05:45:31 -0800 Received: from hal.crihan.fr (hal.crihan.fr [192.93.25.15]) by felix.crihan.fr (8.6.10/8.6.10) with ESMTP id OAA00479; Fri, 17 Mar 1995 14:45:11 +0100 Received: (from am@localhost) by hal.crihan.fr (8.6.6.Beta9/8.6.6.Beta11) id OAA27217; Fri, 17 Mar 1995 14:45:06 +0100 Date: Fri, 17 Mar 1995 14:42:03 +0100 (MET) From: Alain Massiot Subject: Vat - Unicast mode under Solaris 2.4 To: mbone Cc: am@crihan.fr Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi , Could somebody give me the way to use Vat in unicast mode between to Sun workstations running Solaris 2.4 ?? Did Sun correct in 2.4 release the bug concerning unicast with Vat under Solaris 2.3 ?? Regards .. --------------------------------------------------------------------- Alain Massiot | C R I H A N | Centre de Ressources Informatiques Phone: +33 35 59 61 59 | de Haute Normandie Fax : +33 35 59 61 40 | Parc Technologique de la Vatine Mail : Alain.Massiot@crihan.fr | 32, rue Raymond Aron Info : crihan-admin@crihan.fr | 76130 Mont-Saint-Aignan, France --------------------------------------------------------------------- From list-mgr@ISI.EDU Fri Mar 17 04:14:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 06:19:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 06:18:43 -0800 Received: from mwunix.mitre.org by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 06:18:42 -0800 Return-Path: slr@fluky.mitre.org Received: from fluky.mitre.org (fluky.mitre.org [128.29.113.24]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id JAA24160 for ; Fri, 17 Mar 1995 09:18:41 -0500 Received: from murky.mitre.org.noname by fluky.mitre.org (4.1/SMI-4.0) id AA22735; Fri, 17 Mar 95 09:14:22 EST Date: Fri, 17 Mar 95 09:14:22 EST From: slr@fluky.mitre.org (Soochon Radee) Message-Id: <9503171414.AA22735@fluky.mitre.org> To: mbone Subject: multicast over P2P Can mrouted work over a point-to-point interface (either PPP or SLIP) in tunnel or querier mode? I have two subnets connected by a serial link and would like to have the endpoints take care of unicast and multicast routing. From list-mgr@ISI.EDU Fri Mar 17 05:11:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 07:13:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 07:13:30 -0800 Received: from oit.gatech.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 07:13:29 -0800 Received: (from ccoprmm@localhost) by oit.gatech.edu (8.6.11/8.6.11) id KAA00414; Fri, 17 Mar 1995 10:11:53 -0500 From: Michael.Mealling@oit.gatech.edu (Michael Mealling) Message-Id: <199503171511.KAA00414@oit.gatech.edu> Subject: Re: Network monitoring tool To: Graeme.Wood@ucs.ed.ac.uk Date: Fri, 17 Mar 1995 10:11:52 -0500 (EST) Cc: wally@arl.mil, ivan@ccs.neu.edu, sherk@sura.net, mbone In-Reply-To: from "Graeme Wood" at Mar 17, 95 01:41:20 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 922 Graeme Wood said this: > On Thu, 16 Mar 1995, Wallace E. Hughes Jr., AMSAA/CID/SIMB, phone:410-278-5336 wrote: > > >ftp://ftp.ccs.neu.edu/pub/people/ivan/ipwatch-1.3.tar.Z > > > > The net directory is missing, and the associated files: > > > > ipwatch.h:22: net/nit.h: No such file or directory > > ipwatch.h:23: net/nit_if.h: No such file or directory > > ipwatch.h:24: net/nit_buf.h: No such file or directory > > They look like standard include files which you would find in > /usr/include/net. At least they do on my machine running SunOS. This happens on Solaris machines. Does anyone know of a Solaris version? I'd do it myself by IETF is close and I'm trying to get drafts out.... -MM -- ------------------------------------------------------------------------------
Michael Mealling
michael.mealling@oit.gatech.edu
From list-mgr@ISI.EDU Fri Mar 17 06:06:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 08:12:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 08:08:16 -0800 Received: from lupine.nsi.nasa.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 08:08:14 -0800 Received: (from mnewell@localhost) by lupine.nsi.nasa.gov (8.6.9/8.6.9) id LAA02580; Fri, 17 Mar 1995 11:07:00 -0500 Date: Fri, 17 Mar 1995 11:06:52 -0500 (EST) From: "Michael C. Newell" To: Soochon Radee Cc: mbone Subject: Re: multicast over P2P In-Reply-To: <9503171414.AA22735@fluky.mitre.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 17 Mar 1995, Soochon Radee wrote: > Can mrouted work over a point-to-point interface (either PPP or SLIP) > in tunnel or querier mode? I have two subnets connected by a serial link > and would like to have the endpoints take care of unicast and multicast > routing. I've been using your FreeBSD patches to do what I think you're asking; what I have is: +-----+-----------------------------+-------------+ 198.116.75.0 | | +-------+--------+ +--------+--------+ | FreeBSD 2.1.0D | | FreeBSD 1.1.5.1 | | mcn-test1 | | mcn-fbsd | +----------------+ +-------+---------+ | | / 28.8Kbs SLIP line | | +-----------------+ +---------+-------+ | Sun SunOS 4.1.3 | | Sun SunOS 4.1.3 | | camelot | | lupine | +----------+------+ +--------+--------+ | | +-------+--------------------------+----------------+ 198.116.2.0 In this case "camelot" runs mrouted V3.3 tunnelled to "mbone.hq.nasa.gov" (not shown) and "mcn-test1". "mcn-test1" is a 486DX2-66 running FreeBSD 2.1.0-Development with your patches to the multicast and mrouted V3.3 code, tunnelled to camelot. "mcn-fbsd" (aka "stranneek" - it's a long story) does not have any multicast support, since the multicast support in FBSD 1.1.5.1 is badly broken. "Lupine" has the V2.0 multicast patches and does not run mrouted (although I do use it for viewing conferences.) So far this works, although as you can imagine a 28.8Kbs SLIP line doesn't allow for much usefulness (although we have successfully run vat using gsm encoding over 28.8 lines.) Our intention is to replace the 28.8Kbs line with some radio modems Real Soon Now (tm). It's my intention to move the SLIP line to directly connect to mcn-test1, and to convert to PPP; however, what I have works well now so I'm not in any hurry to change... :{) We're also constructing another FreeBSD box that will replace Lupine; that box will act as router, dialup server, and multicast tunnel host; we want to see how well FBSD stands up. Hope this helps! Mike +--------------------------------------+------------------------------------+ |Mike Newell | The opinions expressed herein are | |NASA Science Internet Network Systems | my own, and do not necessarily | |Sterling Software, Inc. | reflect those of the NSI program, | |MNewell@nsipo.nasa.gov | Sterling Software, NASA, or anyone | |+1-202-434-8954 | else. | +--------------------------------------+------------------------------------+ From list-mgr@ISI.EDU Sat Mar 18 00:16:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 10:17:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 10:17:11 -0800 Received: from ns.itep.ru by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 10:16:46 -0800 Received: by ns.itep.ru id AA16888 (5.67a8/IDA-1.5 for mbone@isi.edu); Fri, 17 Mar 1995 21:16:58 +0300 Date: Fri, 17 Mar 1995 21:16:58 +0300 From: Andrey Bobyshev Message-Id: <199503171816.AA16888@ns.itep.ru> To: mbone Subject: MBONE over ISDN ? Hello, Are there in MBONE access points through ISDN ? It's more interesting such points in Germany. Or maybe someone has wishes to make experiments with it ? Thanks, Andrey. From list-mgr@ISI.EDU Fri Mar 17 08:26:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 10:30:55 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 10:30:33 -0800 Received: from mwunix.mitre.org by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 10:30:32 -0800 Return-Path: slr@fluky.mitre.org Received: from fluky.mitre.org (fluky.mitre.org [128.29.113.24]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id NAA28130; Fri, 17 Mar 1995 13:30:24 -0500 Received: by fluky.mitre.org (4.1/SMI-4.0) id AA23589; Fri, 17 Mar 95 13:26:05 EST Date: Fri, 17 Mar 95 13:26:05 EST From: slr@fluky.mitre.org (Soochon Radee) Message-Id: <9503171826.AA23589@fluky.mitre.org> To: mnewell@lupine.nsi.nasa.gov Subject: Re: multicast over P2P Cc: mbone Mike Newell writes: | +-----+-----------------------------+-------------+ 198.116.75.0 | | | | +-------+--------+ +--------+--------+ | | FreeBSD 2.1.0D | | FreeBSD 1.1.5.1 | | | mcn-test1 | | mcn-fbsd | | +----------------+ +-------+---------+ | | | | | / 28.8Kbs SLIP line | | | | | +-----------------+ +---------+-------+ | | Sun SunOS 4.1.3 | | Sun SunOS 4.1.3 | | | camelot | | lupine | | +----------+------+ +--------+--------+ | | | | +-------+--------------------------+----------------+ 198.116.2.0 My original question dealt with putting the SLIP line between mcn-test1 and camelot. The goal is for every subnet to carry either tunneled or unencapsulated mbone traffic but not both. In the diagram above, both subnets have twice the amount of multicast traffic they need to. Does mrouted currently support phyints of sl0, ppp0, or dp0? I have played with the kernel sources to set the IFF_MULTICAST bit for these interfaces and to add and drop group/interface associations. If so, how what must I change to avoid the "Can't assign requested address" error mrouted gives when adding vifs? If not, how do you assign IP addresses to serial links to not get "mrouted: ignoring ppp0, on same subnet as ether0" message? Surely I don't want to reserve a whole subnet for each point-to-point link. From list-mgr@ISI.EDU Fri Mar 17 09:00:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 11:03:49 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 11:03:26 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 11:03:25 -0800 Received: from lupine.nsi.nasa.gov by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 17 Mar 1995 11:03:22 -0800 Received: (from mnewell@localhost) by lupine.nsi.nasa.gov (8.6.9/8.6.9) id OAA03129; Fri, 17 Mar 1995 14:00:46 -0500 Date: Fri, 17 Mar 1995 14:00:37 -0500 (EST) From: "Michael C. Newell" To: Soochon Radee Cc: mbone Subject: Re: multicast over P2P In-Reply-To: <9503171826.AA23589@fluky.mitre.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 17 Mar 1995, Soochon Radee wrote: > My original question dealt with putting the SLIP line between mcn-test1 and > camelot. The goal is for every subnet to carry either tunneled or > unencapsulated mbone traffic but not both. In the diagram above, both subnets > have twice the amount of multicast traffic they need to. Yes, that would be the most effecient approach. I'm working on this in a stepwise manner; first I wanted to get tunnelling working. Next I want to get PPP working between two FreeBSD hosts. Then I want to run mrouted on both PPP hosts (i.e. move the tunnel from camelot to a new server). Then I'll be where you want to be. Basically I'm really careful about taking on too much in one chunk... > Does mrouted currently support phyints of sl0, ppp0, or dp0? I have played > with the kernel sources to set the IFF_MULTICAST bit for these interfaces > and to add and drop group/interface associations. If so, how > what must I change to avoid the "Can't assign requested address" error > mrouted gives when adding vifs? If not, how do you assign IP addresses to > serial links to not get "mrouted: ignoring ppp0, on same subnet as ether0" > message? Surely I don't want to reserve a whole subnet for each point-to-point > link. I suspect not. However, assume you have two mbone routers connected via a SLIP line: + + | | | +----------+ +----------+ | +---+ Router-1 +---//---+ Router-2 +---+ | +----------+ +----------+ | | | + + You should be able to set up a tunnel between Router-1 and Router-2 that just includes the SLIP/PPP line (you'd have to assin an address to the line); true, that would mean running an encapsulated packet over the serial line but that shouldn't be much overhead. As far as reserving a whole subnet I've never had to do that. Say Router-1 is my PPP server and Router-2 is my target system. The addresses are say: Router-1: Ethernet = 198.116.2.100 Serial = 198.116.2.209 Router-2: Ethernet = 198.116.75.1 Serial = 198.116.2.209 (Which, btw, is exactly what I have now.) Note that the serial line is in Router-1's network range; this works because when you fire up a SLIP (or PPP connection) you can request proxy arping on the server host; that way the server host proxy's for the client withing the server host's address space. Thus you don't need a new subnet for the server and client. You can then establish the tunnel between say 198.116.2.100 and 198.11.2.209; packets should then traverse only the serial line and not be replicated on the Ethernet. At least, that's what I'm hoping. Unfortunately I won't be ready to test that for a few more days... ;{(. Thanks, Mike +--------------------------------------+------------------------------------+ |Mike Newell | The opinions expressed herein are | |NASA Science Internet Network Systems | my own, and do not necessarily | |Sterling Software, Inc. | reflect those of the NSI program, | |MNewell@nsipo.nasa.gov | Sterling Software, NASA, or anyone | |+1-202-434-8954 | else. | +--------------------------------------+------------------------------------+ From list-mgr@ISI.EDU Fri Mar 17 09:25:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 11:25:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 11:25:21 -0800 Received: from oit.gatech.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 11:25:21 -0800 Received: (from ccoprmm@localhost) by oit.gatech.edu (8.6.11/8.6.11) id OAA09237 for mbone@isi.edu; Fri, 17 Mar 1995 14:25:20 -0500 From: Michael.Mealling@oit.gatech.edu (Michael Mealling) Message-Id: <199503171925.OAA09237@oit.gatech.edu> Subject: multicast over ATM w/FORE stuff.... To: mbone Date: Fri, 17 Mar 1995 14:25:19 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 576 We are installing ATM cards in our machines and using a FORE switch for now. We are using nv with CellB and getting 30 fps in a small window. The limitation seems to be the processor of the machine. Does anyone have any working knowledge or tips on ways to improve performance? We havn't tried vic, yet...I've been to busy to install it....;-) -MM -- ------------------------------------------------------------------------------
Michael Mealling
michael.mealling@oit.gatech.edu
From list-mgr@ISI.EDU Fri Mar 17 03:58:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 11:58:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 11:58:16 -0800 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 11:58:15 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id LAA24444; Fri, 17 Mar 1995 11:58:13 -0800 Date: Fri, 17 Mar 1995 11:58:13 -0800 From: Dino Farinacci Message-Id: <199503171958.LAA24444@stilton.cisco.com> To: moline@gumby.dsd.TRW.COM Cc: rem-conf@es.net, mbone In-Reply-To: Dan Molinelli's message of Fri, 17 Mar 95 09:54:10 -0800 <9503171754.AA09324@gumby.dsd.TRW.COM> Subject: Last night's BayLISA bcast >> in addition, can someone point me to the reference material to PIM. >> i joined the conference late. >> thanks One place is on ftp.cisco.com: /ftp/rfc/DRAFTS/*-pim-* Some cisco specific documentation can be found in: /ftp/dino/multicast Dino From list-mgr@ISI.EDU Fri Mar 17 03:47:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 11:58:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 11:58:19 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 11:58:11 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14665(1)>; Fri, 17 Mar 1995 11:48:07 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Fri, 17 Mar 1995 11:47:59 -0800 X-Mailer: exmh version 1.5.3 12/28/94 To: slr@fluky.mitre.org (Soochon Radee) Cc: mnewell@lupine.nsi.nasa.gov, mbone Subject: Re: multicast over P2P In-Reply-To: Your message of "Fri, 17 Mar 95 10:26:05 PST." <9503171826.AA23589@fluky.mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Mar 1995 11:47:47 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <95Mar17.114759pst.49859@crevenia.parc.xerox.com> In message <9503171826.AA23589@fluky.mitre.org> you write: >Does mrouted currently support phyints of sl0, ppp0, or dp0? If the IFF_MULTICAST bit is set and the interface ioctl() SIOCADDMULTI works, then mrouted supports it. >If not, how do you assign IP addresses to >serial links to not get "mrouted: ignoring ppp0, on same subnet as ether0" >message? You need to use a subnet for your point-to-point link. You can use a 2-bit subnet, which ends up not being much of a waste. If you don't want to assign IP addresses, you can just configure a tunnel with the point-to-point link's endpoints and unicast routing should make sure that the traffic only flows over the link. Bill From list-mgr@ISI.EDU Fri Mar 17 20:23:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 12:24:00 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 12:23:18 -0800 Received: from hillfoot.cent.gla.ac.uk ([130.209.30.12]) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 12:23:10 -0800 Received: from hillhead.cent.gla.ac.uk by hillfoot.cent.gla.ac.uk with SMTP-GLA (PP); Fri, 17 Mar 1995 20:22:41 +0000 Received: from kite.psy.gla.ac.uk by hillhead.cent.gla.ac.uk with SMTP (PP); Fri, 17 Mar 1995 20:22:27 +0000 From: Anne Marie Date: Fri, 17 Mar 95 20:23:37 GMT Message-Id: <1650.9503172023@swan.psy.gla.ac.uk> To: Michael.Mealling@oit.gatech.edu, mbone Subject: Re: multicast over ATM w/FORE stuff.... Michael.Mealling@oit.gatech.edu asked ..... #We are installing ATM cards in our machines and using a FORE switch for now. #We are using nv with CellB and getting 30 fps in a small window. The #limitation seems to be the processor of the machine. Does anyone have any #working knowledge or tips on ways to improve performance? We have been working on this: see our interim report: http://www.ukerna.ac.uk/technology/devpilot/atmlan/glasgow/glasgow.html If you want more detail then mail me personally. Anne Marie ============================================================================= Anne Marie Fleming Tel: +44 41 330 5424 University of Glasgow Fax: +44 41 339 8889 56 Hillhead St Telex: 777070 UNIGLA Glasgow G12 8QB, U.K. email: annemari@psy.gla.ac.uk www url: http://www.psy.gla.ac.uk/staff/annemari.html ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Sat Mar 18 00:30:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 12:30:47 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 12:30:35 -0800 Received: from cs.tut.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 12:30:33 -0800 Received: from kaarne.cs.tut.fi (mit@kaarne.cs.tut.fi [130.230.3.2]) by cs.tut.fi (8.6.10/8.6.4) with ESMTP id WAA03392; Fri, 17 Mar 1995 22:34:12 +0200 From: Tsokkinen Mikko Received: (mit@localhost) by kaarne.cs.tut.fi (8.6.10/8.6.4) id WAA00890; Fri, 17 Mar 1995 22:30:29 +0200 Date: Fri, 17 Mar 1995 22:30:29 +0200 Message-Id: <199503172030.WAA00890@kaarne.cs.tut.fi> To: Michael.Mealling@oit.gatech.edu (Michael Mealling) Cc: mbone Subject: multicast over ATM w/FORE stuff.... In-Reply-To: <199503171925.OAA09237@oit.gatech.edu> References: <199503171925.OAA09237@oit.gatech.edu> Michael Mealling writes: > We are installing ATM cards in our machines and using a FORE switch for now. > We are using nv with CellB and getting 30 fps in a small window. The > limitation seems to be the processor of the machine. Does anyone have any > working knowledge or tips on ways to improve performance? You did not tell what hardware you use, so it is hard to tell any specific tips. Apart from upgrading hardware there is not much you can do: - You can try to compile the code with the best optimization flags for your brand of workstation - See that there is enough shared memory for X-server available - Make the process real-time or increase priority On suns you can try running regular X11R6 server rather than brokenwindows. Generally in LAN situations the network is not the bottleneck, unless your segment is very busy, it is the processing speed of your computer CPU, the efficiency of the grabbercard, bus bandwidth and X-server/ Graphics adapter performance. Eg. with SS20 and Sunvideo vic/nv/ivs is just as fast with non-loaded Ethernet, ATM or FDDI Interfaces. Generally the specific multimediatools for your brand of hardware are faster in raw update rate than MBone tools, but Mbone tools give you much better connectebility. Cheers Mikko Tsokkinen xxxxx Mit mit@cs.tut.fi "Duct tape is like the force... It has a light side, and a dark side, and it holds the universe together..." From list-mgr@ISI.EDU Fri Mar 17 11:38:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 13:38:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 13:38:09 -0800 Received: from MITCHELL.CIT.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 17 Mar 1995 13:38:08 -0800 Received: from mitchell.cit.cornell.edu (MITCHELL.CIT.CORNELL.EDU [132.236.200.25]) by mitchell.cit.cornell.edu (8.6.10/8.6.9) with ESMTP id QAA20428 for ; Fri, 17 Mar 1995 16:38:07 -0500 Message-Id: <199503172138.QAA20428@mitchell.cit.cornell.edu> To: mbone Subject: Re: multicast over P2P Organization: Information Technologies/Network Resources; Cornell University, Ithaca, NY X-Mailier: MH-E [version 4.1+] MH [version 6.8.1] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Mar 1995 16:38:02 -0500 From: Jeffrey C Honig You must be sure that the local addresses of the P2P links are unique. It is quite common to have the local IP address of P2P links be the same as the IP address of an Ethernet (in general, any non-P2P interface). This is an intentional feature of BSD 4.3 and later that the IP multicast code does not (yet?) support. Jeff From list-mgr@ISI.EDU Sun Mar 19 11:10:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Mar 1995 03:10:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Mar 1995 03:10:27 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Mar 1995 03:10:26 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Sun, 19 Mar 1995 03:10:24 -0800 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 19 Mar 1995 11:10:12 +0000 To: Michael.Mealling@oit.gatech.edu (Michael Mealling) Cc: mbone Subject: Re: multicast over ATM w/FORE stuff.... In-Reply-To: Your message of "Fri, 17 Mar 95 14:25:19 EST." <199503171925.OAA09237@oit.gatech.edu> Date: Sun, 19 Mar 95 11:10:08 +0000 Message-Id: <619.795611408@cs.ucl.ac.uk> From: Jon Crowcroft >We are installing ATM cards in our machines and using a FORE switch for now. >We are using nv with CellB and getting 30 fps in a small window. The >limitation seems to be the processor of the machine. Does anyone have any >working knowledge or tips on ways to improve performance? 1/ get rids of the ATM, and use an ether hub:-) i mean if you use vic or nv, you simply don't need more than a few Mbps but seriouslym if you have 2nd generation fore cards (sba200 or similar) and an ASX200, then the main limit (assuming ytou have your drivers all configured right and so on) is as you say receiver to display process and data moving - we find an SS20 is very happy ....an SS10 just about ok... >We havn't tried vic, yet...I've been to busy to install it....;-) doens't take long and is well worth it cheers jon From list-mgr@ISI.EDU Sun Mar 19 20:47:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Mar 1995 10:58:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Mar 1995 10:57:54 -0800 Received: from faui45.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 19 Mar 1995 10:57:46 -0800 Received: from faui40.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA28759 (5.65c-6/7.3w-FAU); Sun, 19 Mar 1995 19:47:11 +0100 Received: from delos (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with SMTP id TAA09294 (8.6.10/7.4a-FAU);; Sun, 19 Mar 1995 19:47:03 +0100 From: Toerless Eckert Message-Id: <199503191847.TAA09294@faui40.informatik.uni-erlangen.de> Subject: Re: multicast over ATM w/FORE stuff.... To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Sun, 19 Mar 1995 19:47:01 +0100 (MET) Cc: Michael.Mealling@oit.gatech.edu, mbone In-Reply-To: <619.795611408@cs.ucl.ac.uk> from "Jon Crowcroft" at Mar 19, 95 11:10:08 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Could someone give me more detailed information on how multicast will work with the fore ATM interface cards ? I really don't understand how it will work. Do the fore cards together with the fore switch implement ATM multicasting and map IP multicasts onto ATM multicasts ? Do they translate IP multicasts into replicated packets to be transmitted by the sending station onto every svc/pcv on the local cloud ? Does they have IP multicast support in the 4.1.3 driver or in the solaris driver ? Questions over questions.. Thanks Toerless From list-mgr@ISI.EDU Mon Mar 20 09:14:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 01:17:01 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 01:15:54 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 01:15:52 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Mon, 20 Mar 1995 01:15:43 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 20 Mar 1995 09:14:53 +0000 To: Toerless Eckert Cc: Michael.Mealling@oit.gatech.edu, mbone Subject: Re: multicast over ATM w/FORE stuff.... In-Reply-To: Your message of "Sun, 19 Mar 95 19:47:01 +0100." <199503191847.TAA09294@faui40.informatik.uni-erlangen.de> Date: Mon, 20 Mar 95 09:14:42 +0000 Message-Id: <660.795690882@cs.ucl.ac.uk> From: Jon Crowcroft >Could someone give me more detailed information on how multicast will work >with the fore ATM interface cards ? I really don't understand how >it will work. Do the fore cards together with the fore switch implement >ATM multicasting and map IP multicasts onto ATM multicasts ? >Do they translate IP multicasts into replicated packets to be >transmitted by the sending station onto every svc/pcv on the local cloud ? >Does they have IP multicast support in the 4.1.3 driver or in the solaris >driver ? >Questions over questions.. Toerless well i guess Fore are the best people to explai ntheir propietary (but generally smart) imporovements to the baseline ATM stuff... i think that 0/ they support point-multipoint VCs at the UNI and NNI 1/ their signaling (SPANS) permits recevier joins to ATM point multipoint VCs 2/ there is a mapping for an IP multicast addr onto the ATM level addresses they use (maybe, but not a requirement) 3/ in a multiple switch setup, maybe they even understand how to build reverse path multicast trees.... 4/ the ASX[12]00 are not switch fabric switches, but use a fast bus, so can do multicast interally very efficiently without the need for a multicast copoy fabric that true switches have... 4.1.3 and solaris 2.2 we are running /dev/fa0: sba-200 media=4b5b-100 sw=2.3.0 fw=2.1.0 serial=10367 slot=0 which i believe supports multicast, but wouldn't swear to the reason we don't use ATM level multicast in the wide area is due to several things a/ the WAN switches don't do it (though we could setup a VP cross connect between site fore switches and try and see if SPANS and Fore multicast worked over that...) b/ the traffic policers in the WAN won't tolerate the bursts from IP sources (e.g. Vat/Vic/IVS) so we have to smooth traffic somewhere - the easiest place is in cisco routers....i.e we 've build an ATM backbone with routers around the edge and local ATM switching between hotspot hosts and the routers..., but we don't have seemless end to end ATM (at all...) yet we are working on a more recent driver and hoe to try out new ASX switch s/w that allows ATM host or switches under our control to provide the smoothing (shaping), or even eventually use something like a true ABR service (yeah, even a VBR one!), but it is a way off...what you can do in general seems to be get good LAN styel switches which can do data well, or else good WAN style switches wihich do CBR and UBR, but don't mix well with the LAN ones the "abone" is someway off yet... jon From list-mgr@ISI.EDU Mon Mar 20 05:59:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 08:00:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 07:59:20 -0800 Received: from cerc.wvu.edu (cathedral.cerc.wvu.edu) by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 07:59:18 -0800 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA00931; Mon, 20 Mar 95 10:59:12 EST Received: by elk (5.0//ident-1.0) id AA09812; Mon, 20 Mar 1995 10:59:11 +0500 Date: Mon, 20 Mar 1995 10:59:10 -0500 (EST) From: "Todd L. Montgomery" Subject: RMP Beta 1.0 availability To: rem-conf@es.net, mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 4015 I apologize to anyone who has already received this message. After extensive Alpha testing, the Reliable Multicast Protocol (RMP) is now released for general use. What exactly does RMP do? RMP - Reliable Multicast Protocol C++ Programming Library RMP is a high performance transport protocol, designed to provide reliable, fault tolerant, and ordered delivery of messages between multiple senders and multiple destinations in LAN and WAN environments. RMP provides message delivery semantic (RMP QoS (Quality of Service)) selection on a per message basis. Message resilieny and fault tolerance are selectable on a per group and per message basis as well. Fault recovery in RMP is totally transparent to the application. Efficient membership changes provide a Virtual Synchronous model of distributed application processing. RMP is the C++ library that can be used to provide all these wonderful things! Presently only multicast capable machines can use RMP. Currently, the supported platforms and operating systems are: Sun SunOS 4.1.3 Sun SunOS 5.3 (Solaris 2.3) Sun SunOS 5.4 (Solaris 2.4) SGI Irix 5.2 SGI Irix 5.3 In Testing: Linux 1.1.94, DEC Ultrix 4.3, non-multicast support. Soon to be included are non-multicast capable machines and support for DEC Ultrix. Performance tests have shown that on a typcial 10 Mbps Ethernet, RMP can produce throughputs of upwards of 1100 KBps to one receiver and over 900 KBps to 8 receivers. In a WAN environment such as the current MBone topology, the throughput is only limited by the speed of the slowest link in the topology. Latency of messages on a LAN has been shown to be as low as 3.5 msec. for Source Ordered messages and 4.0 msec. for Totally (or Globally Ordered) messages. This latency appears to be virtually flat as the number of destinations increase (4.9 msec. for 8 destinations from 1 sender for a totally ordered message). Thus it can be seen that RMP scales incredibly well! The RMP distribution can be retrieved from: RMP WWW Home Page: http://research.ivv.nasa.gov/projects/RMP/RMP.html RMP FTP Site: ftp://research.ivv.nasa.gov/pub/src/RMP/Beta This distribution includes man pages and documentation describing how to use the RMP library. The distribution site also contains a copy of a thesis on RMP. Because RMP is still less than one year old, it is being released as a Beta version without 100% of its planned features supported. These features are being developed and debugged presently and will be ready for release within a few weeks. Supported Features: ------------------- This is a list of the supported features of this release Message Delivery Semantics (RMP QoS) selection per message Virtual Synchronous execution Model Efficient Membership View Changes Fault Recovery Fault Tolerance selection per group Message Resiliency selection per message 6 Handler Locks User Timer and Periodic Alarm scheduling Event Driven and Implicit Control Unsupported Features: --------------------- As of this release the currently unsupported features that are to be supported in the near future are: Multi-RPC Expected: Beta 1.1 4096 Mutually Exclusive Locks Expected: Beta 1.1 Non-Multicast Group Members Expected: Beta 1.1 Broadcast Support Expected: Beta 1.2 Tentative Release Dates for the near future: Beta 1.1 - March 31, 1995 RMP is being brought to you by the NASA IV&V Facility, West Virginia University, and the Concurrent Engineering Research Center (CERC). This work has been supported by NASA Cooperative Research Agreement NCCW-0400 and NASA Headquarters Office of Safety and Mission Assurance. The protocol developement, design, and verification team are: Todd Montgomery tmont@cerc.wvu.edu Brian Whetten whetten@tenet.icsi.berkeley.edu John R. Callahan callahan@cerc.wvu.edu We look forward to everyones comments. Comments, Suggestions, and Bug Reports can be sent to: -- Todd Montgomery tmont@cerc.wvu.edu http://research.ivv.nasa.gov/~tmont/index.html From list-mgr@ISI.EDU Mon Mar 20 02:04:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 10:04:28 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 10:04:27 -0800 Received: by rx7.ee.lbl.gov (8.6.10/1.43r) id KAA13587; Mon, 20 Mar 1995 10:04:27 -0800 Message-Id: <199503201804.KAA13587@rx7.ee.lbl.gov> To: zchen@indy1.cs.uiuc.edu Cc: mbone-na Subject: zchen@indy1.cs.uiuc.edu sending 100-200kb/s video of empty office Date: Mon, 20 Mar 95 10:04:25 PST From: Van Jacobson For at least the past four days, zchen@indy1.cs.uiuc.edu has been sending continuous nv video of an empty office to mbone address 224.2.218.59/63057. Perhaps this person does not understand that this video is causing problems for people all over the world. The mbone reaches nets in every timezone and is used 24 hours a day, 7 days a week. It has a total bandwidth of 500kb/s which has to be shared among thousands of users. This video is using up to a quarter of the world's mbone bandwidth and taking away bandwidth or causing losses for people trying to use the mbone for useful work. Given the very limited mbone bandwidth and the very large number of users, it is very inconsiderate to ever send gratuitous video at a global scope. It is unconscionable to then wander off and leave it running for days at a time. Please reduce the ttl of this video to <16 or stop it. Thank you. - Van Jacobson From list-mgr@ISI.EDU Mon Mar 20 11:46:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 15:50:40 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 15:50:03 -0800 Received: from newton.ncsa.uiuc.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 15:50:00 -0800 Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA22337 (5.65a/IDA-1.4.2 for mbone@isi.edu); Mon, 20 Mar 95 17:47:43 -0600 Return-Path: Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1) id AA13561; Mon, 20 Mar 95 17:46:28 CST Message-Id: <9503202346.AA13561@void.ncsa.uiuc.edu> Subject: late starts and such.. To: mbone Date: Mon, 20 Mar 1995 17:46:27 -0600 (CST) From: Daniel Simms X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 480 I apologize for the late start this afternoon.. there was some room reshuffling and the one I needed to steal the VCR from was busy... I haven't gotten but one message about the quality of transmission, so please let me know if it's good or bad and where you're tuning in from. Thanks, dan -- Daniel Simms dsimms@uiuc.edu Quad verum tutum. (217) {244-1309,328-7060} What is true, is safe. From list-mgr@ISI.EDU Mon Mar 20 11:04:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 19:06:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 19:05:15 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 20 Mar 1995 19:05:14 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14540(2)>; Mon, 20 Mar 1995 19:05:05 PST Received: by crevenia.parc.xerox.com id <49859>; Mon, 20 Mar 1995 19:04:58 -0800 From: Bill Fenner To: mbone Subject: Imminent 3.5 multicast release Cc: fenner@parc.xerox.com Message-Id: <95Mar20.190458pst.49859@crevenia.parc.xerox.com> Date: Mon, 20 Mar 1995 19:04:48 PST Folks, The 3.5 multicast release (kernel & mrouted) is progressing smoothly, and should be available about a week after IETF. Here is a list of features/ bugfixes in the new release. If your favorite bug is not there, let me know and I will see what I can do about it. If your favorite bug/feature *is* there, volunteer to test it out for me; I will need some help testing some of these. Note the bracketed comment about potential shaving of the feature list. Bill New Features in the 3.5 multicast release ----------------------------------------- o The kernel and mrouted make sure that each is the correct version, to prevent problems with mismatched kernel/mrouted versions. A too-old mrouted will die with the error: can't enable DVMRP routing in kernel: Option not supported by protocol o mrouted can accept and propogate a default route (essential for heirarchical multicast routing) o Kernel route cache keeps source-specific routes instead of subnet routes, eliminating hashing and longest-match problems. o Cached kernel routes only get deleted if no traffic is flowing o mrouted has a new configuration file parser, which provides better error messages than before, and allows named boundaries (see man page) o added "netmask" to phyint configuration, at the suggestion of Anders Klemets o System V compatibility from John Brezak o phyint's can have additional subnets configured, for people with multiple subnets on one wire. see man page for syntax. o both mrouted and the kernel now support classless addresses. [The following two will hopefully be included, but are the two prime candidates for pruning off the completion list in favor of a sooner release date] o mrouted can now use a bogus interface for multicast, in order to accommodate hosts that don't have or don't want to multicast on a physical medium. o mrouted recognizes leaf nodes & automatically reduces routing traffic to them (useful for slow links) Bugs fixed in the 3.5 multicast release --------------------------------------- o Numerous IGMP bugs, both in the kernel and mrouted. [including a major bug in the 3.3 client kernel code; you are strongly encouraged to upgrade both hosts and routers] o Kernel hash function improved o Eliminated possibility of panic(): timeout in cache maintenance o some endian-ness bugs squashed in mrouted, probably more to go. From list-mgr@ISI.EDU Wed Mar 22 22:45:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Mar 1995 22:52:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Mar 1995 22:51:49 -0800 Received: from sunstation2.tsinghua.edu.cn ([166.111.8.10]) by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Mar 1995 22:45:28 -0800 Received: from csnet4.tsinghua.edu.cn ([166.111.166.17]) by sunstation2.tsinghua.edu.cn (4.1/SMI-4.1) id AA01578; Wed, 22 Mar 95 14:45:36 CST Received: by csnet4.tsinghua.edu.cn (5.0/SMI-SVR4) id AA01601; Wed, 22 Mar 1995 14:45:01 --800 Date: Wed, 22 Mar 1995 14:45:01 --800 From: wsg@csnet4.tsinghua.edu.cn (Wu Shangguang) Message-Id: <9503220645.AA01601@csnet4.tsinghua.edu.cn> To: mbone X-Sun-Charset: US-ASCII Content-Length: 50 Subscribe: MBone mbone@csnet4.tsinghua.edu.cn From list-mgr@ISI.EDU Thu Mar 23 04:38:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 22 Mar 1995 02:39:30 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 22 Mar 1995 02:39:03 -0800 Received: from tims3.kotel.co.kr by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 22 Mar 1995 02:39:00 -0800 Received: by tims3.kotel.co.kr (5.0/SMI-SVR4) id AA09269; Wed, 22 Mar 1995 19:38:04 --900 Date: Wed, 22 Mar 1995 19:38:04 --900 From: lethal@tims3.kotel.co.kr Message-Id: <9503221038.AA09269@tims3.kotel.co.kr> To: mbone Subject: Subscription Cc: lethal@tims3.kotel.co.kr X-Sun-Charset: US-ASCII Content-Length: 235 Hello. How do you do? I am Jaehwa Lee working with Korea Telecom(Outside Plant Technology Lab). I want to know if there is any chance that my system(SPARC/20) can join the world-wide MBONE. I look forward to hearing from you. Lethal From list-mgr@ISI.EDU Wed Mar 22 08:18:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 22 Mar 1995 16:18:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 22 Mar 1995 16:18:20 -0800 Received: from gumby.dsd.TRW.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 22 Mar 1995 16:18:19 -0800 Received: from localhost.sp.TRW.COM by gumby.dsd.TRW.COM (4.1/SMI-4.1) id AA26124; Wed, 22 Mar 95 16:18:18 PST Message-Id: <9503230018.AA26124@gumby.dsd.TRW.COM> To: mbone Subject: NV 3.3 bug w/ IPC shmget Date: Wed, 22 Mar 95 16:18:17 -0800 From: Dan Molinelli i just tried to start a VIC session and received the following error: shmget: no space left sure enough, when i did a 'ipcs', my IPC ids ran off the screen. i had to do an 'ipcrm' on each IPC mid to clear. trying different combinations of vat/nv/vic/sd showed that nv is the culprit - leaving lasting IPC mids. is this a known bug? being looked into? thanks for support. later dan Daniel Molinelli dan.molinelli@trw.com TRW S&EG/ITS Views expressed here are mine. Los Angeles, CA From list-mgr@ISI.EDU Wed Mar 22 10:15:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 22 Mar 1995 18:16:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 22 Mar 1995 18:16:17 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 22 Mar 1995 18:16:16 -0800 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14501(6)>; Wed, 22 Mar 1995 18:16:00 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16136>; Wed, 22 Mar 1995 18:15:49 -0800 To: Dan Molinelli Cc: mbone Subject: Re: NV 3.3 bug w/ IPC shmget In-Reply-To: Your message of "Wed, 22 Mar 95 16:18:17 PST." <9503230018.AA26124@gumby.dsd.TRW.COM> Date: Wed, 22 Mar 1995 18:15:38 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <95Mar22.181549pst.16136@ecco.parc.xerox.com> In message <9503230018.AA26124@gumby.dsd.TRW.COM> you write: > sure enough, when i did a 'ipcs', my IPC ids ran off the screen. > i had to do an 'ipcrm' on each IPC mid to clear. trying different > combinations of vat/nv/vic/sd showed that nv is the culprit - leaving > lasting IPC mids. > > is this a known bug? being looked into? > There's a bug in the 3.3beta X11 grabber which I recently found which will leave around a single shm segment if you don't actively use the X11 grabber before killing the tool. I have a fix, but I haven't tried to put together new binary releases. I can provide a patch to anyone who is interested. -- Ron Frederick frederick@parc.xerox.com From list-mgr@ISI.EDU Thu Mar 23 09:46:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 11:45:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 11:45:27 -0800 Received: from davinci.gmu.edu ([199.26.254.51]) by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 11:45:25 -0800 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id OAA01397; Thu, 23 Mar 1995 14:46:25 -0500 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199503231946.OAA01397@davinci.gmu.edu> Subject: versions of mbone To: mbone Date: Thu, 23 Mar 1995 14:46:25 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 278 What is the latest stable version of mbone for solaris 2.3 and where may I obtain it? Michael -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Thu Mar 23 09:53:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 11:55:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 11:55:02 -0800 Received: from home.merit.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 11:55:00 -0800 Received: from localhost (ljb@localhost) by home.merit.edu (8.6.10/merit-2.0) with SMTP id OAA19876; Thu, 23 Mar 1995 14:53:40 -0500 Message-Id: <199503231953.OAA19876@home.merit.edu> To: John Brezak Cc: Ajit Thyagarajan , mbone Subject: Re: New mrouted (version 3.4) available In-Reply-To: Your message of "Tue, 14 Mar 1995 12:34:56 EST." <199503141734.AA273892498@relay.hp.com> Date: Thu, 23 Mar 1995 14:53:36 -0500 From: "Larry J. Blunk" > > > > This is to announce the availability of version 3.4 of mrouted. This > > is an interim release to fix some bugs that were important enough not > > to wait for the planned version 3.5 full release of the multicast > > routing extensions. This interim release includes only mrouted and no > > kernel changes. This version (3.4) of mrouted will work *only* with a > > kernel built using the ipmulti3.3-sunos413x.tar.gz and is meant to > > replace the version of mrouted in that release. > > > > You can pick up mrouted-3.4 at the following location: > > > > ftp.udel.edu:pub/mbone/mrouted-3.4.tar.gz > > > > There is a README-3.4 file in the same directory which explains > > everything about this release. > > > > If there are any questions or problems, please let me know. > > > > Ajit Thyagarajan > > > > Here is a patch to 3.4 (Please consider these for the 3.5 release - Thanx) > > - Compile on SYSV based systems > - Compile for NetBSD and FreeBSD (4.4Lite based systems) > - Include changes for "clean" shutdown > - Include Van's changes to mrinfo so that localhost is implied with no args > Uh, Sun's C Library doesn't have atexit. I made a hack to the code to use Sun's on_exit, but obviously that's not very portable either. -Larry Blunk Merit Network, Inc. From list-mgr@ISI.EDU Thu Mar 23 22:38:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 12:41:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 12:40:51 -0800 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 12:40:50 -0800 Received: from by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AB04270; Thu, 23 Mar 95 12:38:19 PST Message-Id: <9503232038.AB04270@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Mar 1995 21:38:28 +0100 To: brutzman@cs.nps.navy.mil (Don Brutzman) From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Regarding the Hamming on Hamming MBone course Cc: mbone that you propose to multicast worldwide: Tuesday March 28 through Friday June 9. Tuesdays and Thursdays 1210-1300 Pacific (1910-2000 GMT), Fridays 1410-1500 Pacific (2110-2200 GMT). I noticed that you sent your message to rem-conf@es.net I thought such messages (i.e. scheduling MBone slots) were to go to mbone@isi.edu. If I am right about this perhaps this message (cc'ed to the mbone list) will serve. However, the reason I am writing is to question the usefulness of such an effort to "push back the envelope" regarding the kinds of programming possible on the MBone by regular transmission of programming with a global scope (ttl). First I should say that I would love to be able to participate in Dr. Hamming's course. I believe that wherever it could be successfully transmitted that it would be a good use of Internet and MBone bandwidth. However, my experience (here in Germany anyway) suggests that if I am either here in the evening trying to work or if I specifically come in and try to listen in, even given that the schedule puts it in the evening local time, the performance will be such that I will not really be able to understand what is being said most of the time and I will not be able to effectively participate. So from my perspective, I loose at least a hundred kilobits of Internet bandwidth coming from the US (not to mention MBone bandwidth) whenever these course presentations are running and I get nothing out of it. The present bandwidth available here in Germany is such that (global) MBone demonstrations are largely only able to show what would be possible with more bandwidth. Sure, we can set up special or dedicated links and put on a nice show. Just about anything we want to do on the local LAN is CPU limited and works pretty well. But Internet losses are typically so high that usually things coming in with high ttls from the US or elsewhere are enticing, trying to catch meaning in the blits and blats of audio that come through (sound familiar?), but really useless as far as real content goes. So in terms of a Masters project to "push back the envelope", it would seem to me that as far as ttl 127 transmission goes, you will be able to get the learning done during the first transmission. If you then cut back to a ttl that allows you to really get through to most of those that you reach then continued transmission might continue to be a learning exercise. However, to continue to bang on the network (don't tell me about pruning in Europe - even with pruning somebody is sure to tune in, so the choke points will be seeing that data) doesn't seem to me to serve any useful purpose. As I see it, global MBone transmissions are useful for tantalizing demonstrations of what might some day be possible, but to expect to get useful communication done with such transmissions on a regular basis is still beyond the current capabilities. Having said all that, if you do go ahead, please include any visual materials on a whiteboard multicast. Sometimes these whiteboard multicasts get through reasonably (though even they often have problems) with retransmissions. If you are going to interview listeners to get their experiences, at least with a whiteboard they will have something to look at while they gather their experiences. It seems to me that to "push back the envelope" of multimedia multicasts simply takes more bandwidth. Many people are working on this in one area or another. To pound on an inadequate infrastructure in a sustained way does not strike me as a way to make progress, no matter how excellent the source material. --Jed http://www-atp.llnl.gov/atp/jed.html From list-mgr@ISI.EDU Thu Mar 23 20:41:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 12:43:09 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 12:42:56 -0800 Received: from mailsun.aber.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 12:42:48 -0800 Received: from mailhost.aber.ac.uk (actually host saturnbb.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Thu, 23 Mar 1995 20:42:08 +0000 To: Ron Frederick Cc: mbone, dap@aber.ac.uk Subject: Re: Colour Maps Going Odd In-Reply-To: Your message of Wed, 22 Mar 1995 18:15:38 -0800. <95Mar22.181549pst.16136@ecco.parc.xerox.com> Date: Thu, 23 Mar 1995 20:41:59 +0000 Message-Id: <25686.795991319@mailhost.aber.ac.uk> From: D E PRICE Dear All, Yesterday we were involved running a very successful Internet demo in a small local town as part of the UK Science Engineering and Technology week.... We demoed some Mbone tools on an Ethernet link just inside the room as well as Web Browsing via an ISDN supplied Internet link. You will all be pleased to know it went well. Anyway, back to the purpose of this email. I am having large problems with applications not managing to get enough colours and then reverting to to using private colour maps. This of course means the the VIC video window goes to crazy colours as I move the pointer into WB. I was not running many apps and I wonder if I can avoid these problems.... Typically just vat, vic, wb and sd. I have been using either SUN classics or IPXs. We have just one VideoPix card and one SunVideo card.... at the moment. Ive been running Openwindows 3.3 as my X server. So, what am I doing wrong? How do I avoid this problem or do I have to suffer it?? Thanks, Dave Price, Computer Science, Aberystwyth From list-mgr@ISI.EDU Thu Mar 23 12:25:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 14:26:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 14:25:49 -0800 Received: from relay.hp.com by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 14:25:47 -0800 Received: from it_750.ch.apollo.hp.com by relay.hp.com with SMTP (1.37.109.15/15.5+ECS 3.3) id AA067837546; Thu, 23 Mar 1995 14:25:46 -0800 Message-Id: <199503232225.AA067837546@relay.hp.com> Received: from dcetv.ch.apollo.hp.com by it_750.ch.apollo.hp.com for mbone@isi.edu id AA22720; Thu, 23 Mar 1995 17:25:44 -0500 X-Mailer: exmh version 1.5.3 12/28/94 To: "Larry J. Blunk" Cc: Ajit Thyagarajan , mbone Subject: Re: New mrouted (version 3.4) available In-Reply-To: Your message of "Thu, 23 Mar 1995 14:53:36 EST." <199503231953.OAA19876@home.merit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Mar 1995 17:25:44 -0500 From: John Brezak > > > > > > > This is to announce the availability of version 3.4 of mrouted. This > > > is an interim release to fix some bugs that were important enough not > > > to wait for the planned version 3.5 full release of the multicast > > > routing extensions. This interim release includes only mrouted and no > > > kernel changes. This version (3.4) of mrouted will work *only* with a > > > kernel built using the ipmulti3.3-sunos413x.tar.gz and is meant to > > > replace the version of mrouted in that release. > > > > > > You can pick up mrouted-3.4 at the following location: > > > > > > ftp.udel.edu:pub/mbone/mrouted-3.4.tar.gz > > > > > > There is a README-3.4 file in the same directory which explains > > > everything about this release. > > > > > > If there are any questions or problems, please let me know. > > > > > > Ajit Thyagarajan > > > > > > > Here is a patch to 3.4 (Please consider these for the 3.5 release - Thanx) > > > > - Compile on SYSV based systems > > - Compile for NetBSD and FreeBSD (4.4Lite based systems) > > - Include changes for "clean" shutdown > > - Include Van's changes to mrinfo so that localhost is implied with no args > > > > Uh, Sun's C Library doesn't have atexit. I made a hack to the code to use > Sun's on_exit, but obviously that's not very portable either. > > > -Larry Blunk > Merit Network, Inc. Try this patch with it. It turns out that atexit() probably isn't needed anyway, but this patch works for others with Suns. *** 1.8 1995/03/14 17:36:53 --- main.c 1995/03/17 16:22:20 *************** *** 7,13 **** * Leland Stanford Junior University. * * ! * $Id: main.c,v 1.8 1995/03/14 17:36:53 brezak Exp $ */ /* --- 7,13 ---- * Leland Stanford Junior University. * * ! * $Id: main.c,v 1.9 1995/03/17 16:22:00 brezak Exp $ */ /* *************** *** 323,329 **** /* ! * On hangup signal, let everyone know we're going away. */ static void done() { --- 323,329 ---- /* ! * On termination signal, let everyone know we're going away. */ static void done() { *************** *** 334,343 **** --- 334,348 ---- static void cleanup() { + static in_cleanup = 0; + + if (!in_cleanup) { + in_cleanup++; expire_all_routes(); report_to_all_neighbors(ALL_ROUTES); k_stop_dvmrp(); } + } /* * Dump internal data structures to stderr. *************** *** 404,410 **** --- 409,417 ---- dvmrp_genid++; pruning = 1; + #ifdef _XPG4 atexit(cleanup); + #endif init_igmp(); k_init_dvmrp(); /* enable DVMRP routing in kernel */ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5140 From list-mgr@ISI.EDU Thu Mar 23 06:27:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 14:27:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 14:27:17 -0800 Received: from admin.ogi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 14:27:16 -0800 Received: by admin.ogi.edu (4.1/SMI-4.1) id AA27656; Thu, 23 Mar 95 14:27:13 PST Date: Thu, 23 Mar 1995 14:27:12 -0800 (PST) From: Dan Revel Subject: Starting and stopping vat and nv automatically? To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is there a way to start and stop vat and nv multicasts from the command line? From the man page it looks like vat might be able to do this (e.g. vat -M; sleep 3600; kill ...) but I can't see that nv has a similar capability. There is a class that we would like to multicast twice a week and I would like to arrange for the multicast to happen without operator intervention (the class is in a different location from the workstation doing the multicasting). Dan Revel Is it tomorrow, or just the end of time? - Jimi Hendrix From list-mgr@ISI.EDU Thu Mar 23 11:04:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 19:05:09 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 19:04:49 -0800 Received: from medoc.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 19:04:48 -0800 Received: from medoc.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by medoc.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id TAA02281; Thu, 23 Mar 1995 19:04:34 -0800 From: Eric Paulos Message-Id: <199503240304.TAA02281@medoc.CS.Berkeley.EDU> To: D E PRICE Cc: Ron Frederick , mbone Subject: Re: Colour Maps Going Odd In-Reply-To: Your message of "Thu, 23 Mar 1995 20:41:59 GMT." <25686.795991319@mailhost.aber.ac.uk> Date: Thu, 23 Mar 1995 19:04:33 -0800 DEP> Anyway, back to the purpose of this email. I am having DEP> large problems with applications not managing to get enough DEP> colours and then reverting to to using private colour DEP> maps. If you were running Netscape as a web browser, this may have been your problem as Netscape is very greedy with its color map, grabbing all of the colors and refusing to share. Try firing up Netscape last so that it doesn't steal all of the colors. Also, you may try another web browser. There should be a way to force Netscape to use a shared colormap but I am not aware of this. PS -- Similar problems with some color postscript previewers. ------------------------------------------------------------------------- Eric Paulos Robotics Laboratory paulos@robotics.eecs.berkeley.edu University of California, Berkeley URL: http://robotics.eecs.berkeley.edu/~paulos/ From list-mgr@ISI.EDU Thu Mar 23 13:36:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 21:37:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 21:37:11 -0800 Received: from decu13.triumf.ca (www.Triumf.CA) by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 21:37:06 -0800 Received: by decu13.triumf.ca (5.65/DEC-Ultrix/4.3) id AA01550; Thu, 23 Mar 1995 21:35:59 -0800 Date: Thu, 23 Mar 1995 21:36:57 -0800 (PST) From: Andrew Daviel To: mbone Cc: 678-7017@mcimail.com Subject: "Silicon Graphics and Sun systems not used for conferencing" - article in Communications Week Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Just noticed an article on desktop video in the March 6 issue of Communications Week (ISSN 0746-8121). Elliott Gold, president of TeleSpan Publishing Corp., is quoted as saying that Silicon Graphics and Sun systems are not typically used for conferencing applications. He surveyed vendors of desktop video products but IBM, Silicon Graphics and Sun "did not submit data". Although I'm new to mbone and videoconferencing, I find it interesting that the systems most often used (as far as I am aware from my reading) for global conferencing on the Internet are not featured in the survey. I also note that there is no overlap between the videoconferencing standards mentioned in the magazine, ITU's H.320, T.120 and Intel's PCS 2.0, and the encoding standards that I've seen supported in the mbone video tools, H.261 and CellB. I admit that I don't fully understand the standards; I've merely searched the mbone FAQs and mailing list archive for "320" and "PCS". Andrew Daviel email: advax@triumf.ca TRIUMF voice: 604-222-7376 4004 Wesbrook Mall fax: 604-222-7307 Vancouver BC http://andrew.triumf.ca/~andrew Canada V6T 2A3 49D14.7N 123D13.6W From list-mgr@ISI.EDU Fri Mar 24 10:09:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 22:10:40 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 22:10:26 -0800 Received: from cardhu.cs.hut.fi (laphroaig.cs.hut.fi) by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 22:10:23 -0800 Received: by cardhu.cs.hut.fi id AA27071 (5.65c8/HUTCS-C 1.3 for mbone@ISI.EDU); Fri, 24 Mar 1995 08:09:42 +0200 Date: Fri, 24 Mar 1995 08:09:42 +0200 From: Sami-Jaakko Tikka Message-Id: <199503240609.AA27071@cardhu.cs.hut.fi> To: Andrew Daviel Cc: mbone Subject: "Silicon Graphics and Sun systems not used for conferencing" - article in Communications Week In-Reply-To: References: >>>>> "Andrew" == Andrew Daviel writes: Andrew> I also note that there is no overlap between the Andrew> videoconferencing standards mentioned in the magazine, ITU's Andrew> H.320, T.120 and Intel's PCS 2.0, and the encoding standards Andrew> that I've seen supported in the mbone video tools, H.261 and Andrew> CellB. H.261 belongs to the H.320 standard family. H.320 has standards for video, audio and data encoding and packetization and probably something else too. From list-mgr@ISI.EDU Thu Mar 23 14:20:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 22:21:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 22:20:37 -0800 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Mar 1995 22:20:36 -0800 Received: from icsib77.ICSI.Berkeley.EDU (icsib77.ICSI.Berkeley.EDU [128.32.201.203]) by icsia.ICSI.Berkeley.EDU (8.6.11/HUB+V8$Revision: 1.22 $) with ESMTP id WAA06119; Thu, 23 Mar 1995 22:20:19 -0800 From: whd@ICSI.Berkeley.EDU (Wieland Holfelder) Received: (whd@localhost) by icsib77.ICSI.Berkeley.EDU (8.6.11/1.8) id WAA26238; Thu, 23 Mar 1995 22:20:14 -0800 Message-Id: <199503240620.WAA26238@icsib77.ICSI.Berkeley.EDU> Subject: Re: Colour Maps Going Odd To: paulos@CS.Berkeley.EDU (Eric Paulos) Date: Thu, 23 Mar 1995 22:20:13 -0800 (PST) Cc: mbone (Multicast Backbone) In-Reply-To: <199503240304.TAA02281@medoc.CS.Berkeley.EDU> from "Eric Paulos" at Mar 23, 95 07:04:33 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1032 Eric Paulos writes: > If you were running Netscape as a web browser, this may have been your > problem as Netscape is very greedy with its color map, grabbing all of > the colors and refusing to share. Try firing up Netscape last so that > it doesn't steal all of the colors. Also, you may try another web > browser. There should be a way to force Netscape to use a shared > colormap but I am not aware of this. ... or start netscape with "netscape -install" so it uses its own privat color map and does not steal any colors. (you will, however, get crazy colors when the mousepointer leaves netscape...) -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder International Computer Science Institute Email: whd@icsi.berkeley.edu 1947 Center Street Suite 600 Fax : +1-510-642-6865 Berkeley, CA 94704-1198 Phone: +1-510-642-4274 Ext. 302 URL: http://www.icsi.berkeley.edu/~whd ------------------------------------------------------------------------------- From list-mgr@ISI.EDU Fri Mar 24 09:58:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 02:02:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 02:02:17 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 02:01:40 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 24 Mar 1995 02:01:22 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 24 Mar 1995 10:00:19 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Sami-Jaakko Tikka Cc: Andrew Daviel , mbone Subject: Re: "Silicon Graphics and Sun systems not used for conferencing" - article in Communications Week In-Reply-To: Your message of "Fri, 24 Mar 95 08:09:42 +0200." <199503240609.AA27071@cardhu.cs.hut.fi> Date: Fri, 24 Mar 95 09:58:43 +0000 Message-Id: <13695.796039123@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >>>>>> "Andrew" == Andrew Daviel writes: > >Andrew> I also note that there is no overlap between the >Andrew> videoconferencing standards mentioned in the magazine, ITU's >Andrew> H.320, T.120 and Intel's PCS 2.0, and the encoding standards >Andrew> that I've seen supported in the mbone video tools, H.261 and >Andrew> CellB. > >H.261 belongs to the H.320 standard family. H.261 is the video encoding standard from the H.320 family. >H.320 has standards for >video, audio and data encoding and packetization and probably >something else too. H.320 is designed for switched circuits. The framing standard is H.221, which is designed for multiples of 56 or 64Kbps. It is *not* a packet standard in any way that I've every considered packets. H.320 also includes a lot of capability exchange "messages" to find a common set of encoding schemes shared by the end systems and messages for negotiation of increased bandwidth (above the basic 56 or 64Kbps). It contains messages that identify which bits in the H.221 framing are audio, which are video and so forth. For videophones, it's OK. But the capability reports, negotiation, etc is really intimately tied into the H.221 framing which is braindead when it comes to anything other than a px64 raw bit pipe. Why anyone would consider using H.320 for packet nets is beyond me. H.261's OK, though even there you could do a lot better, but you certainly don't want H.221 framing, and therefore by definition, the rest of H.320. Mark From list-mgr@ISI.EDU Fri Mar 24 12:07:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 02:07:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 02:07:24 -0800 Received: from octopus.cosy.sbg.ac.at ([141.201.2.63]) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 02:07:21 -0800 Received: by octopus.cosy.sbg.ac.at id AA29879 (5.65c8/IDA-1.4.4 for mbone@isi.edu); Fri, 24 Mar 1995 11:07:14 +0100 From: Reinhold Huber Message-Id: <199503241007.AA29879@octopus.cosy.sbg.ac.at> Subject: MBone tools for NeXT To: mbone Date: Fri, 24 Mar 1995 11:07:13 +0100 (MET) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 476 Hi, I wonder if there's anybody out there who is working on MBone-tools for NeXTStep. As far as I know, the 3.3.'s Mach Kernel should be able to handle multicast packets. Reini -- | Reinhold Huber | University Salzburg | | (+43) 662 8044 6324 | Dep. of Computer Science & Systems Analysis | | reini@cosy.sbg.ac.at | Jakob Haringerstrasse 5 | | huber@edvz.sbg.ac.at | 5020 Salzburg Austria Europe | From list-mgr@ISI.EDU Fri Mar 24 10:10:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 02:13:56 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 02:13:29 -0800 Received: from v6.ph.gla.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 02:11:00 -0800 Date: Fri, 24 Mar 1995 10:10:44 GMT From: "Alan J. Flavell" To: mbone Cc: FLAVELL@v2.ph.gla.ac.uk Message-Id: <950324101044.23c086be@v2.ph.gla.ac.uk> Subject: Re: Colour Maps Going Odd >If you were running Netscape as a web browser, this may have been your >problem as Netscape is very greedy with its color map, I get problems also with NCSA X Mosaic. I followed the advice I found somewhere, to run xstdcmap -default in the startup profile, and to start up nv before anything else, and start up Mosaic last. This does help, but can result in Mosaic claiming it cannot find some of the colours it needs (and displaying important text as white-on-white, etc.). I fiddled about with Mosaic's colour resources in .Xdefaults to persuade it to use some of the colours that other apps are also using. I'm still not entirely happy, but it's a lot better than before I started. p.s I am no expert in these X things, I'm just doing my best to share my experiences. If someone has a better prescription (short of advising us to buy another workstation that's not limited to 8-bit colours!) I'd be only too happy to hear it. regards From list-mgr@ISI.EDU Thu Mar 23 18:55:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 02:56:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 02:56:00 -0800 Received: from hello-kitty.cs.washington.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 02:55:59 -0800 Return-Path: Received: (cmaeda@localhost) by hello-kitty.cs.washington.edu (8.6.9/7.2ws+) id CAA04986 for mbone@isi.edu; Fri, 24 Mar 1995 02:55:23 -0800 Date: Fri, 24 Mar 1995 02:55:23 -0800 From: cmaeda@cs.washington.edu Message-Id: <199503241055.CAA04986@hello-kitty.cs.washington.edu> Apparently-To: mbone sd_listen runs fine on Nexstep 3.3. You have to compile it with the option that keeps it from trying to bind to a multicast address. From list-mgr@ISI.EDU Fri Mar 24 16:21:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 04:23:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 04:22:36 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 04:22:28 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.11/8.6.9) id OAA21688; Fri, 24 Mar 1995 14:21:32 +0200 Date: Fri, 24 Mar 1995 14:21:32 +0200 Message-Id: <199503241221.OAA21688@silver.sms.fi> From: Petri Helenius To: cmaeda@cs.washington.edu Cc: mbone Subject: nextstep tools In-Reply-To: <199503241055.CAA04986@hello-kitty.cs.washington.edu> References: <199503241055.CAA04986@hello-kitty.cs.washington.edu> cmaeda@cs.washington.edu writes: > sd_listen runs fine on Nexstep 3.3. You have to compile > it with the option that keeps it from trying to bind > to a multicast address. > But is there any "real" tools which would allow one to participate in the sessions, not just to see what is available ;) Pete From list-mgr@ISI.EDU Fri Mar 24 14:54:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 04:54:45 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 04:54:25 -0800 Received: from utrhcs.cs.utwente.nl by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 04:54:22 -0800 Received: from utis179.cs.utwente.nl by utrhcs.cs.utwente.nl (5.0/csrelayMX-SVR4_1.0/RB) id AA28619; Fri, 24 Mar 1995 13:54:14 --100 Received: by utis179.cs.utwente.nl (4.1/RBCS-1.0.1) id AA13219; Fri, 24 Mar 95 13:54:12 +0100 Message-Id: <9503241254.AA13219@utis179.cs.utwente.nl> To: Multicast Backbone Cc: kroeze@cs.utwente.nl Subject: FAQ: audio on SS5, solaris 2.4 audio patches? From: Axel Belinfante X-Organisation: University of Twente, Dept. of Computer Science, Tele Informatics Group, PO Box 217, NL-7500 AE Enschede, The Netherlands X-Phone: +31 53 89 3774 X-Telefax: +31 53 333815 X-Face: 3YGZY^_!}k]>-k'9$LK?8GXbi?vs=2v*ut,/8z,z!(QNBk_>~:~"MJ_%i`sLLqGN,DGbkT@ N\jhX/jNLTz2hO_R"*RF(%bRvk+M,iU7SvVJtC*\B6Ud<7~`MGMp7rCI6LVp=%k=HE?-UCV?[p\$R? mI\n2/!#3/wZZsa[m7d;PKWiuH6'~ Date: Fri, 24 Mar 1995 13:54:09 +0100 Sender: belinfan@cs.utwente.nl Content-Length: 1113 Hi, We have a Sparcstation 5 that runs solaris 2.4 with patches, and it suffers from the audio problem as mentioned in other messages on this list. I have scanned the mailing list archive, and found quite a number of messages, but no 'definite' answer. it has been working sort-of: we received the sunergy broadcast at the end of january, using vat with audiofile, and the sound quality was quite good, but it is unclear how the machine was configured at that time: it could even be that it run solaris 2.3 then. Right now the quality is simply unworkable: it is quite difficult to even 'hear' that there is someone speaking, because the audio sound ia terrilbly distorted. So, the question is: is is possible to get the ss5 solaris 2.4 audio 'workable', and if so, how (simple 'recipes' prefered :-)? Thanks in advance, Axel. tel. +31 53 893774 fax. +31 53 333815 University of Twente, Dept. of C.S., Tele-Informatics & Open Systems Group P.O. Box 217 NL-7500 AE Enschede The Netherlands "ili ne sciis ke estas neebla do ili simple faris" -- Loesje From list-mgr@ISI.EDU Fri Mar 24 13:33:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 05:38:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 05:36:17 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 05:36:14 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id NAA05713; Fri, 24 Mar 1995 13:33:31 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id NAA03990; Fri, 24 Mar 1995 13:33:29 GMT Date: Fri, 24 Mar 1995 13:33:27 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Axel Belinfante Cc: Multicast Backbone , kroeze@cs.utwente.nl Subject: Re: FAQ: audio on SS5, solaris 2.4 audio patches? In-Reply-To: <9503241254.AA13219@utis179.cs.utwente.nl> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 24 Mar 1995, Axel Belinfante wrote: > So, the question is: is is possible to get the ss5 solaris 2.4 audio > 'workable', and if so, how (simple 'recipes' prefered :-)? Ask your Sun support person for patch 102125-02 and if they say it hasn't been released then moan at them until they give it to you. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Fri Mar 24 15:54:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 07:55:30 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 07:55:16 -0800 Received: from mailsun.aber.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 07:55:10 -0800 Received: from mailhost.aber.ac.uk (actually host saturnbb.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Fri, 24 Mar 1995 15:54:59 +0000 To: "Alan J. Flavell" Cc: mbone, dap@aber.ac.uk Subject: Re: Colour Maps Going Odd In-Reply-To: Your message of Fri, 24 Mar 1995 10:10:44 +0000. <950324101044.23c086be@v2.ph.gla.ac.uk> Date: Fri, 24 Mar 1995 15:54:54 +0000 Message-Id: <24854.796060494@mailhost.aber.ac.uk> From: D E PRICE Dear All, I am back at `home base' again running Mbone apps and I have no (well much less) colour problems... Why have things changed I thought....... The day I was reporting problems I was away from base, logged in as root and using openwindows. Root did not have any x startup files, so I guess all the files in /usr/openwin/lib were being used. At the moment I now have olvwm as my window manager, then I had Sun's own window manager... Then I also had all the help viewers, file managers etc etc popping up...... Its look to me that Suns wm/desktop applications combination grabs lots of colours and so if I avoid them I get much better results.... Thansk for the comments many people submitted... I will try them out back in the environment I had the other day when I get the chance.. Dave Price From list-mgr@ISI.EDU Fri Mar 24 19:00:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 09:05:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 09:03:26 -0800 Received: from enst.enst.fr by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 09:03:21 -0800 Received: from inf.enst.fr (root@inf.enst.fr [137.194.2.81]) by enst.enst.fr (8.6.10/8.6.10) with ESMTP id SAA10763 for ; Fri, 24 Mar 1995 18:03:10 +0100 Received: from valjean.enst.fr (tardieu@valjean.enst.fr [137.194.160.29]) by inf.enst.fr (8.6.10/8.6.10) with ESMTP id SAA08395; Fri, 24 Mar 1995 18:00:31 +0100 From: Samuel Tardieu Received: (tardieu@localhost) by valjean.enst.fr (8.6.10/8.6.10) id SAA07491; Fri, 24 Mar 1995 18:00:28 +0100 Date: Fri, 24 Mar 1995 18:00:28 +0100 Message-Id: <199503241700.SAA07491@valjean.enst.fr> To: mbone Subject: Tunnels and UDP Reply-To: sam@inf.enst.fr Cc: sam@inf.enst.fr Hi folks. Because of recent breaks-in, our institution's headmaster has decided to restrict incoming and outgoing connections to some TCP and UDP ports. This list must be established as soon as possible. Our router does multicast tunneling (cisco, 10.2) but this doesn't seem to work anymore since we have closed almost everything but a few services. I'd like to know what port should be opened to make it work again, or what protocol number must be authorized to go through our router. I'm sure I could find this kind of information on the net, but we have to know about it very quickly, and we don't want to loose the connection to the mbone. If you send your answer to the list, please be kind enough to send me a private copy as well since I don't know how long it takes to the various lists to redistribute mails. Thanks in advance. Regards. Sam -- "La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette" Charles Baudelaire From list-mgr@ISI.EDU Fri Mar 24 11:43:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 14:00:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 14:00:01 -0800 Received: from Princeton.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 13:59:55 -0800 Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.116/princeton) id AA02787; Fri, 24 Mar 95 16:43:25 -0500 Received: from deepthought.Princeton.EDU by ponyexpress.princeton.edu (8.6.9/1.7/newPE) id QAA03076; Fri, 24 Mar 1995 16:43:22 -0500 Received: by deepthought.Princeton.EDU (4.1/Phoenix_Cluster_Client) id AA14551; Fri, 24 Mar 95 16:43:14 EST Message-Id: <9503242143.AA14551@deepthought.Princeton.EDU> X-Mailer: exmh version 1.5.3 12/28/94 To: mbone Cc: tengi@Princeton.EDU, brantley@Princeton.EDU Subject: need help with DVMRP --> PIM X-Face: Bf#x_s+*GOjDqAJ)5qI'fpm&Y2OF`RgiD2w\&Qr7ly@(yzUB)zSw#@Bj)A"3sIEwTwdBY&} #v`i+!@m"7yGc;*@Gqk_LZW4l;q8jsoEKRHL'eC|($Jc wWNl X-Uri: http://www.Princeton.EDU/~tengi/ Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Mar 1995 16:43:14 EST From: "Christopher J. Tengi" I have a tunnel from my network provider into a Sun SS5 running the 3.3 multicasting code (I know, I need to get 3.4 one of these days). I am trying to get MBone packets from this machine into a Cisco router running PIM. Here is a diagram of the part of my net in question: 232 - mc ----+--------------------+------------- | | ---+--- --------+-------- | ss5 | | maingate |------------\ ------- ----------------- | | | | | 200 - mc 120 224 128 --+-------------+----- mc mc | --------+-------- | csgate | ----------------- | | | 136 4 128 mc mc The numbers above are subnet numbers. We are doing multicasting on all of the listed subnets except 128. Right now, I have "IP multicast-routing" on both routers, and "ip pim dense-mode" on all of the required interfaces. Anything that originates locally (via sd, or any of the SGI multicast tools/games) gets spread to all of the subnets. However, sessions announced via sd on the greater MBone are only showing up on subnet 232 (where the tunnel ends). I tried adding "ip dvmrp metric 1" to the subnet 232 interface of maingate, but it made no difference in the forwarding. Also, when I do mrinfo to maingate (the "querier" only showed up on 200.200 only after I added the dvmrp metric), I get 128.112.129.36 (maingate.Princeton.EDU) [version 10.2]: 128.112.120.1 -> 0.0.0.0 (?) [1/0/querier] 128.112.224.1 -> 0.0.0.0 (?) [1/0/querier] 128.112.200.200 -> 0.0.0.0 (?) [1/0/querier] 128.112.232.1 -> 0.0.0.0 (?) [1/0/querier] When I try it on csgate I get: 128.112.200.144 (csgate.Princeton.EDU) [version 10.2]: I tried wading through the UniverCD to find all the details, but I must have missed something (not surprising, paper manuals are still easier, I need to get a copy). I assume that others out there have done this. Can anybody tell me what I am missing? Do I need to move the tunnel to maingate to have this work at all? Thanks, /Chris From list-mgr@ISI.EDU Sat Mar 25 01:04:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 15:09:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 15:08:58 -0800 Received: from faui45.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 15:08:28 -0800 Received: from faui40.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA08017 (5.65c-6/7.3w-FAU); Sat, 25 Mar 1995 00:04:51 +0100 Received: from delos (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with SMTP id AAA24404 (8.6.10/7.4a-FAU);; Sat, 25 Mar 1995 00:04:47 +0100 From: Toerless Eckert Message-Id: <199503242304.AAA24404@faui40.informatik.uni-erlangen.de> Subject: Re: need help with DVMRP --> PIM To: tengi@Princeton.EDU (Christopher J. Tengi) Date: Sat, 25 Mar 1995 00:04:44 +0100 (MET) Cc: mbone, tengi@Princeton.EDU, brantley@Princeton.EDU In-Reply-To: <9503242143.AA14551@deepthought.Princeton.EDU> from "Christopher J. Tengi" at Mar 24, 95 04:43:14 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit You've got a problem with RPF. maingate has got it's default route pointing to 128.112.128.114, i.e.: to a different interface than where the ss5 is on. This means that maingate will drop packets received from the ss5. RPF - reverse path forwarding - a multicast router forwards a multicast packet only if it comes in via the correct interface. The correct interface for a cisco is the one where it would send packets destined to the source of the multicast packet to, i.e.: the interface of the default route if you're talking about external packets. You didn't had that trouble with mrouted alone because mrouted uses it's own routing tables derived from dvmrp, whereas maingate using pim relies on the unicast routing tables. The current cisco implementation will only use dvmrp derived routing information if it's on the end of a dvmrp tunnel, but not if it's peering with some mrouted on an ethernet. So you've got a couple of solutions: a) Leave mbone alone and get some real work done. Problem with this solution: guess you don't like it. b) Put the ss5 on 128.112.128. Problem with this solution: That net is probably a serial link so you'll have trouble putting the sun. c) run the tunnels to the mbone from maingate. problem with this solution: won't work with dvmrp if the remote ends of the tunnels are ciscos too. pruning will stop to work towards the mbone. d) put the ss5 on 128.112.200 and forget about multicasting on maingate. problems with this solution: you'll loose multicasting on the maingate networks 120 and 224. e) get another router, make that one have the link to jvncnet, have 128.112.18 become an ethernet and put the ss5 there. problem with that solution: you didn't expect the spanish inquisition ? Best regards Toerless From list-mgr@ISI.EDU Fri Mar 24 11:18:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 19:19:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 19:18:36 -0800 Received: from ell.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 24 Mar 1995 19:18:34 -0800 Received: by ell.ee.lbl.gov (8.6.11/1.43r) id TAA01017; Fri, 24 Mar 1995 19:18:31 -0800 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199503250318.TAA01017@ell.ee.lbl.gov> To: "Christopher J. Tengi" Cc: mbone, tengi@Princeton.EDU, brantley@Princeton.EDU Subject: Re: need help with DVMRP --> PIM In-Reply-To: Your message of Fri, 24 Mar 95 16:43:14 -0500. <9503242143.AA14551@deepthought.Princeton.EDU> Date: Fri, 24 Mar 95 19:18:31 PST Christopher, We had a similar problem configuring pim/dvrmp at U.C. Berkeley. I believe the problem is a constraint on where you can place the pim/dvmrp interface point with respect to unicast routes. In your case, when maingate gets a multicast packet, it will flood it by forwarding it on all interface except one. The interface that doesn't get a copy of the packet is the one that would be used to reach the subnet of the source address in the packet (i.e., reverse-path forwarding). The hitch is that, for pim, the forwarding decision is based on unicast routing information. So for your topology, if maingate reaches the rest of the world via the 200 net, then it won't forward any external multicast packets to csgate. Thus, subnets fed by csgate won't ever see any mbone sources. One solution is to place your pim/dvmrp interface point near your gateway to the Internet. This will guarantee that pim's view of the reverse-path forwarding trees matches dvmrp's. Because of topology constraints, we couldn't do this at Berkeley and ended up running separate dvmrp tunnels to our two pim routers. I would love to hear about other approaches to working around this problem. Thanks, Steve From list-mgr@ISI.EDU Sat Mar 25 06:47:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 25 Mar 1995 06:47:15 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 25 Mar 1995 06:46:29 -0800 Received: from degaulle.hil.unb.ca by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 25 Mar 1995 06:46:28 -0800 Received: (spencer@localhost) by DeGaulle.hil.unb.ca (8.6.10/8.6.5) id KAA04916; Sat, 25 Mar 1995 10:47:39 -0400 Date: Sat, 25 Mar 1995 10:47:39 -0400 (AST) From: "Dwight E. Spencer" X-Sender: spencer@DeGaulle To: Wieland Holfelder Cc: Eric Paulos , Multicast Backbone Subject: Re: Colour Maps Going Odd In-Reply-To: <199503240620.WAA26238@icsib77.ICSI.Berkeley.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 24 Mar 1995, Wieland Holfelder wrote: > Eric Paulos writes: > > If you were running Netscape as a web browser, this may have been your > > problem as Netscape is very greedy with its color map, grabbing all of > > the colors and refusing to share. Try firing up Netscape last so that > ... or start netscape with "netscape -install" so it uses its > own privat color map and does not steal any colors. (you will, > however, get crazy colors when the mousepointer leaves netscape...) Or, if you have the capability, run your window system with something higher than 8bit color. On my sparc20m I can run in 24bit color, run a full color graphic as the wallpaper, have netscape loaded, a video session from sd, and -no- colormap flickering. Granted, it is about 10-15% slower when redrawing the screen, but I don't mind that. It's that or the blasted colormap flashing. You need a different video card in your workstation. Whatever the sparc 20 m's come with should do. It's not realy my machine, but if someone wants to really know, I can find out. Here is what I start openwin windows with... ~/bin/openwin24 #!/usr/bin/sh openwin -dev /dev/fbs/cgfourteen0 defclass TrueColor defdepth 24 -nobanner -- You -do- need the cgfourteen0 frame buffer. Another person in our department has the sun video addition to his system, as well as "cgsix" which will not support 24bit color openwindows. dwight. ------------------------------------------------------------------------------ Dwight E. Spencer University of New Brunswick Email: spencer@unb.ca, dwight@www.unb.ca Http://www.unb.ca/staff/dspencer.html Computing Services Department ..... Phone: (506) 453 4573 Harriet Irving Library ............. (506) 453 4740 (ext. 6889) University of New Brunswick WWW Project: ........ Email to: www@www.unb.ca From list-mgr@ISI.EDU Sat Mar 25 10:04:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 25 Mar 1995 19:49:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 25 Mar 1995 18:09:05 -0800 Received: from global1.global.net by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 25 Mar 1995 18:09:04 -0800 Received: by global1.global.net (8.6.9/2.29) id SAA00450; Sat, 25 Mar 1995 18:04:37 -0800 Date: Sat, 25 Mar 1995 18:04:37 -0800 From: ina@global.net (internet access - Alfredo Lusa) Message-Id: <199503260204.SAA00450@global1.global.net> To: mbone Subject: mbone address... Hi Guys, Super newbie question. nv asks me for an address to open. which one should I give it? From list-mgr@ISI.EDU Sat Mar 25 12:55:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 25 Mar 1995 22:38:18 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 25 Mar 1995 20:56:41 -0800 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 25 Mar 1995 20:56:41 -0800 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA14982; Sat, 25 Mar 95 20:55:47 PST From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9503260455.AA14982@taurus.cs.nps.navy.mil> Subject: Re: Regarding the Hamming on Hamming MBone course To: jed@llnl.gov (James E. [Jed] Donnelley) Date: Sat, 25 Mar 1995 20:55:47 -0800 (PST) Cc: brutzman@cs.nps.navy.mil, mbone, rem-conf@es.net, tlemswil@nps.navy.mil (Tracey L Emswiler) In-Reply-To: <9503232038.AB04270@ocfmail.ocf.llnl.gov> from "James E. [Jed] Donnelley" at Mar 23, 95 09:38:28 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 4615 As usual Jed makes some key points. The partial deployment of pruning appears to make transatlantic links particularly vulnerable. Does it make more sense to multicast this course with a ttl corresponding to North America? Does such a value exist? If so, how is it best determined? Using a lower ttl that avoids borderline links might also permit multicasting this course without schedule choreography between IETF Danvers, WWW International, Interactive 3D Graphics Symposium et al. thanks for opinions, Don James E. [Jed] Donnelley writes: > > that you propose to multicast worldwide: > > Tuesday March 28 through Friday June 9. > Tuesdays and Thursdays 1210-1300 Pacific (1910-2000 GMT), > Fridays 1410-1500 Pacific (2110-2200 GMT). > > I noticed that you sent your message to rem-conf@es.net > I thought such messages (i.e. scheduling MBone slots) were > to go to mbone@isi.edu. If I am right about this perhaps > this message (cc'ed to the mbone list) will serve. > > However, the reason I am writing is to question the usefulness > of such an effort to "push back the envelope" regarding the kinds > of programming possible on the MBone by regular transmission > of programming with a global scope (ttl). > > First I should say that I would love to be able to participate > in Dr. Hamming's course. I believe that wherever it could be > successfully transmitted that it would be a good use of > Internet and MBone bandwidth. > > However, my experience (here in Germany anyway) suggests > that if I am either here in the evening trying to work or if I > specifically come in and try to listen in, even given that the > schedule puts it in the evening local time, the performance > will be such that I will not really be able to understand > what is being said most of the time and I will not be able > to effectively participate. > > So from my perspective, I loose at least a hundred kilobits > of Internet bandwidth coming from the US (not to mention > MBone bandwidth) whenever these course presentations are > running and I get nothing out of it. > > The present bandwidth available here in Germany is such > that (global) MBone demonstrations are largely only able > to show what would be possible with more bandwidth. > Sure, we can set up special or dedicated links and put on > a nice show. Just about anything we want to do on > the local LAN is CPU limited and works pretty well. > But Internet losses are typically so high that usually > things coming in with high ttls from the US or elsewhere > are enticing, trying to catch meaning in the blits and blats > of audio that come through (sound familiar?), but really > useless as far as real content goes. > > So in terms of a Masters project to "push back the envelope", > it would seem to me that as far as ttl 127 transmission goes, > you will be able to get the learning done during the first > transmission. If you then cut back to a ttl that allows you > to really get through to most of those that you reach then > continued transmission might continue to be a learning > exercise. > > However, to continue to bang on the network (don't tell > me about pruning in Europe - even with pruning somebody > is sure to tune in, so the choke points will be seeing that data) > doesn't seem to me to serve any useful purpose. > > As I see it, global MBone transmissions are useful for > tantalizing demonstrations of what might some day be > possible, but to expect to get useful communication done > with such transmissions on a regular basis is still beyond > the current capabilities. > > Having said all that, if you do go ahead, please include > any visual materials on a whiteboard multicast. Sometimes > these whiteboard multicasts get through reasonably > (though even they often have problems) with retransmissions. > If you are going to interview listeners to get their experiences, > at least with a whiteboard they will have something to look > at while they gather their experiences. > > It seems to me that to "push back the envelope" of > multimedia multicasts simply takes more bandwidth. > Many people are working on this in one area or another. > To pound on an inadequate infrastructure in a sustained > way does not strike me as a way to make progress, > no matter how excellent the source material. > > --Jed http://www-atp.llnl.gov/atp/jed.html -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv.html From list-mgr@ISI.EDU Sat Mar 25 16:45:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 02:24:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 00:45:21 -0800 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 00:45:18 -0800 Posted-Date: Sun 26 Mar 95 00:45:09 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Sun, 26 Mar 95 00:45:11 PST Date: Sun 26 Mar 95 00:45:09 PST From: Stephen Casner Subject: rem-conf vs. mbone vs. newsgroup (was: Regarding the Hamming ...) To: jed@llnl.gov Cc: rem-conf@es.net, MBONE Message-Id: <796207509.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9503232038.AB04270@ocfmail.ocf.llnl.gov> Mail-System-Version: Jed, > I noticed that you sent your message to rem-conf@es.net > I thought such messages (i.e. scheduling MBone slots) were > to go to mbone@isi.edu. Actually, no. The convention that we had set up was that the mbone list was to concentrate on MBone engineering issues and problems with the multicast kernel and mrouted software, so the audience was intended to be those people who operate multicast routers. The rem-conf list, on the other hand, discusses more general conferencing issues. More end-users are there, and so that's where the announcements were supposed to go. (It was assumed that most people on the mbone list were also on rem-conf.) I'm using the past tense in the paragraphs above because recently Ari Ollikainen, the keeper of the rem-conf list, told me that he'd like to get that list out of the business of carrying MBone event announcements. I'm willing to go along with that, but moving them to the mbone list would be no better. Ideally, there should be a fully dynamic scheduling calendar that distributes its data via multicast and all that other wonderful stuff. The www calendar at http://www.cilea.it/MBone/agenda.html is a good start, and event organizers should post there. However, there may still be a need for a list-like function. In order to keep that manageable as the number of interested people continues to grow, I agree with the suggestion that has been made at several times in the past that it should be a newsgroup. Since I don't do netnews at all (as a matter of load avoidance), I am hoping that someone else out there will volunteer to coordinate the voting procedure and whatever else would be required to get a new newsgroup established to carry mbone announcements. Any takers? In my view, it would be best to have the newsgroup be limited to just the announcement function, but I don't know what mechanisms would be required to keep it that way. -- Steve ------- From list-mgr@ISI.EDU Sun Mar 26 16:13:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 18:13:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 18:13:23 -0800 Received: from noc.sura.net by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 18:13:22 -0800 Received: from aotearoa.sura.net (aotearoa.sura.net [128.167.254.175]) by noc.sura.net (8.6.8.1/8.6.6) with ESMTP id VAA00516; Sun, 26 Mar 1995 21:13:13 -0500 Received: from localhost (localhost [127.0.0.1]) by aotearoa.sura.net (8.6.10/8.6.10) with SMTP id VAA16783; Sun, 26 Mar 1995 21:13:12 -0500 Message-Id: <199503270213.VAA16783@aotearoa.sura.net> X-Authentication-Warning: aotearoa.sura.net: Host localhost didn't use HELO protocol To: mbone Cc: "Todd L. Montgomery" Subject: Re: mrouted and netmasks In-Reply-To: Your message of "Sun, 26 Mar 1995 12:09:01 EST." Date: Sun, 26 Mar 1995 21:13:11 -0500 From: Erik Sherk Hi, I know that I have seen this question answered before, but I can't remember the answer. Can anyone help? thanks... Erik > > Erik, > > Sorry to bother you. > Some machines on the same LAN as hopper (The machine at CS that is mrouted > connected to SUARnet) don't see multicast packets. It seems that they > are on a different netmask (The actual address is 157.128.112.183). > How can I setup hooper's mrouted.conf file to forward to this netmask? > Or should I just work on the specific machines to enable them to see > the packets? > > Thanks! > > -- Todd > From list-mgr@ISI.EDU Mon Mar 27 22:24:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 19:25:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 19:25:06 -0800 Received: from tigger.cs.adelaide.edu.au by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 19:24:42 -0800 Received: from chook.cs.adelaide.edu.au (via delivery) by tigger.cs.adelaide.edu.au with SMTP (5.65/UA-5.20) id AA01868; Mon, 27 Mar 95 12:54:39 +0930 X-Authentic-Sender: matthew@chook.cs.adelaide.edu.au Received: by chook.cs.adelaide.edu.au (5.65/SMI-4.1)id AA29499; Mon, 27 Mar 95 12:54:37 +0930 Date: Mon, 27 Mar 95 12:54:37 +0930 From: matthew@cs.adelaide.edu.au (Matthew Donaldson) Message-Id: <9503270324.AA29499@chook.cs.adelaide.edu.au> To: mbone Subject: Multicast + ATM problems Hi all. This is pretty obscure. I'm trying to get the following to work together: SunOS 4.1.4 (on a SS10) Multicast 3.3 Fore Systems ATM card driver It seems under 4.1.4 that the last two things are incompatible - with both installed under 4.1.4, attempts to use the ATM stuff crash the kernel. Under 4.1.3 U1, they seem to work together without problems. Anyone have any ideas? Copious log info follows: Mar 20 12:46:24 zebedee vmunix: BAD TRAP: cpu=0 type=7 rp=fd002c4c addr=0 mmu_fs r=0 rw=0 Mar 20 12:46:24 zebedee vmunix: MMU sfsr=0: No Error Mar 20 12:46:24 zebedee vmunix: regs at fd002c4c: Mar 20 12:46:24 zebedee vmunix: psr=41000ac7 pc=f005078c npc=f005075c Mar 20 12:46:24 zebedee vmunix: y: 30000000 g1: a00 g2: 2290 g3: ffffff00 Mar 20 12:46:24 zebedee vmunix: g4: 0 g5: f13a7000 g6: 0 g7: 0 Mar 20 12:46:24 zebedee vmunix: o0: 38 o1: 0 o2: 817f943c o3: 817f0000 Mar 20 12:46:24 zebedee vmunix: o4: fb01774a o5: e sp: fd002c98 ra: 0 Mar 20 12:46:24 zebedee vmunix: pid 12312, `receiver': Memory address alignment Mar 20 12:46:24 zebedee vmunix: rp=0xfd002c4c, pc=0xf005078c, sp=0xfd002c98, psr =0x41000ac7, context=0xa73 Mar 20 12:46:24 zebedee vmunix: g1-g7: a00, 2290, ffffff00, 0, f13a7000, 0, 0 Mar 20 12:46:24 zebedee vmunix: Begin traceback... sp = fd002c98 Mar 20 12:46:24 zebedee vmunix: Called from f0052e64, fp=fd002cf8, args=ff04f3f0 ff050d20 100 41800ae0 0 e Mar 20 12:46:24 zebedee vmunix: Called from f018ece0, fp=fd002d58, args=ff04f3f0 ff050d20 fd00a800 f0284ba0 41400ae1 ff04ded8 Mar 20 12:46:24 zebedee vmunix: Called from f018e9c0, fp=fd002db8, args=ff04f438 ff050d20 ff05071c 419003e2 ff050d20 ff050700 Mar 20 12:46:24 zebedee vmunix: Called from f018e690, fp=fd002e18, args=20 e 2 3 a6 ff050d20 ff050d20 Mar 20 12:46:24 zebedee vmunix: Called from f019b104, fp=fd002e78, args=f0240ef0 e 0 fb1b5000 1000 100 Mar 20 12:46:24 zebedee vmunix: Called from f0199e38, fp=fd002ed8, args=f0240ef0 e 0 ff050d08 fb02e070 fb02e070 Mar 20 12:46:24 zebedee vmunix: Called from f0199bc4, fp=fd002f40, args=fb02e070 23 0 fb02f404 f028b604 fff003a0 Mar 20 12:46:24 zebedee vmunix: Called from f0006894, fp=fd002fa0, args=0 2024c 1 0 0 fb02e070 Mar 20 12:46:24 zebedee vmunix: Called from f0128de4, fp=f13a6d88, args=3 efffab b0 0 f0129590 1ec5c500 20 Mar 20 12:46:24 zebedee vmunix: End traceback... Mar 20 12:46:24 zebedee vmunix: panic on cpu 0: Memory address alignment Mar 20 12:46:24 zebedee vmunix: BAD TRAP: cpu=0 type=9 rp=fd00284c addr=120 mmu_ fsr=3a6 rw=2 Mar 20 12:46:24 zebedee vmunix: MMU sfsr=3a6: Invalid Address on supv data store at level 3 [it goes on to have other faults and things] The stack trace for this looks like this: f0052e64?a _strrput+0x2d4: _strrput+0x2d4: f018ece0?a _fore_atm_put_strq+0x4c: _fore_atm_put_strq+0x4c: f018e9c0?a _fore_atm_stream_dispatch+0x1f8: _fore_atm_stream_dispatch+0x1f8: f018e690?a _fore_atm_to_stream_sbuf+0x5c: _fore_atm_to_stream_sbuf+0x5c: f019b104?a _fore_deliver_sbuf_pdu+0x40: _fore_deliver_sbuf_pdu+0x40: f0199e38?a _pdu_received+0x230: _pdu_received+0x230: f0199bc4?a _fa_200_poll+0x88: _fa_200_poll+0x88: f0006894?a level3+0x40: level3+0x40: f0128de4?a alwordcp: alwordcp: alwordcp: All hints/help appreciated. Thanks in advance -Matthew +--------------------------------------------------------------------------+ | Matthew Donaldson Email: matthew@cs.adelaide.edu.au | | Computer Science Department Phone: +61 8 303 5583 _ | | University of Adelaide Fax: +61 8 303 4366 John / \/ | | South Australia 5005 Telex: UNIVAD AA89141 3:16 \_/\ | +--------------------------------------------------------------------------+ From list-mgr@ISI.EDU Sun Mar 26 12:47:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 21:04:46 -0800 Received: from mv.MV.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 21:04:44 -0800 Received: from maple.mv.com by mv.mv.com (8.6.10/mv(b)/mem-940616) id AAA07921; Mon, 27 Mar 1995 00:04:36 -0500 Received: from venera.isi.edu by mv.mv.com (8.6.10/mv(b)/mem-940616) id XAA28888 for ; Sun, 26 Mar 1995 23:47:10 -0500 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 20:47:07 -0800 Message-Id: <199503270447.AA23753@venera.isi.edu> Resent-Message-Id: Priority: Normal To: coutu@maple.MV.COM Resent-To: rem-conf@es.net Resent-Cc: mbone-na Mime-Version: 1.0 From: MAILER-DAEMON@ISI.EDU Resent-From: Dan Coutu Subject: Spring DECUS speakers, advice on ttl values? Date: Sun, 26 Mar 1995 20:47:07 -0800 Resent-Date: Mon, 27 Mar 95 00:04:14 EST Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Discussions on rem-conf have indicated that schedule announcements are generally discouraged there. My subscription to the mbone list has been in the request queue over a month now so I'm unsure of the discussion there. :-( I have used the web page at http://www.cilea.it/MBone/agenda.html to book a set of four sessions from May 8 to 11. What I'd like to get a sense of from your collected wisdom/opinions is what type of ttl value would appropriate for these sessions? Here's the nutshell description of the sessions. DECUS, the Digital Equipment Corp. User's Society (an independent non-profit organization, not a part of Digital), is holding their spring convention in Washington, DC with a focus on the Internet. They want to 'broadcast' four speakers. Enrico Pesatori, a VP at Digital, will give a keynote speech about the Internet. Dr. Bill Hancock, Executive Vice President of Network-1, will talk about "Industry Trends and Futures". Tim Berners-Lee will talk about the World Wide Web and Marc Andreessen will talk about "In the Internet Fast Lane". I expect that at least some of these will have widespread interest. All sessions are to be public. Both audio and video will be present. No whiteboard. In addition I'll have the IRC channel #DECUS setup and monitored. For sessions with abstracts available beforehand I'll be using expect to 'type' in the talk so that those unable to receive MBone can still learn about what is said. IRC will also enable questions to be posed of the speakers. Any suggestions? I don't want to flood the world if the world has no interest but also don't want to leave out interested parties by too small a ttl. Thanks! Dan Coutu coutu@convergent.com coutu@maple.mv.com Dan Coutu "The Web is a harsh mistress" coutu@maple.mv.com From list-mgr@ISI.EDU Sun Mar 26 21:55:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 23:55:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 23:55:14 -0800 Received: from bos1e.delphi.com by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 26 Mar 1995 23:55:12 -0800 Received: from delphi.com by delphi.com (PMDF V4.3-9 #7804) id <01HOM5KMVGAO8Y67SI@delphi.com>; Mon, 27 Mar 1995 02:55:07 -0500 (EST) Date: Mon, 27 Mar 1995 02:55:07 -0500 (EST) From: ADAMGOOD@delphi.com Subject: Re: rem-conf vs. mbone vs. newsgroup (was: Regarding the Hamming ...) To: CASNER Cc: mbone Message-Id: <01HOM5KMVGAQ8Y67SI@delphi.com> X-Vms-To: IN%"CASNER@ISI.EDU" X-Vms-Cc: IN%"mbone@isi.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Steve, wouldn't there be a problem with posting event scheduals, given the propogation times necessary for Usenet posting to reach all the nodes on the 'Net? I would think that last minute schedualings especially would become impossible in a newsgroup environment. Am I completely wrong about this? -Adam From list-mgr@ISI.EDU Tue Mar 28 03:13:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 01:14:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 01:13:59 -0800 Received: from kagulx4.cc.kagu.sut.ac.jp by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 01:13:56 -0800 Received: by kagulx4.cc.kagu.sut.ac.jp (5.x/3.3W/solaris2-940627) id AA02711; Mon, 27 Mar 1995 18:13:32 +0900 Date: Mon, 27 Mar 1995 18:13:32 +0900 From: Devendra Narayan Message-Id: <9503270913.AA02711@kagulx4.cc.kagu.sut.ac.jp> To: MBONE Subject: Needed .sd.tcl Organization: Science University of Tokyo X-Sun-Charset: US-ASCII Being no 'expert' in TCL, I am looking for a .sd.tcl script that is 'most complete' ( in the sense that it would set your desired name in vat etc., start up vat, nv, vic, ivs, imm, wb, Mosaic, Netscape etc. - all the well known mbone tools ! ). Would really appreciate if anyone can send me such a file ( or better still - post it to the list as I am sure there probably are a few others who would appreciate it ! ). Thanks and regards, Devendra Narayan March 27th. 1995 ( narayan@sut.ac.jp ) From list-mgr@ISI.EDU Tue Mar 28 07:17:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 03:18:17 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 03:17:41 -0800 Received: from mullian.ee.mu.OZ.AU by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 03:17:40 -0800 Received: from rees.ee.mu.OZ.AU by mullian.ee.mu.OZ.AU with SMTP id AA12075 (5.67b/IDA-1.5 for ); Mon, 27 Mar 1995 21:17:38 +1000 youdy (rfc931-sender: youdy@rees.ee.mu.OZ.AU) From: Hu Youdy Received: (youdy@localhost) by rees.ee.mu.OZ.AU (8.6.10/8.6.10) id VAA14816 for mbone@isi.edu; Mon, 27 Mar 1995 21:17:37 +1000 Date: Mon, 27 Mar 1995 21:17:37 +1000 Message-Id: <199503271117.VAA14816@rees.ee.mu.OZ.AU> To: mbone Subject: Re. MPEG book Would anyone recommend me a good book about MPEG (especially MPEG 2) and related video compression? Thank you. From list-mgr@ISI.EDU Mon Mar 27 22:27:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 08:29:26 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 08:27:22 -0800 Received: from cc.lut.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 08:27:20 -0800 Received: (from ruokonen@localhost) by cc.lut.fi (8.6.11/8.6.6/1.17.kim) id TAA12027; Mon, 27 Mar 1995 19:27:04 +0300 From: Vesa Ruokonen Message-Id: <199503271627.TAA12027@cc.lut.fi> Subject: Re: mrouted and netmasks To: sherk@sura.net (Erik Sherk) Date: Mon, 27 Mar 1995 19:27:04 +0300 (EETDST) Cc: mbone, tmont@cerc.wvu.edu In-Reply-To: <199503270213.VAA16783@aotearoa.sura.net> from "Erik Sherk" at Mar 26, 95 09:13:11 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3230 > I know that I have seen this question answered before, but > I can't remember the answer. Can anyone help? thanks... Hint: ftp://ftp.isi.edu/mbone/mbone.mail* > > Some machines on the same LAN as hopper (The machine at CS that is mrouted > > connected to SUARnet) don't see multicast packets. It seems that they > > are on a different netmask (The actual address is 157.128.112.183). I use following patch with mrouted-3.3 and 'weird' netmask. To: mbone@ISI.EDU Subject: subnet masks and mrouted Date: Wed, 21 Sep 94 23:30:03 +0200 From: klemets@it.kth.se -------- We have a Class B IP network and we don't use subnetting with it. Sometimes we have multiple "subnets" on the same physical link, so we cannot use subnetting. This causes a lot of trouble if we try to run more than mrouted on the Class B network. Since our network consists of many ethernet segments separated by routers, we must have one mrouted on each segment. But since the subnet mask is not set, each mrouted will try to announce the whole Class B network. A couple of years ago, I wrote a small fix to mrouted that allows one to work around this problem. I added an extra "mask" option to the "phyint" command. This option allows one to specify a subnet mask for ones interface, even though the subnet mask may not be set in the kernel. An example command is "phyint 1230.237.215.43 mask 0xffffff00" I am not hacking on mrouted at the moment, and the system administrators at my site are becoming desperate because they want to use the latest versions of mrouted and they don't have this patch. So I am posting my latest version of the patch as a part of this message. The patch is from May last year for the, then newly released, version of mrouted that used IP encapsulation for tunneling. I am posting the patch 1) for reference, so that people will stop asking me about it, 2) in the hope that somebody will incorporate it into new releases of mrouted. Anders *** config.c Sun May 30 03:41:16 1993 --- ../mrouted-encap/config.c Mon Apr 5 21:50:19 1993 *************** *** 214,220 **** } /* ! * Look for "disable", "metric" and "threshold" options. */ while (!EQUAL((w = next_word(&s)), "")) { if (EQUAL(w, "disable")) { --- 214,220 ---- } /* ! * Look for "disable", "metric" and "threshold" and "mask" options. */ while (!EQUAL((w = next_word(&s)), "")) { if (EQUAL(w, "disable")) { *************** *** 253,258 **** --- 253,276 ---- break; } v->uv_threshold = n; + } + else if (EQUAL(w, "mask")) { + if(EQUAL((w = next_word(&s)), "")) { + log(LOG_WARNING, 0, + "missing mask for phyint %s in %s", + inet_fmt(lcl_addr, s1), configfilename); + w = "garbage"; + break; + } + if(sscanf(w, "0x%x%c", &n, &c) != 1 || + !inet_valid_subnet(lcl_addr & n, n)) { + log(LOG_WARNING, 0, + "invalid mask '%s' for phyint %s in %s", + w, inet_fmt(lcl_addr, s1), configfilename); + break; + } + v->uv_subnetmask = n; + v->uv_subnet = lcl_addr & n; } else break; } -- Vesa.Ruokonen@lut.fi From list-mgr@ISI.EDU Mon Mar 27 00:25:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 08:34:18 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 08:33:55 -0800 Received: from framsparc.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 08:33:54 -0800 Received: by framsparc.ocf.llnl.gov (4.1/SMI-4.0) id AA14032; Mon, 27 Mar 95 08:25:51 PST From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian) Message-Id: <9503271625.AA14032@framsparc.ocf.llnl.gov> Subject: Re: rem-conf vs. mbone vs. newsgroup (was: Regarding the Hamming ...) To: ADAMGOOD@delphi.com Date: Mon, 27 Mar 1995 08:25:51 -0800 (PST) Cc: CASNER, mbone In-Reply-To: <01HOM5KMVGAQ8Y67SI@delphi.com> from "ADAMGOOD@delphi.com" at Mar 27, 95 02:55:07 am X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1437 >wouldn't there be a problem with posting event scheduals, given the propogation >times necessary for Usenet posting to reach all the nodes on the 'Net? > >I would think that last minute schedualings especially would become impossible >in a newsgroup environment. Am I completely wrong about this? Propagation delay is definitely a factor with USENET. However, I believe that significant propagation delays would only be encountered by sites receiving news via UUCP. Presumably sites receiving news via NNTP would see articles in as timely a fashion as those receiving email via a mailing list. One question you might ask is that if a site receives its USENET feed via UUCP, is it likely to be connected to the MBone? My guess would be no, but I have no data to support it. A bigger problem with USENET announcements might be expiration of articles. Someone who sent out an announcement very early on might find that by the time the date of their event rolls around, lots of sites have expired the article, and lots of folks don't know about the event. I don't know enough about USENET to know if, when a new group is created, a recommended expiration time can be suggested. My guess is that is strictly a local issue. Personally, the web solution is appealing. I believe a mailing list is still necessary for discussion of scheduling-related issues, but the web seems a natural for keeping placemarks for all too see. mb From list-mgr@ISI.EDU Mon Mar 27 20:58:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 09:08:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 09:08:15 -0800 Received: from utrhcs.cs.utwente.nl by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 09:08:09 -0800 Received: from utis179.cs.utwente.nl by utrhcs.cs.utwente.nl (5.0/csrelayMX-SVR4_1.0/RB) id AA04867; Mon, 27 Mar 1995 19:00:32 --100 Received: by utis179.cs.utwente.nl (4.1/RBCS-1.0.1) id AA05912; Mon, 27 Mar 95 18:58:58 +0200 Message-Id: <9503271658.AA05912@utis179.cs.utwente.nl> X-Mailer: exmh version 1.5.3 12/28/94 To: mbone Subject: Video mixing/splitting? From: Axel Belinfante X-Organisation: University of Twente, Dept. of Computer Science, Tele Informatics Group, PO Box 217, NL-7500 AE Enschede, The Netherlands X-Phone: +31 53 89 3774 X-Telefax: +31 53 333815 X-Face: 3YGZY^_!}k]>-k'9$LK?8GXbi?vs=2v*ut,/8z,z!(QNBk_>~:~"MJ_%i`sLLqGN,DGbkT@ N\jhX/jNLTz2hO_R"*RF(%bRvk+M,iU7SvVJtC*\B6Ud<7~`MGMp7rCI6LVp=%k=HE?-UCV?[p\$R? mI\n2/!#3/wZZsa[m7d;PKWiuH6'~ tel. +31 53 893774 fax. +31 53 333815 University of Twente, Dept. of C.S., Tele-Informatics & Open Systems Group P.O. Box 217 NL-7500 AE Enschede The Netherlands "ili ne sciis ke estas neebla do ili simple faris" -- Loesje From list-mgr@ISI.EDU Mon Mar 27 04:50:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 12:51:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 12:51:16 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 12:51:15 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14456(5)>; Mon, 27 Mar 1995 12:51:01 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Mon, 27 Mar 1995 12:50:58 -0800 X-Mailer: exmh version 1.6beta 3/23/95 To: Erik Sherk Cc: mbone, "Todd L. Montgomery" Subject: Re: mrouted and netmasks In-Reply-To: Your message of "Sun, 26 Mar 95 18:13:11 PST." <199503270213.VAA16783@aotearoa.sura.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Mar 1995 12:50:51 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <95Mar27.125058pst.49859@crevenia.parc.xerox.com> In message <199503270213.VAA16783@aotearoa.sura.net> you write: >> Some machines on the same LAN as hopper (The machine at CS that is mrouted >> connected to SUARnet) don't see multicast packets. It seems that they >> are on a different netmask (The actual address is 157.128.112.183). >> How can I setup hooper's mrouted.conf file to forward to this netmask? It appears that hopper's netmask is 255.255.255.128, and it is in subnet 157.128.112.0, but is on the same wire as 157.128.112.128 . I don't know why anyone would want to set their network up this way, but assuming there is a reason, mrouted 3.5 will handle this situation by saying something like phyint le0 altnet 157.128.112.128/25 Anders Klemets' patch that Vesa Ruokonen reposted should also work in this specific case, where two adjacent subnets are on the same wire, by just making the subnet mask one bit narrower. Bill From list-mgr@ISI.EDU Mon Mar 27 07:44:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 13:45:18 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 13:44:56 -0800 Received: from scapa.cs.ualberta.ca by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 13:44:55 -0800 Received: from sunnyslope.cs.ualberta.ca by scapa.cs.ualberta.ca id <13061-4>; Mon, 27 Mar 1995 14:44:44 -0700 Subject: Video mixing/splitting? (fwd) From: Kannan Thiruvengadam To: mbone Date: Mon, 27 Mar 1995 14:44:37 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 947 Message-Id: <95Mar27.144444-0700_mst.13061-4+13@scapa.cs.ualberta.ca> Forwarded message: > > Hi, > > The question we have is the following: would it be possible in some way > or another to 'rebroadcast' our 'virtual speaker' on (the dutch part of) > the mbone, but with a reduced bandwith? Something like the 'vat' mixer mode, > but then for video? Or would it be possible to have our virtual speaker > participate in two video conferences at the same time: a 'local' 'high speed' > one, and another 'non-local' low-bandwidth one, using only one camera and > one framegrabber card (SunVideo)in his sun? > > (I do seem to recall having seen an announcement that mentioned that their > broadcast would be 'high bandwidth' at their own site, and 'low bandwidth' > on the remaining part of the mbone, but i couldn't find it back... :-/ > Please cc your response to kannan@cs.ualberta.ca My interest is in knowing what methods are used to decode and reencode recorded video to a lower bit-rate. Thanks - Kannan From list-mgr@ISI.EDU Mon Mar 27 07:28:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 15:29:20 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 15:29:05 -0800 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 27 Mar 1995 15:28:58 -0800 Posted-Date: Mon 27 Mar 95 15:28:46 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Mon, 27 Mar 95 15:28:47 PST Date: Mon 27 Mar 95 15:28:46 PST From: Stephen Casner Subject: Re: Regarding the Hamming on Hamming MBone course To: brutzman@cs.nps.navy.mil Cc: MBONE, rem-conf@es.net Message-Id: <796346926.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9503260455.AA14982@taurus.cs.nps.navy.mil> Mail-System-Version: Don, > Does it make more sense to multicast this course with a ttl > corresponding to North America? Does such a value exist? Unfortunately, such a value does not exist. I think most of the international links are at threshold 64, but so are many of the links within the US. We should probably try to establish a new convention within the US, but getting all the links changed is a lengthy process. > Using a lower ttl that avoids borderline links might also permit > multicasting this course without schedule choreography between > IETF Danvers, WWW International, Interactive 3D Graphics Symposium > et al. I like your phrase -- indeed the scheduling next week is going to require some choreography. I've just seen some notices about activities planned at UIUC as well. -- Steve ------- From list-mgr@ISI.EDU Mon Mar 27 18:42:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 28 Mar 1995 08:55:54 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 28 Mar 1995 08:55:04 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 28 Mar 1995 08:55:03 -0800 Received: from sparc13.cs.uiuc.edu by quark.isi.edu (5.65c/5.61+local-20) id ; Mon, 27 Mar 1995 22:47:18 -0800 Received: by sparc13.cs.uiuc.edu id AA21646 (5.67b/IDA-1.5 for mbone@isi.edu); Tue, 28 Mar 1995 00:42:37 -0600 From: jak@sparc13.cs.uiuc.edu Message-Id: <199503280642.AA21646@sparc13.cs.uiuc.edu> Subject: MBONE booking To: rem-conf@es.net, mbone Date: Tue, 28 Mar 1995 00:42:36 -0600 (CST) Cc: jak@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 903 The ACM at UIUC student chapter would like to broadcast our April general meeting over the MBONE. Gene Spafford be our guest. The time we need is Wed. April 5th from 1800-1900 EDT. This time does not conflict with the IETF broadcasts, but I think it might overlap with one of the IEEE Infocom broadcasts (anyone?). We will be sending video (nv), audio (vat), and text (MUMBLE (see: http://www.acm.uiuc.edu/signet/projects/mumble.html)). Please advise of any problems. -j, ACM@UIUC network admin. -- Jay A. Kreibich University of Illinois, U/C Undergrad Computer Science ------------------------------------------------------------------------------ "You think that I want to be understood..." -They Might Be Giants ------------------------------------------------------------------------------ My Home Page From list-mgr@ISI.EDU Wed Apr 1 11:21:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 29 Mar 1995 13:33:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 29 Mar 1995 13:32:54 -0800 Received: from Princeton.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 29 Mar 1995 13:32:53 -0800 Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.116/princeton) id AA06296; Wed, 29 Mar 95 16:22:19 -0500 Received: from deepthought.Princeton.EDU by ponyexpress.princeton.edu (8.6.9/1.7/newPE) id QAA21952; Wed, 29 Mar 1995 16:22:14 -0500 Received: by deepthought.Princeton.EDU (4.1/Phoenix_Cluster_Client) id AA27472; Wed, 29 Mar 95 16:21:39 EST Message-Id: <9503292121.AA27472@deepthought.Princeton.EDU> X-Mailer: exmh version 1.5.3 12/28/94 To: mbone Subject: looking for sd-launch X-Face: Bf#x_s+*GOjDqAJ)5qI'fpm&Y2OF`RgiD2w\&Qr7ly@(yzUB)zSw#@Bj)A"3sIEwTwdBY&} #v`i+!@m"7yGc;*@Gqk_LZW4l;q8jsoEKRHL'eC|($Jc wWNl X-Uri: http://www.Princeton.EDU/~tengi/ Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Mar 1995 16:21:38 EST From: "Christopher J. Tengi" Where can I find the latest version of sd-launch? Thanks, /Chris From list-mgr@ISI.EDU Wed Apr 1 08:39:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 29 Mar 1995 16:40:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 29 Mar 1995 16:40:02 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 29 Mar 1995 16:40:01 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14464(4)>; Wed, 29 Mar 1995 16:39:46 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <49864>; Wed, 29 Mar 1995 16:39:41 -0800 X-Mailer: exmh version 1.6gamma- 3/28/95 To: "Christopher J. Tengi" Cc: mbone Subject: Re: looking for sd-launch In-Reply-To: Your message of "Wed, 29 Mar 95 13:21:38 PST." <9503292121.AA27472@deepthought.Princeton.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Mar 1995 16:39:25 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <95Mar29.163941pst.49864@crevenia.parc.xerox.com> In message <9503292121.AA27472@deepthought.Princeton.EDU> you write: >Where can I find the latest version of sd-launch? I'm afraid that for now, ftp://town.hall.org/pub/software/sd_launch.tar.gz is your best bet. I unexpectedly lost my software distribution site when I left NRL, and haven't generated a new release yet (too busy trying to get the 3.5 multicast release going...) Bill From list-mgr@ISI.EDU Wed Apr 1 14:27:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 29 Mar 1995 22:30:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 29 Mar 1995 22:29:01 -0800 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 29 Mar 1995 22:28:59 -0800 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA04483; Wed, 29 Mar 95 22:27:58 PST From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9503300627.AA04483@taurus.cs.nps.navy.mil> Subject: Re: Hamming multicast series comments To: CASNER (Stephen Casner) Date: Wed, 29 Mar 1995 22:27:58 -0800 (PST) Cc: rem-conf@es.net, mbone In-Reply-To: <796430625.0.CASNER@XFR.ISI.EDU> from "Stephen Casner" at Mar 28, 95 02:43:45 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 5644 Here are some lengthy technical comments regarding our first Hamming lecture for anyone interested. Also some schedule changes, thus this message is posted to both mbone & rem-conf lists. Sorry for duplicates. One long-term change to schedule: the friday sessions will be one hour later than originally scheduled (1510-1600 Pacific). Changes for next week's IETF conflicts appear at the end. Several people have asked about receiving the textbook. Unfortunately we cannot provide it since a publisher is working on publishing it. We will save names of those interested and will eventually repost to rem-conf when order information becomes available. Stephen Casner writes: > I watched the lecture today and have some feedback for you. The > packet loss rate was 8-10% according to the vat statistics panel. > Subjectively, I think I got most of what was said since we experienced > MBone listeners can interpolate from context, but there were a few key > words lost. Overall, it was worthwhile. Thank you for taking the time to let us know. Losses in Europe were higher, 15-20%. That is much more severe. > Since you had the audio set for no silence suppression, the > transmission continued after microphone was turned off and the video > was stopped. I was running the vat strip chart on the missing > packets, and it appeared that the loss rate dropped significantly when > the video was stopped. I was going to report this simple fact to you, > but then I was out of my office for a moment and when I returned, I > saw there was a period of higher loss again just before you shut down > the audio transmission. Did you turn the video back on for a period > or was there some other traffic? (I would not have seen the video if > that is what happened because I had already quit that nv.) We did turn on the camera briefly to put the school seal on as the parting image. Good lesson learned on no silence suppression. > I captured the stats window with xwd so you can see it, and I left it > in the file ftp://ftp.isi.edu/mbone/hamming.xwd for you to pick up. > Please let me know when you have it so I may delete it. Notice that > the leftmost inch or so of the graph has a low loss rate, then there > is an inch and a half of higher loss before the signal stops. Got it thanks. Mike McCann was seeing about 5% loss across campus, it appears we added one tunnel too many. We will look at fixing that first. During multicasts we monitor vat entries and e-mail for feedback. > My recommendation is that you might try lowering the video bandwidth > to 64 to see if that makes a difference. As a control, you may want > to start with 128 to see if the loss is similar to what I saw today, > and then reduce to see if the quality improves. Of course, lowering > the data rate will make the frame rate lower. OK we will certainly have to do that sooner or later. Hopefully later but sooner if necessary. We are watching for real-time feedback. We are considering whether we might do archival recordings at 256 Kbps and/or encoding with vic. I must say you can watch the 128 Kbps nv stream for a while and think "that's not so bad," but then you look at the video monitor and full motion is MUCH more engaging. This sounds obvious perhaps, but is a reminder against complacency based on recent achievements. We definitely are not where we need to be, yet. > >From your message: > > Our default bandwidth plan is 128 Kbps, to be reduced prior to obvious > > conflict or real-time reports of significant difficulty. > > If you mean 128K video, then audio+video is about 200K. > > > We plan to use lecture mode. > > Lecture mode affects only reception, not transmission. Perhaps you > meant no-silence-suppression mode. You are correct on both counts. We shifted to no-silence-suppress early on at Mike McCann's suggestion and belatedly recommend lecture mode for listeners. > Regarding the choreography of schedules for next week: Since there > will be two channels from IETF and one from Infocom going > simultaneously, it would really be best to avoid adding yours to the > load while the others are active. Since you are videotaping these > sessions, and since you say that live interaction with the speaker > will only include people in the room, would you agree to time-shift > the lectures to fit within the IETF dinner break periods on Tuesday > and Thursday? (Friday is open.) > > Tuesday PDT > --------------------------------------------------------------- > IETF 0600-0830 1000-1200 1230-1430 > Infocom 0530-0700 0730-0900 1030-1200 1230-1400 > UIUC 1930-2130 > NPS 1500-1600 > > Thursday PDT > --------------------------------------------------------------- > IETF 0600-0830 1000-1200 1230-1530 > Infocom 0530-0700 0730-0900 1030-1200 1230-1400 > NPS 1600-1700 > > Thanks. > -- Steve > ------- Yes we will. During the lecture proper we will multicast on the NPS backbone only. Viewing the digitized image helps the camera operator avoid excessive zooming. Thanks for looking up all of the schedule information and thanks again for all of your helpful comments. Next session coming up Thursday 1210 Pacific. all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv.html From list-mgr@ISI.EDU Thu Apr 2 04:27:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 30 Mar 1995 06:28:55 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 30 Mar 1995 06:27:36 -0800 Received: from null.math.lsa.umich.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 30 Mar 1995 06:27:35 -0800 Received: from hotbox.math.lsa.umich.edu (hotbox.math.lsa.umich.edu [141.211.60.51]) by null.math.lsa.umich.edu with SMTP id JAA29217 (8.6.11/IDA-1.6 for ); Thu, 30 Mar 1995 09:27:34 -0500 Message-Id: <199503301427.JAA29217@null.math.lsa.umich.edu> X-Authentication-Warning: null.math.lsa.umich.edu: Host hotbox.math.lsa.umich.edu didn't use HELO protocol To: mbone Subject: Multicast for 4.1.4 Date: Thu, 30 Mar 1995 09:27:34 -0500 From: Bill Niester Hello. Does anyone know if the multicast patches for SunOS 4.1.3_U1B will work for SunOS 4.1.4? If not, are there patches available for 4.1.4? Thanks Bill ==================================================================== Bill Niester Email: niester@umich.edu The University of Michigan Phone: (313) 763-1182 Mathematics Department Pager: (313) 210-0167 Systems Manager Address: Rm 425 West Engineering Ann Arbor, MI 48109 =================================================================== From list-mgr@ISI.EDU Thu Apr 2 03:46:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 30 Mar 1995 11:47:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 30 Mar 1995 11:46:29 -0800 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 30 Mar 1995 11:46:27 -0800 Posted-Date: Thu 30 Mar 95 11:46:19 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 30 Mar 95 11:46:20 PST Date: Thu 30 Mar 95 11:46:19 PST From: Stephen Casner Subject: Re: Multicast for 4.1.4 To: niester@math.lsa.umich.edu, MBONE Message-Id: <796592779.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199503301427.JAA29217@null.math.lsa.umich.edu> Mail-System-Version: > Does anyone know if the multicast patches for SunOS 4.1.3_U1B > will work for SunOS 4.1.4? This has been reported to work. Just make a symlink sys.sunos414 -> sys.sunos413_U1 -- Steve ------- From list-mgr@ISI.EDU Thu Apr 2 15:17:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 30 Mar 1995 23:18:00 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 30 Mar 1995 23:17:39 -0800 Received: from medoc.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 30 Mar 1995 23:17:38 -0800 Received: from medoc.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by medoc.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id XAA08743; Thu, 30 Mar 1995 23:17:24 -0800 From: Eric Paulos Message-Id: <199503310717.XAA08743@medoc.CS.Berkeley.EDU> To: Axel Belinfante Cc: Multicast Backbone , kroeze@cs.utwente.nl Subject: Re: FAQ: audio on SS5, solaris 2.4 audio patches? In-Reply-To: Your message of "Fri, 24 Mar 1995 13:54:09 +0100." <9503241254.AA13219@utis179.cs.utwente.nl> Date: Thu, 30 Mar 1995 23:17:22 -0800 Since the audio question came up for the Sparc5, I thought that I should address some of the problems that I had in getting the audio working on the HP machines here at Berkeley. The HP 712's and 715's run a Aserver to handle the audio (usually located in /usr/audio/bin/Aserver). You should make sure that two copies are running: % ps -aef | grep Aserver root 8303 1 0 19:30:41 ? 0:00 /usr/audio/bin/Aserver -f paulos 8730 1126 2 23:10:41 ttyp4 0:00 grep Aserver root 8304 8303 0 19:30:41 ? 0:00 /usr/audio/bin/Aserver -f Next, as root, you should make the audio devices by executing the script: /usr/audio/bin/make_audio_dev This makes appropriate audio devices for the speakers, internal, and external jacks, etc. I've installed mrouted-kernels on several of the HP machines here and performed the above operation to activate the audio without any problems. ------------------------------------------------------------------------- Eric Paulos Robotics Laboratory paulos@robotics.eecs.berkeley.edu University of California, Berkeley URL: http://robotics.eecs.berkeley.edu/~paulos/ From list-mgr@ISI.EDU Fri Apr 3 11:41:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 01:46:30 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 01:44:28 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 01:44:26 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 31 Mar 1995 01:44:19 -0800 Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 31 Mar 1995 10:42:07 +0100 To: Bill Fenner Cc: mbone, S.Bhatti@cs.ucl.ac.uk, A.Sasse@cs.ucl.ac.uk Subject: mrouted and ISDN Date: Fri, 31 Mar 95 10:41:43 +0100 Message-Id: <1269.796642903@cs.ucl.ac.uk> From: Jon Crowcroft we have a requirement for mbone access over basic rate ISDN [ISDN is far and away the most cost effective intermittent medium bandwidth conenctivity in europe] there are two scenarios 1. Sun or PC (Winsock stack machine of some kind with multicast) at 'home' or school site, calls up an Internet Provider point of presence (POP) where there is either a sun running mrouted, or a cisco running PIM/DVMRP or a non mcast router at the POP with an an mbone capable one just past it So there are three sub cases of the latter i) the ISDN at the POP comes into a bridge, and the sun/cisco have a lan interface or point-to-point line iside the POP to the bridge school Pop PC -------isdn---------MRouter -> Internet ii) the sun or cisco inside the POP interfaces direct onto the ISDN school Pop PC -------isdn---------Bridge ... MRouter -> Internet iii) school Pop PC -------isdn---------Router ... MRouter -> Internet what i'm asking is a) can a PC or unix stack do host IP multicast over ISDN? (should be simple, since the host simply runs the IGMP and IP multciast packets are sent over the interface to a 'multicast link address' which just resolves to the otehr end of a PPP link...but do people implement this on winsock/packet drivers, and does it work on unixes, and if not, what needs fixing to make it?) b) Do mrouted, and do cisco cope with interfaces that are ISDN (same question really as a), but now for router end....) c) can we make it so the router (POP) end doesn't try and initiate any calls (make sure that the school host leaves any groups and closes dow n the line, and that the Pop end says, ok there;s no members on this "network" so doesn't try to deliver any mcast packets ,and thus doesn't try to open an isdn call..)? 2. Sun or PC at school/home is a router with a LAN interface inside the school, and an ISDN line to the POP again there are 3 sub cases..... however, in this case. we have a couple more questions, one easy, the other nasty d) Does anyone do co-resident mrouted+host s/w for PCs (the sun case is easy, but we aren't gonna buy suns for all our 20,000 schools:-) and if so, does it "do the right thing" for ISDN interfaces? e) how would DVMRP (or MOSPF or PIM) cope with intermittent connectivity? - remembering that initially, this is a stub network case, we might be able to use ISDN call shutdown to cause some sort of "proxy prune" message from the upstream router maybe....also, maybe we could look at using some of the ideas from rfc 1582 ("Extensions to RIP to Support Demand Circuits") for DVMRP.... just a few thoughts for you'all while you wing your way to IETF... jon From list-mgr@ISI.EDU Fri Apr 3 00:34:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 08:35:47 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 08:35:24 -0800 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 08:35:23 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id IAA21454; Fri, 31 Mar 1995 08:34:49 -0800 Date: Fri, 31 Mar 1995 08:34:49 -0800 From: Dino Farinacci Message-Id: <199503311634.IAA21454@stilton.cisco.com> To: J.Crowcroft@cs.ucl.ac.uk Cc: fenner@parc.xerox.com, mbone, S.Bhatti@cs.ucl.ac.uk, A.Sasse@cs.ucl.ac.uk In-Reply-To: Jon Crowcroft's message of Fri, 31 Mar 95 10:41:43 +0100 <1269.796642903@cs.ucl.ac.uk> Subject: mrouted and ISDN >> b) Do mrouted, and do cisco cope with interfaces that are ISDN (same >> question really as a), but now for router end....) Some engineers at cisco are running PIM over ISDN to their homes. We use sparse-mode on those links for the obvious reasons. Dino From list-mgr@ISI.EDU Fri Apr 3 20:29:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 08:32:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 08:31:40 -0800 Received: from arco.na.cnr.it by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 08:30:07 -0800 Received: from cps.na.cnr.it ([140.164.14.3]) by arco.na.cnr.it (5.65c+/1.34) id AA15071; Fri, 31 Mar 1995 18:29:28 -0400 Received: from maiori.na.cnr.it by cps.na.cnr.it (4.1/SMI-4.1) id AA01749; Fri, 31 Mar 95 18:29:44 +0200 Date: Fri, 31 Mar 95 18:29:44 +0200 From: canonico@cps.na.cnr.it (Roberto Canonico) Message-Id: <9503311629.AA01749@cps.na.cnr.it> To: mbone Subject: Info request about ST2 and RSVP Hello everybody! I am interested in real-time protocols for my thesis work. I am looking for up-to-date informations about the current status of the implementation of: - the Experimental Internet Stream Protocol, Version 2 (ST-II), described by Claudio Topolcic in RFC-1190; - the New ReSerVation Protocol (RSVP). If possible, I would like to run some experiments with these protocols on the University of Naples' testbed. Please, let me know who I should contact to get some informations. I'd be grateful if anybody would help me. Thank you in advance Roberto Canonico email: canonico@cps.na.cnr.it Universita` degli Studi di Napoli "Federico II" - Italy P.S.: Does anybody know a mailing list more specifically concerned with real-time protocols? From list-mgr@ISI.EDU Fri Apr 3 03:28:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 11:28:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 11:28:31 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 11:28:30 -0800 Received: by rx7.ee.lbl.gov (8.6.11/1.43r) id LAA00792; Fri, 31 Mar 1995 11:28:20 -0800 Message-Id: <199503311928.LAA00792@rx7.ee.lbl.gov> To: Jon Crowcroft Cc: Bill Fenner , mbone, S.Bhatti@cs.ucl.ac.uk, A.Sasse@cs.ucl.ac.uk Subject: Re: mrouted and ISDN In-Reply-To: Your message of Fri, 31 Mar 95 10:41:43 N. Date: Fri, 31 Mar 95 11:28:18 PST From: Van Jacobson Jon, Part of our DOE research program for this year is to add whatever's necessary to the conferencing architecture to transparently support the mbone suite over isdn links (which means I was able to justify a home isdn link for everyone in my research group :). There are really two problems that have to be addressed: multicast routing & dynamic bandwidth allocation over the link. The second issue is crucial for isdn links since most sessions run at or above the link bandwidth and you want to allow multiple sessions (or multiple media from one session) to be multiplexed over the link in a way that matches human communication requirements (e.g., the audio session you're currently listening to should have priority over video & other audio sessions). To deal with the dynamic bandwith allocation issues, and issues with intermittent connectivity and braindead PCs & Macs, we're initially punting on using multicast over the link & following a different approach. The model is that the end's of the link are assymmetric with an mbone "proxy" at the Internet end & a client of that proxy at the home/school end. The client presents an sd-like interface to the user but requests to "open" a session result in a request to the proxy to subscribe to the session & forward packets to/from it on a dynamically allocated (unicast) UDP ports. The proxy runs CBQ over the ISDN link and has at least 6 statically configured classes: primary audio, primary video, secondary audio, secondary video, background & blackhole (these are in priority order). The client sends messages to the proxy to say which ports (and optionally source addresses) are to be associated with which class. Since we want the system to be transparent to users (i.e., the fact that you're at the far end of a skinny link should be nearly invisible), the client automatically learns which local session is the "primary" one by listening on the media access bus (one of the two local multicast "busses" that vat/vic/wb/etc. use) to find out which session currently has the audio hardware. Whenever the audio is assigned to a new session, the proxy is told to associate that session's audio packets with the "primary audio" class; if that session has video, the video packets are associated with the "primary video" class; and all other sessions are put in either secondary audio or video. The client also listens on the "conference bus" of active sessions & tells the proxy to blackhole traffic from any source that has been locally "muted" (i.e., this is the equivalent of the multicast source pruning that hasn't been implemented yet). Thus the client is basically translating natural, application level user actions into the appropriate link level bandwidth allocation policy & the user doesn't have to be aware that this is happening (or manually control the machinery to make it happen). To deal with intermittent connectivity, the CBQ top level class (the physical link) says it has bandwidth only if the link is up. The various session classes have to borrow against the top level to send anything so with the default "discard" overlimit action, random background traffic won't bring the link up. There is also a new "dial" overlimit action that can be used to bring up the link based on traffic arriving in some class. E.g., you could make the overlimit action on the primary audio be "dial" so audio data from the Internet in that session would bring up the link but the id msg control traffic & other audio & video data wouldn't. (The policy for taking down the link is left to the client & is probably based on an inactivity timer on data traffic from the primary session and/or whether there is a primary session.) I've glossed over most of the details but that may give you the flavor. We're not very far along (we've been waiting forever for some Voyager's from Sun for the home machines) but I suspect you already have done most of the pieces needed to put this together. E.g., use a variant of Mark's sdr for the client, use Ian's CBQ on a x86 box running solaris-2 to get the bandwidth-managed isdn gateway at both ends (using PC hardware is cheap and cost effective but using Microsoft software is not; so putting a PC at the schools makes sense but thinking you have to run dos or windows on it seems dumb to me). If you're interested and/or confused maybe we could have a vat chat next week & talk about this. Cheers. - Van From list-mgr@ISI.EDU Fri Apr 3 09:44:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 11:44:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 11:44:04 -0800 Received: from davinci.gmu.edu ([199.26.254.51]) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 11:43:55 -0800 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id OAA04874; Fri, 31 Mar 1995 14:44:57 -0500 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199503311944.OAA04874@davinci.gmu.edu> Subject: Reserved ip address and ports To: mbone Date: Fri, 31 Mar 1995 14:44:57 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1117 Hello, Every week, and in the future perhaps more, we have a session that we transmit over the mbone and record onto the hard drive. We also are going to be transmitting it over cuseeme at the same time as another way for students to gain acces to the session. Every time we set up a session we have to go in and manually enter the ip address, ports and conf-id to the recording software and also to the cuseeme's reflect.conf file. It would be a hugh help if we could reserve one of these ip address and a couple ports so that these files do not have to be edited continously. Is there a way to do this, or is there a way to add buttons onto sd that when checked will call up the recording/reflector programs and give them the specific ip,ports,etc.? Is there also a way of virtualizing ports so that the recording software and broadcasting software can run off the same machine? (Or the reflector software also)? Michael -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Fri Apr 3 23:46:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 11:51:00 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 11:50:42 -0800 Received: from faui45.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 11:50:22 -0800 Received: from faui40.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA19057 (5.65c-6/7.3w-FAU); Fri, 31 Mar 1995 21:46:18 +0200 Received: from delos (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with SMTP id VAA02961 (8.6.10/7.4a-FAU);; Fri, 31 Mar 1995 21:46:06 +0200 From: Toerless Eckert Message-Id: <199503311946.VAA02961@faui40.informatik.uni-erlangen.de> Subject: Re: mrouted and ISDN To: dino@cisco.com (Dino Farinacci) Date: Fri, 31 Mar 1995 21:46:04 +0200 (MET DST) Cc: J.Crowcroft@cs.ucl.ac.uk, fenner@parc.xerox.com, mbone, S.Bhatti@cs.ucl.ac.uk, A.Sasse@cs.ucl.ac.uk In-Reply-To: <199503311634.IAA21454@stilton.cisco.com> from "Dino Farinacci" at Mar 31, 95 08:34:49 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > >> b) Do mrouted, and do cisco cope with interfaces that are ISDN (same > >> question really as a), but now for router end....) > > Some engineers at cisco are running PIM over ISDN to their homes. We > use sparse-mode on those links for the obvious reasons. Ever tried this with a Sun at the remote end ? Looks to me as if the sun doesn't send the igmp packets on the ppp interfaces... Toerless From list-mgr@ISI.EDU Fri Apr 3 04:51:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 12:52:16 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 12:51:58 -0800 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 31 Mar 1995 12:51:57 -0800 Posted-Date: Fri 31 Mar 95 12:51:48 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 31 Mar 95 12:51:49 PST Date: Fri 31 Mar 95 12:51:48 PST From: Stephen Casner Subject: Please (re-)install mrouted 3.4! To: MBONE Message-Id: <796683108.0.CASNER@XFR.ISI.EDU> Mail-System-Version: A couple of days ago, Bill Fenner and I discovered that a bug had crept into the mrouted 3.4 at the last minute before it was released on March 14. That 3.4 release did fix a bug that would cause mrouted 3.3 to crash, but it introduced this new bug that prevents multicast traceroute requests from working. This is unfortunate since support of multicast traceroute was one of the reasons for making the interim 3.4 release. Fortunately, this new bug is very simple to fix, and the tar files have been updated on the two repositories: ftp://ftp.parc.xerox.com/pub/net-research/mrouted-3.4.tar.gz (updated as of Tuesday Mar 28 23:30 PST) ftp://ftp.udel.edu/pub/mbone/mrouted-3.4.tar.gz (updated as of Wednesday Mar 29 09:57 EST) If you fetched the mrouted 3.4 release before it was updated, please fetch it and install it again. Or, you can apply the patch below. Those of you who had fetched the release from PARC already received an individual note based on the FTP logs. This version is still numbered 3.4 because we didn't want to use up another number, and we figured all the good people who had promptly picked up 3.4 would be responsive again, thus wiping out the broken one! Watch this space later tonight or tomorrow for a release announcement about the multicast traceroute tool "mtrace" (a significantly enhanced version derived from Ajit Thyagarajan's prototype). I was going to combine this message with that announcement, but since I haven't finished the little-endian porting yet, I didn't want to hold up this notice. Since an mtrace request will fail if there is any mrouted 3.4 along the path that has not been corrected, please update yours. Anyone running mrouted 3.3 should also update to mrouted 3.4 to avoid the bug in the 3.3 traceroute code which causes mrouted to crash if there is no route for the source being traced (typically this will only occur if a request is specifically directed to that mrouted as the last hop, as will be explained further in the mtrace release announcement). -- Steve *** prune.c.orig Fri Mar 31 11:31:31 1995 --- prune.c Tue Mar 28 15:29:14 1995 *************** *** 1393,1399 **** } else send_igmp(src, dst, ! IGMP_MTRACE_RESP, no, group, datalen + RLEN); return; } --- 1393,1399 ---- } else send_igmp(src, dst, ! IGMP_MTRACE, no, group, datalen + RLEN); return; } ------- From list-mgr@ISI.EDU Sat Apr 1 12:45:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 02:47:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 02:47:12 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 02:47:11 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Sat, 1 Apr 1995 02:47:09 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 1 Apr 1995 11:46:51 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: mbenson@davinci.gmu.edu (Michael Benson) Cc: mbone Subject: Re: Reserved ip address and ports In-Reply-To: Your message of "Fri, 31 Mar 95 14:44:57 CDT." <199503311944.OAA04874@davinci.gmu.edu> Date: Sat, 01 Apr 95 11:45:08 +0100 Message-Id: <12232.796733108@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >Every week, and in the future perhaps more, we have a session that we >transmit over the mbone and record onto the hard drive. We also are going >to be transmitting it over cuseeme at the same time as another way for >students to gain acces to the session. > > >Every time we set up a session we have to go in and manually enter the >ip address, ports and conf-id to the recording software and also to the >cuseeme's reflect.conf file. > >It would be a hugh help if we could reserve one of these ip address and a >couple ports so that these files do not have to be edited continously. > >Is there a way to do this, or is there a way to add buttons onto sd that >when checked will call up the recording/reflector programs and give them >the specific ip,ports,etc.? Of the the requirements for the Session Description Protocol (sd protocol) v2 that we're discussing in the MMUSIC WG of the IETF is for sessions that are "intermittently active". Yours sounds like just such a requirement. I have written a next generation sd (called sdr) which will let you start up recording tools directly. I haven't officially released it yet because I want it to implement SDPv2 properly, and we're still discussing that. Hopefully I will release it in a month or so. Mark From list-mgr@ISI.EDU Fri Mar 28 17:57:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 05:53:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 05:53:05 -0800 Received: from mailrelay.pixi.com (sirius.pixi.com) by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 05:53:04 -0800 Received: from pali.pixi.com by mailrelay.pixi.com (8.6.10/SMI-4.1) id DAA20776; Sat, 1 Apr 1995 03:57:52 -1000 Date: Sat, 1 Apr 1995 03:57:52 -1000 From: tony@pixi.com (Antonio Querubin Jr.) Message-Id: <199504011357.DAA20776@mailrelay.pixi.com> To: mbone Subject: Looking for the nearest tunnel How does one go about looking for the nearest point to set up an mrouted tunnel? I want to connect 140.174.243.106 to the mbone and have a temporary tunnel running now. I'd like to point mrouted to a closer tunnel. From list-mgr@ISI.EDU Sat Apr 1 18:10:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 08:11:18 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 08:11:04 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 08:11:02 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Sat, 1 Apr 1995 08:11:00 -0800 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 1 Apr 1995 17:10:25 +0100 To: Toerless Eckert Cc: dino@cisco.com (Dino Farinacci), J.Crowcroft@cs.ucl.ac.uk, fenner@parc.xerox.com, mbone, S.Bhatti@cs.ucl.ac.uk, A.Sasse@cs.ucl.ac.uk Subject: Re: mrouted and ISDN In-Reply-To: Your message of "Fri, 31 Mar 95 21:46:04 +0100." <199503311946.VAA02961@faui40.informatik.uni-erlangen.de> Date: Sat, 01 Apr 95 17:10:22 +0100 Message-Id: <7393.796752622@cs.ucl.ac.uk> From: Jon Crowcroft >> Some engineers at cisco are running PIM over ISDN to their homes. We >> use sparse-mode on those links for the obvious reasons. dino: i hope you do smart dynamic channel allocation (see van's message) - we cannot afford to leave our calls open (from either end) when there is no user traffic (even if there are members, or routers at each end) >Ever tried this with a Sun at the remote end ? >Looks to me as if the sun doesn't send the igmp packets on the >ppp interfaces... Toerless: the bug is that the PPP/ISDN driver doesn't support the ifconfig/ioctl to say Map IP mcast destinations to link level multicast addrs, even though the task is a NUL one - easy to fix (in fact, one of our folks just adb's the kernel and patches the driver if flags to say its ok...) (there may be other problems:-) jon From list-mgr@ISI.EDU Sat Apr 1 18:16:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 08:18:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 08:17:54 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 08:17:53 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Sat, 1 Apr 1995 08:17:41 -0800 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 1 Apr 1995 17:16:49 +0100 To: Van Jacobson Cc: Bill Fenner , mbone, S.Bhatti@cs.ucl.ac.uk, A.Sasse@cs.ucl.ac.uk Subject: Re: mrouted and ISDN In-Reply-To: Your message of "Fri, 31 Mar 95 11:28:18 PST." <199503311928.LAA00792@rx7.ee.lbl.gov> Date: Sat, 01 Apr 95 17:16:47 +0100 Message-Id: <7422.796753007@cs.ucl.ac.uk> From: Jon Crowcroft Van, thanks for the detaile, insightful response (as usual!) on the two problems on multicast routes and channel allocation i'm assuming in our schol case at first that 1/ we have a stub only, so we can do some very simple hack to the route advertising 2/ we have 1 basic rate channel only, so again some fairly simple hack ought to suffice as you say, some notion of proxy could help we don't really have the budget to field any unix boxes, and i believe that the routers involved may be PCs also acting as novell nightmare servers as well in some case, so it isn't an option to run linux or *bsd, yet... anyhow, we'll look at the adventurous option you propose too (if only to flex the cbq code again!)' meanwhile, for a reference on ISDN channel allocation algorithms for lan connect can i refer peopel to the book below cheers jon "ISDN and Its Application to LAN Interconnection" by Dervis Z Deniz, 254 pages. published by McGraw Hill, 1994, ISBN 0 07 707883-7 From list-mgr@ISI.EDU Sat Apr 1 20:47:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 08:51:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 08:50:20 -0800 Received: from faui45.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 08:50:09 -0800 Received: from faui40.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA05152 (5.65c-6/7.3w-FAU); Sat, 1 Apr 1995 18:47:36 +0200 Received: from delos (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with SMTP id SAA06963 (8.6.10/7.4a-FAU);; Sat, 1 Apr 1995 18:47:23 +0200 From: Toerless Eckert Message-Id: <199504011647.SAA06963@faui40.informatik.uni-erlangen.de> Subject: Re: mrouted and ISDN To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Sat, 1 Apr 1995 18:47:18 +0200 (MET DST) Cc: Toerless.Eckert@Informatik.Uni-Erlangen.de, dino@cisco.com, J.Crowcroft@cs.ucl.ac.uk, fenner@parc.xerox.com, mbone, S.Bhatti@cs.ucl.ac.uk, A.Sasse@cs.ucl.ac.uk In-Reply-To: <7393.796752622@cs.ucl.ac.uk> from "Jon Crowcroft" at Apr 1, 95 05:10:22 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Toerless: > > the bug is that the PPP/ISDN driver doesn't support the ifconfig/ioctl > to say Map IP mcast destinations to link level multicast addrs, even > though the task is a NUL one - easy to fix (in fact, one of our folks > just adb's the kernel and patches the driver if flags to say its > ok...) Hmm, just forgot it in the previous mail: Fixing that bug would probably be easyer in source. I guess the interfaces in question are the "ipd" and "ipdptp" interfaces, which are contained in 2.4. Only problem ist that the implementations from 2.4 don't work with isdn 1.0.1, so i wonder what they've managed to break there... Toerless From list-mgr@ISI.EDU Sat Apr 1 06:24:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 10:24:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 10:24:39 -0800 Received: from everest.cclabs.missouri.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 10:24:38 -0800 Received: from realtime.cc.missouri.edu (realtime.cc.missouri.edu [128.206.212.69]) by everest.cclabs.missouri.edu (8.6.11/8.6.6-Arete-2) with SMTP id MAA00671; Sat, 1 Apr 1995 12:24:34 -0600 Date: Sat, 1 Apr 1995 12:24:34 -0600 (CST) From: "Paul 'Shag' Walmsley" X-Sender: ccshag@realtime.cc.missouri.edu To: "Antonio Querubin Jr." Cc: mbone Subject: Re: Looking for the nearest tunnel In-Reply-To: <199504011357.DAA20776@mailrelay.pixi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 1 Apr 1995, Antonio Querubin Jr. wrote: > How does one go about looking for the nearest point to set up an mrouted tunnel? > I want to connect 140.174.243.106 to the mbone and have a temporary tunnel > running now. I'd like to point mrouted to a closer tunnel. Probably the best place to look is first on any nets that may be connected between you and your service provider, then at your service provider. From a traceroute to your site, looks like the best places to ask at would be tlg.net, perhaps rg.net, and if all else fails, Sprintlink (via their mbone-admin@sprint.net address). - Paul "Shag" Walmsley "Praise and blame alike mean nothing." -- Virginia Woolf ------------------------------------------------------------------------ traceroute to 140.174.243.106 (140.174.243.106), 30 hops max, 40 byte packets 1 128.206.212.254 (128.206.212.254) 5 ms (ttl=30!) 2 ms (ttl=30!) 2 ms (ttl=30!) 2 j2.bb.missouri.edu (128.206.200.254) 6 ms (ttl=29!) 5 ms (ttl=29!) 4 ms (ttl=29!) 3 t1.bb.missouri.edu (128.206.2.248) 9 ms (ttl=28!) 6 ms (ttl=28!) 6 ms (ttl=28!) 4 Columbia-0.MO.MORE.Net (150.199.1.5) 41 ms 100 ms 30 ms 5 sl-fw-1-S11-T1.sprintlink.net (144.228.8.1) 29 ms 28 ms 39 ms 6 sl-fw-6-F0/0.sprintlink.net (144.228.30.6) 25 ms 35 ms 26 ms 7 sl-ana-1-H2/0-T3.sprintlink.net (144.228.10.30) 49 ms 55 ms 47 ms 8 sl-ana-2-F0/0.sprintlink.net (144.228.70.2) 82 ms 48 ms 48 ms 9 sl-stk-6-H2/0-T3.sprintlink.net (144.228.10.25) 60 ms 58 ms 57 ms 10 sl-stk-2-F0.sprintlink.net (144.228.40.2) 61 ms 58 ms 67 ms 11 sl-rgnet-1-S1-T1.sprintlink.net (144.228.42.22) 70 ms 66 ms 78 ms 12 gw9-sf1.tlg.net (140.174.153.11) 67 ms 65 ms 62 ms 13 goldengate.pixi.com (140.174.243.1) 125 ms 127 ms 121 ms 14 pali.pixi.com (140.174.243.106) 123 ms 215 ms 119 ms From list-mgr@ISI.EDU Sat Apr 1 10:09:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 18:10:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 18:10:10 -0800 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 18:10:09 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id SAA04870; Sat, 1 Apr 1995 18:09:52 -0800 Date: Sat, 1 Apr 1995 18:09:52 -0800 From: Dino Farinacci Message-Id: <199504020209.SAA04870@stilton.cisco.com> To: Toerless.Eckert@Informatik.Uni-Erlangen.de Cc: J.Crowcroft@cs.ucl.ac.uk, fenner@parc.xerox.com, mbone, S.Bhatti@cs.ucl.ac.uk, A.Sasse@cs.ucl.ac.uk In-Reply-To: Toerless Eckert's message of Fri, 31 Mar 1995 21:46:04 +0200 (MET DST) <199503311946.VAA02961@faui40.informatik.uni-erlangen.de> Subject: mrouted and ISDN >> Ever tried this with a Sun at the remote end ? >> Looks to me as if the sun doesn't send the igmp packets on the >> ppp interfaces... Nope. Only cisco-to-cisco. Dino From list-mgr@ISI.EDU Sat Apr 1 14:00:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 22:01:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 22:00:47 -0800 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 1 Apr 1995 22:00:46 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id WAA05799; Sat, 1 Apr 1995 22:00:35 -0800 Date: Sat, 1 Apr 1995 22:00:35 -0800 From: Dino Farinacci Message-Id: <199504020600.WAA05799@stilton.cisco.com> To: J.Crowcroft@cs.ucl.ac.uk Cc: Toerless.Eckert@Informatik.Uni-Erlangen.de, J.Crowcroft@cs.ucl.ac.uk, fenner@parc.xerox.com, mbone, S.Bhatti@cs.ucl.ac.uk, A.Sasse@cs.ucl.ac.uk In-Reply-To: Jon Crowcroft's message of Sat, 01 Apr 95 17:10:22 +0100 <7393.796752622@cs.ucl.ac.uk> Subject: mrouted and ISDN >> dino: >> i hope you do smart dynamic channel allocation (see van's message) - >> we cannot afford to leave our calls open (from either end) when there >> is no user traffic (even if there are members, or routers at each end) Yes, using dial-backup, you can allocate and inactivity time-out extra B-channels. Currently, PIM sends periodic joins when you join groups and keeps the link up, but we have plans to improve this. Dino From list-mgr@ISI.EDU Mon Apr 3 18:41:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 07:42:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 07:41:54 -0700 Received: from dxmint.cern.ch by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 07:41:47 -0700 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14044; Mon, 3 Apr 1995 16:41:44 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA21966; Mon, 3 Apr 1995 16:41:42 +0200 Message-Id: <9504031441.AA21966@dxcoms.cern.ch> Subject: H261 with VIC and/or IVS To: mbone Date: Mon, 3 Apr 1995 16:41:41 +0200 (MET DST) From: "Philippe Galvez - CERN/CN/CS" X-Face: #ROKyLG]e>),=jJnrU-jw[E]/4C~VPQfd$I,^S#cz%veC!}`#L;P1cU*]@(!`>E4r^5uxXr ;0EiT;~x%bhpnGyYt6.|(xsB%o)QrTuC>EtAQlEr5j;_xq"kO9Y7"?)6&>EboH$D7Z8OFQ4)C32qq= .uAvh(.2-8+09XI>N0&$EE;ol)0&qG/u#.R7a{\@BHp"`lx@a;iig57*1U@zDq3yh%6R`P"~*5$544 0Zi{Q;<76U7aLv{_ X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 830 Hi folks, I plan to use VIC for collaborative work between US and Europe. For this, I have two questions : Did someone planned to make VIC available for Parallax card ? If Yes, any idea when it will be in production ? Does H261 software codec used in VIC and IVS are identical ? if not, What is the difference ? Thanks very much in advance, Best Regards, -- ~`''~ (~ o) +-----------------------oOO--(_)--OOo-------------------------------------+ | Philippe Galvez Email: pgalvez@dxcoms.cern.ch | | European Laboratory for Particle Physics CERN - CN/CS/EN | | Computers and Networks division Tel: +41 22 767 89 08 | | CH-1211 Geneva 23 - Switzerland Fax: +41 22 767 71 55 | +-------------------------(_)--(_)----------------------------------------+ From list-mgr@ISI.EDU Mon Apr 3 09:22:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 10:21:49 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 10:19:25 -0700 Received: from FOGHORN.PASS.WAYNE.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 10:19:23 -0700 Received: by foghorn.pass.wayne.edu (5.x/SMI-SVR4) id AA05183; Mon, 3 Apr 1995 13:22:07 -0400 Date: Mon, 3 Apr 1995 13:22:04 -0400 (EDT) From: Dan Cwiertniewicz To: MBONE Subject: Mrouted with Solaris 2.4 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I just tried to run the latest version of mrouted and got the following message. Is this normal? # /etc/mrouted -d 2 -p debug level 2 mrouted version 3.4 installing le0 (141.217.25.22 on subnet 141.217.25) as vif #0 - rate=0 installing tunnel from 141.217.25.22 to 141.217.35.6 as vif #1 - rate=500 setsockopt DVMRP_ADD_VIF: Option not supported by protocol From list-mgr@ISI.EDU Mon Apr 3 19:39:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 10:41:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 10:40:27 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 10:39:40 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id SAA02087; Mon, 3 Apr 1995 18:39:16 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id SAA07388; Mon, 3 Apr 1995 18:39:09 +0100 Date: Mon, 3 Apr 1995 18:39:06 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Dan Cwiertniewicz Cc: MBONE Subject: Re: Mrouted with Solaris 2.4 In-Reply-To: Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 3 Apr 1995, Dan Cwiertniewicz wrote: > I just tried to run the latest version of mrouted and got the following > message. Is this normal? > > # /etc/mrouted -d 2 -p > debug level 2 > mrouted version 3.4 > installing le0 (141.217.25.22 on subnet 141.217.25) as vif #0 - rate=0 > installing tunnel from 141.217.25.22 to 141.217.35.6 as vif #1 - rate=500 > setsockopt DVMRP_ADD_VIF: Option not supported by protocol You cannot run mrouted 3.4 on Solaris 2.4. The latest revision you can run on Solaris is version 2.2. Sun are reputedly producing a version 3.x of IP multicast for Solaris but they have been saying that for a while now so I guess it is not a priority for them. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Mon Apr 3 18:41:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 07:42:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 07:41:54 -0700 Received: from dxmint.cern.ch by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 07:41:47 -0700 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14044; Mon, 3 Apr 1995 16:41:44 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA21966; Mon, 3 Apr 1995 16:41:42 +0200 Message-Id: <9504031441.AA21966@dxcoms.cern.ch> Subject: H261 with VIC and/or IVS To: mbone Date: Mon, 3 Apr 1995 16:41:41 +0200 (MET DST) From: "Philippe Galvez - CERN/CN/CS" X-Face: #ROKyLG]e>),=jJnrU-jw[E]/4C~VPQfd$I,^S#cz%veC!}`#L;P1cU*]@(!`>E4r^5uxXr ;0EiT;~x%bhpnGyYt6.|(xsB%o)QrTuC>EtAQlEr5j;_xq"kO9Y7"?)6&>EboH$D7Z8OFQ4)C32qq= .uAvh(.2-8+09XI>N0&$EE;ol)0&qG/u#.R7a{\@BHp"`lx@a;iig57*1U@zDq3yh%6R`P"~*5$544 0Zi{Q;<76U7aLv{_ X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 830 Hi folks, I plan to use VIC for collaborative work between US and Europe. For this, I have two questions : Did someone planned to make VIC available for Parallax card ? If Yes, any idea when it will be in production ? Does H261 software codec used in VIC and IVS are identical ? if not, What is the difference ? Thanks very much in advance, Best Regards, -- ~`''~ (~ o) +-----------------------oOO--(_)--OOo-------------------------------------+ | Philippe Galvez Email: pgalvez@dxcoms.cern.ch | | European Laboratory for Particle Physics CERN - CN/CS/EN | | Computers and Networks division Tel: +41 22 767 89 08 | | CH-1211 Geneva 23 - Switzerland Fax: +41 22 767 71 55 | +-------------------------(_)--(_)----------------------------------------+ From list-mgr@ISI.EDU Mon Apr 3 07:28:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 14:28:55 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 14:28:51 -0700 Received: by rx7.ee.lbl.gov (8.6.11/1.43r) id OAA04230; Mon, 3 Apr 1995 14:28:51 -0700 Message-Id: <199504032128.OAA04230@rx7.ee.lbl.gov> To: stan@glorius.cs.uiuc.edu, zchen@indy1.cs.uiuc.edu Cc: mbone-na Subject: wilkes video being sent at 240kb/s Date: Mon, 03 Apr 95 14:28:49 PDT From: Van Jacobson You are sending the video from the Wilkes talk (224.2.241.51/43651) at 200-240kb/s. The mbone is *very* busy this week and your original announcement said the video would be sent at a very low frame rate. 64-80kb/s would be an appropriate rate; 240kb/s is not. You are causing substantial loss on the ietf audiocast. Please lower your bandwidth. Thanks. - Van Jacobson From list-mgr@ISI.EDU Mon Apr 3 07:36:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 14:36:30 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 14:36:29 -0700 Received: by rx7.ee.lbl.gov (8.6.11/1.43r) id OAA04249; Mon, 3 Apr 1995 14:36:33 -0700 Message-Id: <199504032136.OAA04249@rx7.ee.lbl.gov> To: mbone-na Subject: NCSA trashing mbone, culprits unreachable by email Date: Mon, 03 Apr 95 14:36:33 PDT From: Van Jacobson The Wilkes broadcast from NSCA is sending 240kb/s of video & trashing the mbone but the mailers on the machines sending the video & sd announcements are so misconfigured that it's not possible to get through (see below). Could someone at or near NSCA ask these people to lower their bandwidth? (and maybe fix their mailer.) Thanks. - Van --------------- Subject: Returned mail: Service unavailable ----- Transcript of session follows ----- <<< HELO rx7.ee.lbl.gov <<< MAIL From: <<< RCPT To: <<< RCPT To: <<< DATA Connected to delirius.cs.uiuc.edu: >>> HELO delirius <<< 553 delirius host name configuration error 554 ... Service unavailable From list-mgr@ISI.EDU Mon Apr 3 13:06:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 14:40:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 14:39:59 -0700 Received: from Princeton.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 14:39:36 -0700 Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.116/princeton) id AA23896; Mon, 3 Apr 95 17:06:38 -0400 Received: from deepthought.Princeton.EDU by ponyexpress.princeton.edu (8.6.12/1.7/newPE) id RAA10313; Mon, 3 Apr 1995 17:06:37 -0400 Received: by deepthought.Princeton.EDU (4.1/Phoenix_Cluster_Client) id AA12744; Mon, 3 Apr 95 17:06:34 EDT Message-Id: <9504032106.AA12744@deepthought.Princeton.EDU> X-Mailer: exmh version 1.5.3 12/28/94 To: mbone Cc: tengi@Princeton.EDU Subject: problems with map-mbone-v3.4 X-Face: Bf#x_s+*GOjDqAJ)5qI'fpm&Y2OF`RgiD2w\&Qr7ly@(yzUB)zSw#@Bj)A"3sIEwTwdBY&} #v`i+!@m"7yGc;*@Gqk_LZW4l;q8jsoEKRHL'eC|($Jc wWNl X-Uri: http://www.Princeton.EDU/~tengi/ Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="boundary=_0" Date: Mon, 03 Apr 1995 17:06:33 EDT From: "Christopher J. Tengi" This is a multipart MIME message. --boundary=_0 Content-Type: text/plain; charset="us-ascii" -------- I keep getting bus errors when I run map-mbone (without any arguments). I have tracked it down to a problem of some kind in the data that accept_neighbors2 is trying to deal with. Just for grins, I added the args to a few functions in mapper.c as used by igmp.c when lint complained (a patch is at the end). I didn't expect any change in behaviour, and I didn't get any. I am running this on a SS5 - deepthought.princeton.edu - running SunOS-4.1.3_U1B, with the 3.3 multicasting code installed. The SS5 has a tunnel to another SPARC machine in JvNCnet - x-wing.jvnc.net - and another tunnel to a cisco router (attached to it's "primary", in terms of unicast routes, interface) - maingate.princeton.edu - running 10.2(4). Sometimes, as in when I can't get through x-wing, map-mbone prints what it knows about my local configuration. However, when I successfully try to get into the greater mbone, map-mbone gets a bus error. I traced ifc_node, ifc_i and ifc_n at (my) line 466 in mapper.c: 466 old_neighbors = ifc_n->neighbors; with the following results just before the bus error: at line 466 in file "mapper.c": *`mapper`accept_neighbors2`ifc_node = { addr = 3758096385 version = 522 tries = 1 u = left = 0xc060 right = 0xed98 } at line 466 in file "mapper.c": *`mapper`accept_neighbors2`ifc_i = { next = (nil) addr = 2154854401 neighbors = 0xc0b8 } at line 466 in file "mapper.c": `mapper`accept_neighbors2`ifc_n = 0xc0f0 at line 466 in file "mapper.c": *`mapper`accept_neighbors2`ifc_node = { addr = 3758096385 version = 522 tries = 1 u = left = 0xc060 right = 0xed98 } at line 466 in file "mapper.c": *`mapper`accept_neighbors2`ifc_i = { next = (nil) addr = 2154854401 neighbors = 0xc0b8 } at line 466 in file "mapper.c": *`mapper`accept_neighbors2`ifc_n = { next = 0xc140 addr = 2154854401 neighbors = (nil) } at line 466 in file "mapper.c": *`mapper`accept_neighbors2`ifc_node = { addr = 3758096385 version = 522 tries = -1 u = left = 0xc060 right = 0xed98 } at line 466 in file "mapper.c": *`mapper`accept_neighbors2`ifc_i = { next = 0xe0000004 addr = 522 neighbors = 0x1 } at line 466 in file "mapper.c": `mapper`accept_neighbors2`ifc_n = 0xc0a0 at line 466 in file "mapper.c": *`mapper`accept_neighbors2`ifc_node = { addr = 3758096385 version = 522 tries = -1 u = left = 0xc060 right = 0xed98 } at line 466 in file "mapper.c": *`mapper`accept_neighbors2`ifc_i = { next = 0xe0000004 addr = 522 neighbors = 0x1 } at line 466 in file "mapper.c": *`mapper`accept_neighbors2`ifc_n = { next = 0xc0f0 addr = 522 neighbors = (nil) } signal BUS (bus error) in accept_neighbors2 at line 468 in file "mapper.c" 468 next_nb_i = nb_i->next; (dbx) list 466 466 old_neighbors = ifc_n->neighbors; (dbx) It looks kinda strange that the addr fields of ifc_i and ifc_n both have the value for ifc_node->version just before it craps out. I tried tracing through the code, but I'm having trouble getting into the mind-set required for this programm (and probably the rest of the multicast stuff). Does anything just "jump out" to the folks who know this code? Is there anything else I can/should be looking at? Thanks, /Chris --boundary=_0 Content-Type: text/plain; charset="us-ascii" Content-Description: mapper.c.diff *** mapper.c.ORIG Tue Mar 28 18:29:13 1995 --- mapper.c Mon Apr 3 16:10:31 1995 *************** *** 185,192 **** /* * Process an incoming group membership report. */ ! void accept_group_report(src, dst, group) u_long src, dst, group; { log(LOG_INFO, 0, "ignoring IGMP group membership report from %s to %s", inet_fmt(src, s1), inet_fmt(dst, s2)); --- 185,193 ---- /* * Process an incoming group membership report. */ ! void accept_group_report(src, dst, group, r_type) u_long src, dst, group; + int r_type; { log(LOG_INFO, 0, "ignoring IGMP group membership report from %s to %s", inet_fmt(src, s1), inet_fmt(dst, s2)); *************** *** 403,410 **** } } ! void accept_neighbors2(src, dst, p, datalen) ! u_long src, dst; u_char *p; int datalen; { --- 404,411 ---- } } ! void accept_neighbors2(src, dst, p, datalen, group) ! u_long src, dst, group; u_char *p; int datalen; { --boundary=_0-- From list-mgr@ISI.EDU Mon Apr 3 13:11:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 16:12:00 -0700 Received: from sparc14.cs.uiuc.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 16:11:58 -0700 Received: by sparc14.cs.uiuc.edu id AA03671 (5.67b/IDA-1.5 for mbone-na@isi.edu); Mon, 3 Apr 1995 18:11:48 -0500 From: z-chen3@sparc14.cs.uiuc.edu Message-Id: <199504032311.AA03671@sparc14.cs.uiuc.edu> Subject: Apologies for trashing mbone To: van@rx7.ee.lbl.gov Date: Mon, 3 Apr 1995 18:11:47 -0500 (CDT) Cc: mbone-na, mdb@cisco.com, stan@delirius.cs.uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 406 I am the graduate student working with stan@glorius.cs.uiuc.edu broadcasting the Wilkes talk this afternoon. I made a mistake rasing the nv transmission rate which caused serious problems. I would like to apologize for my mistake to the whole mbone community, and to my colleague See-Mong Tan for damaging his reputation, it was really my fault. I am really sorry. Zhigang Chen(zchen@cs.uiuc.edu) From list-mgr@ISI.EDU Mon Apr 3 17:01:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 22:01:46 -0700 Received: from colmex.mx (jupiter.uc.colmex.mx) by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 3 Apr 1995 22:01:43 -0700 Received: by colmex.mx (4.1/4.7) id AA00440; Mon, 3 Apr 95 23:01:22 CST Date: Mon, 3 Apr 1995 23:01:21 -0600 (CST) From: Patrick Vielle Subject: From Mexico. To: mbone-na-request Cc: mbone-na Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I am Patrick Vielle, system and network administrator for el Colegio de Mexico A.C. in Mexico City. Since there is no Mexican list nor any contact, nor even mbone tunnel to mexico (or is there?), I would like to join the North American list. I have installed and compiled the multicast kernel for a Sparcstation 10 running SunOS 4.1.3U1B, (ipmulti3.3-sunos413x.tar.Z, mrouted-3.4.tar.gz) using mcast_install. The kernel has been succesfully compiled and linked however when I boot with the new kernel there is an assertion failure. I had previouslly installed these recommended kernel patches from SUN: 101508-08: SunOS 4.1.3_U1: sun4m kernel jumbo patch 101558-04: SunOS 4.1.3_U1: international libc jumbo patch 101784-03: SunOS 4.1.3_U1: rpc.lockd/rpc.statd jumbo patch 102177-02: SunOS 4.1.3_U1: NFS Jumbo Patch I did not install: 101587-01: SunOS 4.1.3_U1: security patch for mfree and icmp redirect Because of a mention in: "Installation notes for the multicast release 3.3 code" : "To note a couple, the "panic:mfree" fix is included in ip_icmp.o and the fix for "applications bind to same port if IP address supplied" is included in in_pcb.o." Is there anything that I could have done wrong? I would really apreciate any help, both for the multicast installation and for the tunneling which would be one of the first in Mexico. Thanks in advance. Patrick Vielle Coordinador de Redes y Telecomunicaciones. El Colegio de Mexico, A.C. From list-mgr@ISI.EDU Mon Apr 3 17:07:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 00:09:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 00:08:03 -0700 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 00:08:01 -0700 Posted-Date: Tue 4 Apr 95 00:07:52 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 4 Apr 95 00:07:53 PDT Date: Tue 4 Apr 95 00:07:52 PDT From: Stephen Casner Subject: Release of mtrace (multicast traceroute) To: MBONE Message-Id: <796982872.0.CASNER@XFR.ISI.EDU> Mail-System-Version: A beta release of the multicast traceroute tool "mtrace" is available from ftp://ftp.isi.edu/mbone/mtrace.tar.Z This file includes an mtrace.c file which should replace the one in the mrouted directory of the multicast 3.3 software release or 3.4 mrouted release. Also included is a man page and a SunOS binary. This tool has been ported to FreeBSD on a PC, so I think it works with both endians (thanks to Bill Fenner for testing this). mtrace utilizes a tracing feature implemented in multicast routers (mrouted version 3.3 and later) that is accessed via an extension to the IGMP protocol. A trace query is passed hop-by-hop along the reverse path from the receiver to the source, collecting hop addresses, packet counts, and routing error conditions along the path, and then the response is returned to the requestor. This is a significantly enhanced version derived from the prototype written by Ajit Thyagarajan. The prototype was hard to use because it required that several parameters all be supplied correctly or there would be no response. This new version makes use of multicast for trace requests and responses where appropriate and supplies defaults for other parameters so that in most cases the only required parameter is the source host name or address. Further details are given in the man page. Feedback on the output format or the behavior of the tool would be welcomed. An mrouted warning: Since it has been three weeks since the mrouted 3.4 was released, everyone running 3.3 has upgraded by now, right? That's good, because there was a bug in mrouted 3.3 that mtrace can tickle and cause mrouted to core dump. However, this is unlikely enough that I decided this mtrace release was reasonable. There are two cases: - If the mtrace request packet is explicitly directed to an mrouted 3.3 as a unicast packet (using the -g option, which isn't normally done), and if that mrouted does not have a route for the specified source, it will crash. To guard against this, the man page has a large warning. Also, if -g to a unicast address is given, mtrace tries an mrinfo query to that address to check the mrouted version number and won't send the trace request if it's 3.3. - There is a very small time window for traces that don't use -g to cause a crash. If the mrouted 3.3 times out and deletes a route from its table before the next router closer to the receiver does, and if a trace for that route comes through between those two events then the mrouted 3.3 will crash. The probability of this situation should be small. Meanwhile, everyone running 3.3 should please upgrade to 3.4 to eliminate this potential crash. Since 3.4 is just a new mrouted and no kernel change from 3.3, it should be easy to upgrade. [Note that if you are running Solaris or another OS that does not yet support 3.x multicast, you can't upgrade to mrouted 3.4 but you also don't have the danger of mrouted 3.3 crashing.] The mrouted 3.4 release is available from: ftp://ftp.parc.xerox.com/pub/net-research/mrouted-3.4.tar.gz (updated as of Tuesday Mar 28 23:30 PST) ftp://ftp.udel.edu/pub/mbone/mrouted-3.4.tar.gz (updated as of Wednesday Mar 29 09:57 EST) If you are running mrouted 3.4 already, but fetched it before the time of update shown, please fetch a new one because the original release of mrouted 3.4 on March 14 contained a new bug that was "safe" (would not cause a crash) but which prevents multicast traceroute from working. Since an mtrace request will fail if there is any mrouted 3.4 along the path that has not been corrected, please update yours. Sorry for the inconvenience. -- Steve ------- From list-mgr@ISI.EDU Tue Apr 4 18:07:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 05:08:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 05:08:03 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 05:07:51 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.11/8.6.9) id PAA10135; Tue, 4 Apr 1995 15:07:42 +0300 Date: Tue, 4 Apr 1995 15:07:42 +0300 Message-Id: <199504041207.PAA10135@silver.sms.fi> From: Petri Helenius To: mbone Subject: multicast support for HP-UX 9.05 Can anyone point me to multicast kernel for HP-UX 9.05 ? Pete From list-mgr@ISI.EDU Tue Apr 4 05:02:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 06:04:03 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 06:02:57 -0700 Received: from math.lsa.umich.edu (null.math.lsa.umich.edu) by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 06:02:56 -0700 Received: from hotbox.math.lsa.umich.edu by math.lsa.umich.edu (8.6.11/2.2) with SMTP id JAA15908; Tue, 4 Apr 1995 09:02:55 -0400 Message-Id: <199504041302.JAA15908@math.lsa.umich.edu> To: Stephen Casner Cc: MBONE Subject: Re: Release of mtrace (multicast traceroute) In-Reply-To: Your message of Tue, 04 Apr 1995 00:07:52 PDT. Date: Tue, 04 Apr 1995 09:02:55 -0400 From: Bill Niester ftp.isi.edu seems to be refusing me a connection, any reason why? ---- included session ----- bailey:niester% ftp ftp.isi.edu ftp: connect: Connection refused --------------------------- > A beta release of the multicast traceroute tool "mtrace" is available > from > ftp://ftp.isi.edu/mbone/mtrace.tar.Z Thanks, Bill ==================================================================== Bill Niester Email: niester@umich.edu The University of Michigan Phone: (313) 763-1182 Mathematics Department Pager: (313) 210-0167 Systems Manager Address: Rm 425 West Engineering Ann Arbor, MI 48109 =================================================================== From list-mgr@ISI.EDU Tue Apr 4 06:10:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 07:12:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 07:11:10 -0700 Received: from mailer.jhuapl.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 07:11:08 -0700 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA25296; Tue, 4 Apr 1995 10:11:07 -0400 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA19689; Tue, 4 Apr 1995 10:10:13 -0400 Date: Tue, 4 Apr 1995 10:10:12 -0400 (EDT) From: Jim Bogard BIX Subject: CUseeme and nv To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 337 I would like to be able to conference between nv and CUseeme clients, presumably using the CUseeme reflector. (Although I actually have no idea what's necessary.) Would someone please be kind enough to point me in the right direction? I can't seem to find anything pertinent on the subject. Thanks. Jim jimbo@aplcomm.jhuapl.edu From bmanning@ISI.EDU Tue Apr 4 00:41:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 07:41:58 -0700 Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 07:41:57 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Tue, 4 Apr 1995 07:41:29 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199504041441.AA20891@zephyr.isi.edu> Subject: Re: From Mexico. To: patvie@colmex.mx (Patrick Vielle) Date: Tue, 4 Apr 1995 07:41:29 -0700 (PDT) Cc: mbone-na-request, mbone-na In-Reply-To: from "Patrick Vielle" at Apr 3, 95 11:01:21 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 96 Check with Stan Barber (sob@ns.sesqui.net) for the current feeds already in Mexico. -- --bill From list-mgr@ISI.EDU Tue Apr 4 18:59:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 08:02:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 08:01:21 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 07:59:49 -0700 Received: from marconi.electrum.kth.se (marconi.electrum.kth.se [130.237.212.20]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id QAA16404 for ; Tue, 4 Apr 1995 16:59:20 +0200 Received: (gunnarb@localhost) by marconi.electrum.kth.se (8.6.9/8.6.9) id QAA24343; Tue, 4 Apr 1995 16:59:19 +0200 Date: Tue, 4 Apr 1995 16:59:19 +0200 Message-Id: <199504041459.QAA24343@marconi.electrum.kth.se> To: mbone Subject: Solaris 2.2 From: Gunnar Brading Reply-To: Gunnar Brading Can anyone point me to mrouted binaries and the needed patch for Solaris 2.4? Would be very grateful! -- Gunnar Brading From list-mgr@ISI.EDU Wed Apr 5 09:48:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 08:49:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 08:48:55 -0700 Received: from yuri.ipc.chiba-u.ac.jp by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 08:48:52 -0700 Received: by yuri.ipc.chiba-u.ac.jp (5.67+1.6W/2.8Wb) id AA26657; Wed, 5 Apr 95 00:48:43 JST Return-Path: Message-Id: <9504041548.AA26657@yuri.ipc.chiba-u.ac.jp> To: jimbo@aplcomm.jhuapl.edu Cc: mbone Subject: Re: CUseeme and nv In-Reply-To: Your message of "Tue, 04 Apr 1995 10:10:12 -0400." Date: Wed, 05 Apr 1995 00:48:42 +0900 From: Yozo Toda > I would like to be able to conference between nv and CUseeme clients, > presumably using the CUseeme reflector. (Although I actually have no I don't know details about this subject, either, but how about looking through CU-SeeMe WWW page? I believe you can find something valuable. http://www.jungle.com/msattler/sci-tech/comp/CU-SeeMe/ -- yozo. From list-mgr@ISI.EDU Tue Apr 4 06:44:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 13:45:02 -0700 Received: from osi-east.es.net by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 13:45:01 -0700 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <23941-0@osi-east.es.net>; Tue, 4 Apr 1995 13:44:41 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA05795; Tue, 4 Apr 95 13:44:39 PDT Date: Tue, 4 Apr 95 13:44:39 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9504042044.AA05795@viipuri.nersc.gov> To: mbone-na Subject: subscribe mbone-na ----- Begin Included Message ----- From skarupa@pharmvax1.ab.umd.edu Tue Apr 4 11:29:13 1995 Date: Tue, 4 Apr 1995 13:26:44 -0400 From: skarupa@pharmvax1.ab.umd.edu (Stephen J. Skarupa) To: rem-conf-request@es.net Subject: subscribe mbone-na X-Vms-To: SMTP%"rem-conf-request@es.net" Content-Length: 19 subscribe mbone-na ----- End Included Message ----- From list-mgr@ISI.EDU Wed Apr 5 01:04:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 14:02:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 14:00:56 -0700 Received: from owl.igd.fhg.de ([192.67.203.132]) by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 14:00:53 -0700 Received: by owl.igd.fhg.de (5.x/SMI-4.1) id AA24904; Tue, 4 Apr 1995 23:04:51 +0200 Date: Tue, 4 Apr 1995 23:04:51 +0200 From: likavec@igd.fhg.de (Jaromir Likavec) Message-Id: <9504042104.AA24904@owl.igd.fhg.de> To: mbone, rem-conf@es.net Subject: Announcement: 3rd Int. WWW Conference 11-13 April Cc: likavec@igd.fhg.de, kroemker@igd.fhg.de, kucera@igd.fhg.de, puchtler@igd.fhg.de X-Sun-Charset: US-ASCII Dear Colleagues, Live interactive audio and video will be sent around the world from the Third International World-Wide Web Conference in Darmstadt, Germany, by means of the multicasting backbone (MBONE) on 11-13 April 1995. Any individual with the appropriate Internet-connected hardware and software can participate; there will also be several pre-designated remote Conference sites, where the audio and video will be projected before a group of registered remote participants. Two parallel sessions will be multicasted simultaneously. We will be experimenting with a new multicasting Web application as well. MBONE communication is multi-way, and remote participation will be solicited during question periods. You will find complete information about this multicast and the remote conference sites on the Conference server under the URL: http://www.igd.fhg.de/www95.html Look under the topic MBONE-Multicasting. We encourage you to consider setting up a remote site at your facility, after reading the documentation about the limitations of this technology. To ease multicast-related communications between the Darmstadt Conference site and the remote sites, we have put into operation a HyperNews-based "Multicast Sessions Discussion Forum" at the URL: http://ananas.igd.fhg.de/HyperNews/get/hypernews/mbone95.html Other questions/remarks can be directed to us. We hope to see many of you participating in the meeting from afar. Regards, Jaromir Likavec (likavec@igd.fhg.de) R. P. C. Rodgers (rodgers@nlm.nih.gov) From list-mgr@ISI.EDU Tue Apr 4 19:13:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 20:13:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 20:13:35 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 4 Apr 1995 20:13:33 -0700 Received: from CAES-SUN-3.MIT.EDU by MIT.EDU with SMTP id AA21708; Tue, 4 Apr 95 23:13:25 EDT Received: by caes-sun-3.MIT.EDU (5.0/4.7) id AA22159; Tue, 4 Apr 1995 23:13:15 -0400 Message-Id: <9504050313.AA22159@caes-sun-3.MIT.EDU> To: rem-conf@es.net, mbone Cc: bailey@farnsworth.mit.edu, nomad@farnsworth.mit.edu, jimmy@MIT.EDU Subject: MBONE rebroadcast of the Internet Economic Workshop Date: Tue, 04 Apr 1995 23:13:13 EDT From: Chi-ming Lai Content-Length: 685 Greetings, There will be a rebroadcast of the Internet Economics Workshop in its entirety on April 6 & 7, 1995. The original workshop was held on March 9th and 10th. The rebroadcast will begin at 9am (Eastern Daylight Savings Time) on April 6 & 7. We will be putting in the videotapes from the workshop one-right-after-the-other. The rebroadcast will end approximately 4:30 pm on Thursday, April 6, and at 3:30 pm on Friday, April 7. Please consult the original agenda to determine the order of the tapes. (http://rpcp.mit.edu/Workshops/mbone.html) Should there be any questions or comments, please address to bailey@farnsworth.mit.edu, or jimmy@mit.edu Thanks. -Jimmy Lai From list-mgr@ISI.EDU Wed Apr 5 08:08:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 03:08:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 03:07:57 -0700 Received: from INCTURKY.AF.MIL by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 03:07:46 -0700 Received: by incturky.af.mil (5.59/25-eef) id AA22896; Wed, 5 Apr 95 13:08:03 EST Date: Wed, 5 Apr 95 13:08:03 EST From: 39lgwpw@incturky.af.mil Message-Id: <9504051808.AA22896@incturky.af.mil> To: mbone Subject: Membership [R(11)] To whom it may concern; I would like some information about the MBONE as well as how to log on as a guest to see what services are offered. Again, any information you have I would appreciate. Thank You, Robert Reno Incirlik, Turkey Internet From list-mgr@ISI.EDU Wed Apr 5 12:24:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 03:27:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 03:26:46 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 03:26:45 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 5 Apr 1995 03:26:42 -0700 Message-Id: <199504051026.AA01812@quark.isi.edu> Received: from speedy.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Apr 1995 11:25:09 +0100 To: 39lgwpw@incturky.af.mil Cc: mbone, mice-nsc-admin@cs.ucl.ac.uk Subject: Re: Membership [R(11)] In-Reply-To: Your message of "Wed, 05 Apr 95 13:08:03 EST." <9504051808.AA22896@incturky.af.mil> Date: Wed, 05 Apr 95 11:24:59 +0100 From: Roy Bennett Robert The MICE project, Multimedia Integrated Conferencing for Europe, has set up a "Network of Support Centres" throughout Europe to provide information and advice on the use of the Mbone videoconferencing tools If you have access to the World Wide Web, look at http://www.cs.ucl.ac.uk/mice/ and, within that, http://www.cs.ucl.ac.uk/mice/mice-nsc/ If you need further information, you may contact either myself or any colleagues in other centres. Best wishes Roy >To whom it may concern; > I would like some information about the MBONE as well >as how to log on as a guest to see what services are offered. >Again, any information you have I would appreciate. > Thank You, > Robert Reno > Incirlik, Turkey > Internet --------------------------------------------------------------------- Roy Bennett Email: rbennett@cs.ucl.ac.uk Project EMMA - Enhanced Multicast for Multimedia Applications MICE National Support Centre, England mice-nsc@cs.ucl.ac.uk Computer Science University College London Phone: +44 171 380 7934 Gower Street, LONDON WC1E 6BT Fax: +44 171 387 1397 --------------------------------------------------------------------- From list-mgr@ISI.EDU Wed Apr 5 12:25:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 03:26:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 03:26:27 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 03:25:43 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id LAA15933; Wed, 5 Apr 1995 11:25:24 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id LAA11192; Wed, 5 Apr 1995 11:25:19 +0100 Date: Wed, 5 Apr 1995 11:25:16 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Chi-ming Lai Cc: rem-conf@net.es, mbone, bailey@farnsworth.mit.edu, nomad@farnsworth.mit.edu, jimmy@mit.edu Subject: Re: MBONE rebroadcast of the Internet Economic Workshop In-Reply-To: <9504050313.AA22159@caes-sun-3.MIT.EDU> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 4 Apr 1995, Chi-ming Lai wrote: > There will be a rebroadcast of the Internet Economics Workshop in its > entirety on April 6 & 7, 1995. The original workshop was held on March > 9th and 10th. The rebroadcast will begin at 9am (Eastern Daylight > Savings Time) on April 6 & 7. We will be putting in the videotapes > from the workshop one-right-after-the-other. Given that the IETF meeting is currently taking place and the MBONE is not coping very well with that, it seems strange to schedule (at very short notice) a *retransmission* of an event that has already taken place. Could this not be rescheduled for a slightly later date? ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Thu Apr 6 09:58:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 08:59:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 08:59:02 -0700 Received: from ss10.mag.keio.ac.jp by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 08:59:00 -0700 Received: from localhost by ss10.mag.keio.ac.jp (8.6.10+2.5Wb1/2.7W) id AAA02520; Thu, 6 Apr 1995 00:58:50 +0900 Return-Path: Message-Id: <199504051558.AAA02520@ss10.mag.keio.ac.jp> To: mbone Cc: jones@hq.unu.edu, toyokuni@mag.keio.ac.jp, yama@glocom.ac.jp Cc: nazo@mag.keio.ac.jp, tomy@mag.keio.ac.jp Subject: conference using mbone Date: Thu, 06 Apr 1995 00:58:49 +0900 From: Jun Toyokuni To: whole Internet mbone We, United Nations University, will have an international conference on environmental issues in 6th and 7th April. The Conference will be broadcasted via M-bone, for which purpose, we will create a session. 1. The First UNU World Congress on Zero Emission Research Initiative 2. Name of the session: ZERI Congress 3. Media: nv, vat 4. Band Width: 128Kbps (nv 64kbps, vat dvi 64kbps) 5. The First Day Sessions: 4/6/95 9:00am - 5:00pm (JST) The Second Day Sessions: 4/7/95 9:00am - 5:00pm (JST) 7. Initial TTL: 128 8. Contact to: Ed Jones, United Nations University (Aoyama, Tokyo) Phone: +81-3-5467-1350 9. E-mail: JONES@hq.unu.edu 10. WWW: http://www.glocom.ac.jp/UN/unhp-e.html -- Ed Jones United Nations University JONES@hq.unu.edu -- sender: toyokuni@mag.keio.ac.jp From list-mgr@ISI.EDU Wed Apr 5 12:26:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 13:26:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 13:25:49 -0700 Received: from davinci.gmu.edu ([199.26.254.51]) by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 13:25:46 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id QAA12352; Wed, 5 Apr 1995 16:26:48 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199504052026.QAA12352@davinci.gmu.edu> Subject: Sound problems with SUNOS 4.1.3 (NOT SOLARIS) and VAT To: mbone Date: Wed, 5 Apr 1995 16:26:48 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 865 The subject was wrong in the previous message. The problem is with SunOS 4.1.3, sorry about that. Hello, We are experiencing sound problems on a Sparc 5 with SunOS 4.1.3. We have installed the 'latest' patch by Sun for sound problems. The audio tool works fine but the sound on vat drops after the first second of play to level 0. The packets are coming in ok apparently as other applications are utilizing them (ie nv, wb). Any ideas, thoughts or solutions would be appreciated. Michael -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Wed Apr 5 12:24:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 13:24:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 13:23:55 -0700 Received: from davinci.gmu.edu ([199.26.254.51]) by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 13:23:50 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id QAA12341; Wed, 5 Apr 1995 16:24:42 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199504052024.QAA12341@davinci.gmu.edu> Subject: Sound problems with Solaris 2.3 and VAT To: mbone Date: Wed, 5 Apr 1995 16:24:41 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 581 Hello, We are experiencing sound problems on a Sparc 5 with SunOS 4.1.3. We have installed the 'latest' patch by Sun for sound problems. The audio tool works fine but the sound on vat drops after the first second of play to level 0. The packets are coming in ok apparently as other applications are utilizing them (ie nv, wb). Any ideas, thoughts or solutions would be appreciated. Michael -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Wed Apr 5 06:50:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 13:50:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 13:50:25 -0700 Received: from euclid.jpl.nasa.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 13:50:23 -0700 Received: by euclid.Jpl.Nasa.Gov (8.6.10/SMI-4.1+DXRm2.5) id NAA00706; Wed, 5 Apr 1995 13:50:33 -0700 Subject: mrouted 3.4 warnings To: mbone Reply-To: Peter.J.Scott@jpl.nasa.gov X-Mailer: Poste 2.0 From: "Peter J. Scott" Date: Wed, 5 Apr 95 13:50:31 -0700 Message-Id: <950405135031.28960@euclid> Encoding: 6 TEXT, 2 TEXT SIGNATURE I put the latest mrouted 3.4 on my Sun IPX running SunOS 4.1.3, and I see occasional log messages of the form Apr 4 18:22:11 euclid mrouted[24315]: warning - setsockopt DVMRP_DEL_MFC: No such process Anyone know what's going on? Peter J. Scott, Member of Technical Staff | Peter_J_Scott@jpl.nasa.gov Jet Propulsion Laboratory, NASA/Caltech | Navigation Systems Section From list-mgr@ISI.EDU Wed Apr 5 14:27:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 15:27:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 15:27:31 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 15:27:30 -0700 Received: from CAES-SUN-3.MIT.EDU by MIT.EDU with SMTP id AA05679; Wed, 5 Apr 95 18:27:17 EDT Received: by caes-sun-3.MIT.EDU (5.0/4.7) id AA00584; Wed, 5 Apr 1995 18:27:15 -0400 Message-Id: <9504052227.AA00584@caes-sun-3.MIT.EDU> To: rem-conf@es.net, mbone Cc: bailey@farnsworth.mit.edu, nomad@farnsworth.mit.edu, jimmy@MIT.EDU Subject: Rebroadcast of Internet Economic Workshop -- Rescheduled Date: Wed, 05 Apr 1995 18:27:14 EDT From: Chi-ming Lai Content-Length: 582 Dear mbone folks, The previously announced rebroadcast of the Internet Economic Workshop will be rescheduled to this Friday (April 7th) and next Monday (April 10) to avoid conflict with the IEFT sessions and the upcoming web conference sessions. The rebroadcast will take place during the following period: April 7th: 9am-~4.30pm (EDT) April 10th: 9am-~3.30pm (EDT) Please refer to http://rpcp.mit.edu/Workshops/mbone.html for more info. and the original agenda. Again, comments and questions can be directed to bailey@farnsworth.mit.edu, or jimmy@mit.edu Thanks. -Jimmy Lai From list-mgr@ISI.EDU Wed Apr 5 08:43:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 15:44:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 15:44:01 -0700 Received: from hp.com by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 15:43:59 -0700 Received: from hpindlm.cup.hp.com by hp.com with ESMTP (1.37.109.15/15.5+ECS 3.3) id AA116821837; Wed, 5 Apr 1995 15:43:57 -0700 Received: by hpindlm.cup.hp.com (1.37.109.16/15.5+IOS 3.20+cup+OMrelay) id AA253601833; Wed, 5 Apr 1995 15:43:53 -0700 Date: Wed, 5 Apr 1995 15:43:53 -0700 From: Ken Mintz Message-Id: <199504052243.AA253601833@hpindlm.cup.hp.com> To: mbone Subject: Re: DVMRP_DEL_MFC: no such process Peter J. Scott writes: > Apr 4 18:22:11 euclid mrouted[24315]: warning - setsockopt DVMRP_DEL_MFC: > No such process > > Anyone know what's going on? We've this log message as well on 3.3. The error is misleading. It is really errno ESRCH, which the IPM kernel code returns when it cannot find the cache entry that mrouted requests to delete with setsockopt(DVMRP_DEL_MFC). I have not isolated the problem. Of course, it could be a kernel error. But I suspect that it is either an mrouted coding or design error. Oddly, DVMRP_DEL_MFC (really del_mfc in the kernel) ignores any "incomplete" cache entry when it does its search. This would be a cache entry that was created by ip_mforward (i.e. forwarding an mcast). In that case, the kernel creates the cache entry and sends an "upcall" igmp message to mrouted. The expectation is that mrouted will come back later with a setsockopt(DVMRP_ADD_MFC) to complete the entry. But I have wondered if there are circumstances (rightly or wrongly) under which mrouted will attempt to delete the cache entry before it tries to complete it. (I have not looked at mrouted at all. This is blind speculation. But I don't know why del_mfc would not allow mrouted to delete an incomplete cache entry, for whatever reason. That raises my suspicions.) In any case, we have seen this error only on rare occassion. We have tried to create this error on our own, to no avail. I suspect that it happens as a result of specific events on the mbone because we have seen this logged at a time when we were __not__ running any tests. If anyone can reproduce this error at will, I would appreciate some information on how we could do the same. I have instrumented a kernel so that we could isolate the culprit to some degree, at least to identify the sequence of kernel events that lead up to this. -- Regards, Ken Mintz PS: On a multiprocessor IPM kernel, there is another possible explanation. At least in our MP design, there is a race condition with cleanup_cache being called when softclock() processes the callout list. This can arise even on uniprocessor systems if softclock() is not an splnet soft-interrupt. That is, splnet() may not be sufficient to guarantee mutual exclusion. But this is highly dependent on vendor system design, so I don't know to what extent this might affect other implementations. In any case, this is a corner-case situation which I do not believe would happen even with the frequency with which we are seeing the ESRCH logs. From list-mgr@ISI.EDU Wed Apr 5 13:06:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 20:08:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 20:07:21 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 5 Apr 1995 20:07:20 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14408(1)>; Wed, 5 Apr 1995 20:07:13 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49864>; Wed, 5 Apr 1995 20:07:03 -0700 To: Ken Mintz Cc: mbone Subject: Re: DVMRP_DEL_MFC: no such process In-Reply-To: Your message of "Wed, 05 Apr 95 15:43:53 PDT." <199504052243.AA253601833@hpindlm.cup.hp.com> Date: Wed, 5 Apr 1995 20:06:53 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Apr5.200703pdt.49864@crevenia.parc.xerox.com> In message <199504052243.AA253601833@hpindlm.cup.hp.com> you write: >Peter J. Scott writes: >> Apr 4 18:22:11 euclid mrouted[24315]: warning - setsockopt DVMRP_DEL_MFC: >> No such process >> >> Anyone know what's going on? mrouted and the kernel get out of sync sometimes. It is a bug in mrouted 3.[34]. I have rewritten most of prune.c in 3.5, to help mrouted keep closer track of the kernel cache, and have not experienced this bug at all in my 3.5 testing. > Oddly, DVMRP_DEL_MFC (really del_mfc in the kernel) ignores any > "incomplete" cache entry when it does its search. This is because if the kernel and mrouted are properly synchronized, mrouted won't even know about any incomplete cache entries until it has installed the route, so it certainly won't try to delete an incomplete cache entry. Bill From list-mgr@ISI.EDU Wed Apr 5 17:46:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 00:44:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 00:43:51 -0700 Received: from nexsys.nexsys.net by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 00:43:49 -0700 Received: by nexsys.nexsys.net (8.6.10/SM-8.6.4) id AAA16184; Thu, 6 Apr 1995 00:46:24 -0700 Date: Thu, 6 Apr 1995 00:46:23 -0700 (PDT) From: Geoff White Subject: ANNOUNCE: mbone broadcast 0000 - 0600 April 9 PDT To: mbone Cc: cyberlab7@aol.com, geoffw@v-site.net Message-Id: We at Cyberlab would like to broadcast live video and audio to the world On the night of April 8 - April 9. This will be a live broadcast of a visual and aural multimedia event. We invite the Internet community to plug-in, turn-on and reach out. We will also have simultaneous CUseeme sessions going all night. And invite anyone else to set up corresponding mbone video/audio sessions which we will be projecting on our large screen projectors. VibeLab Live begins at midnight PDT April 9, 1995 From list-mgr@ISI.EDU Thu Apr 6 10:57:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 02:00:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 01:57:35 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 01:57:29 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id JAA24390; Thu, 6 Apr 1995 09:57:21 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id JAA13747; Thu, 6 Apr 1995 09:57:18 +0100 Date: Thu, 6 Apr 1995 09:57:17 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Michael Benson Cc: mbone Subject: Re: Sound problems with SUNOS 4.1.3 (NOT SOLARIS) and VAT In-Reply-To: <199504052026.QAA12352@davinci.gmu.edu> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Apr 1995, Michael Benson wrote: > We are experiencing sound problems on a Sparc 5 with SunOS 4.1.3. > > We have installed the 'latest' patch by Sun for sound problems. The > audio tool works fine but the sound on vat drops after the first > second of play to level 0. The packets are coming in ok apparently > as other applications are utilizing them (ie nv, wb). Which patch did you install? The one that ought to be installed is 102161-03. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Thu Apr 6 05:24:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 06:26:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 06:25:29 -0700 Received: from mailer.jhuapl.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 06:25:28 -0700 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA16018; Thu, 6 Apr 1995 09:25:27 -0400 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA16061; Thu, 6 Apr 1995 09:24:32 -0400 Date: Thu, 6 Apr 1995 09:24:31 -0400 (EDT) From: Jim Bogard BIX Subject: nv and cuseeme To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1176 Firstly, thanks to everyone for thier help thus far. I have waded through the mail archives and FAQs, but am unable to answer my next question: I am able to view video captured with nv3.3 on a CUseeme client using the cuseeme encoding option and point-to-point transmission. Whew. Is there an agent "Mixer?" which will translate between nv and cuseeme? IE, I'd like be able to translate and retransmit mbone nv broadcasts for the viewing pleasure of our local Macs. (short ttl). Although I haven't yet verified it, my reading to date leads me to believe vat will provide such a service for audio. This does not seem to be the case with nv. Help! On a related note, reflect (3.0b3) croaks when I try to set it up with multicast parameters. Bombs immediately with Version: 3.00B3 1: MOTD Welcome to the reflector! 2: NV-MC-PORT 4444 3: NV-MC-IN 224.2.1.1 4: NV-MC-OUT 16 224.2.1.1 recvfrom error on nv_ucast_sock : Socket operation on non-socket: FATAL ERROR: EXITING What is it trying to do with unicast? Anyone else have this problem? I have the multicast kernel and mrouted(3.4) running on the same machine.. SunOs 4.1.4. Conflict? Thanks. J-. From list-mgr@ISI.EDU Thu Apr 6 13:57:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 14:58:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 14:57:59 -0700 Received: from mailer.psc.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 14:57:58 -0700 Received: from sabre.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA14542; Thu, 6 Apr 1995 17:57:55 -0400 Message-Id: <9504062157.AA14542@mailer.psc.edu> To: mbone Cc: mahdavi@sabre.psc.edu, mathis@sabre.psc.edu Subject: FYI -- PSC transitioning to MCInet... Date: Thu, 06 Apr 1995 17:57:54 -0400 From: "Jamshid Mahdavi" PSC is in the process of transitioning to MCInet. This means that over the next few weeks our mrouters will be moving back and from between ANS and MCI. Currently, we are dual attached, with our default route pointing out ANS. I believe this is actually the optimal routing situation for mbone traffic. Sometime tomorrow, however, the ANS link will disappear for the weekend. Matt tells me this isn't really a bad thing for the mbone, but I wanted to make sure those who might care know. --Jamshid From list-mgr@ISI.EDU Thu Apr 6 15:38:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 16:37:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 16:37:09 -0700 Received: from davinci.gmu.edu ([199.26.254.51]) by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 16:37:08 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id TAA02096; Thu, 6 Apr 1995 19:38:12 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199504062338.TAA02096@davinci.gmu.edu> Subject: Sunos 4.1.3 and Sparc 5. Does it work? To: mbone Date: Thu, 6 Apr 1995 19:38:12 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 623 For some reason, even though we installed the right patch, 102161-03, we only get a second of sound on the Sparc 5/Sunos4.1.3 combination. We used the MIT script to modify the kernel for use with multicast. Can anyone confirm that they have a working combination of this type ( Sparc 5 with SunOS 4.1.3)? Can anyone verify that they have a working combination of Sparc 5 with Solaris 2.3? 2.4? Michael (Still searching for a solution) -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Thu Apr 6 11:58:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 18:59:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 18:58:56 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 18:58:55 -0700 Received: by rx7.ee.lbl.gov (8.6.11/1.43r) id SAA08769; Thu, 6 Apr 1995 18:58:53 -0700 Message-Id: <199504070158.SAA08769@rx7.ee.lbl.gov> To: ietf@CNRI.Reston.VA.US, ietf32-multicast@ietf.org Cc: mbone Subject: Danvers ietf trashing mbone with 800kb/s video Date: Thu, 06 Apr 95 18:58:51 PDT From: Van Jacobson The Danvers IETF channel one video from ietf-mc1 (199.92.188.1) is currently being sent at 800kb/s. The same channel was also sending video at this ridiculous rate last night until I screamed at them. I assumed the people doing this broadcast would know better. Apparently not. Multicast routing has gotten extremely unstable as mrouters are falling over around the world. Would you please reduce your video rate to <100kb/s and not raise it again? Thank you. - Van From list-mgr@ISI.EDU Thu Apr 6 16:25:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 21:26:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 21:25:49 -0700 Received: from scapa.cs.ualberta.ca ([129.128.4.44]) by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 6 Apr 1995 21:25:47 -0700 Received: from nisku.cs.ualberta.ca by scapa.cs.ualberta.ca id <13070-8>; Thu, 6 Apr 1995 22:25:40 -0600 Subject: Recording of MBONE sessions From: Kannan Thiruvengadam To: mbone Date: Thu, 6 Apr 1995 22:25:43 -0600 (MDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 276 Message-Id: <95Apr6.222540-0600_mdt.13070-8+232@scapa.cs.ualberta.ca> Hi, I am looking for recordings of MBONE sessions, preferably those with slides displayed using a web-browser. I need the files themselves. I just want some test data for the playback routines I have written. Thanks a hundred (I don't believe in wasting things:)) - Kannan From list-mgr@ISI.EDU Fri Apr 7 12:03:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 01:06:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 01:05:41 -0700 Received: from my.sm.luth.se ([130.240.3.1]) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 01:04:38 -0700 Received: from unauthenticated@io.sm-staff (io.cdt.luth.se) by my.sm.luth.se with SMTP (5.67b8/IDA-1.2.8-NS) id AA02720; Fri, 7 Apr 1995 10:03:57 +0200 Received: from io.cdt.luth.se (localhost) by io.sm-staff (5.x/SMI-SVR4) id AA04093; Fri, 7 Apr 1995 10:03:02 +0200 Message-Id: <9504070803.AA04093@io.sm-staff> X-Mailer: exmh version 1.6gamma+ 4/3/95 To: mbenson@davinci.gmu.edu (Michael Benson) Cc: mbone, hakanl Subject: Re: Sunos 4.1.3 and Sparc 5. Does it work? In-Reply-To: Your message of "Thu, 06 Apr 1995 19:38:12 EDT." <199504062338.TAA02096@davinci.gmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 07 Apr 1995 10:03:01 +0200 From: Hakan Lennestal In message <199504062338.TAA02096@davinci.gmu.edu>, Michael Benson writes= : = > Can anyone verify that they have a working combination of Sparc 5 with = Solari > s > 2.3? 2.4? We are having a "kind of" working combination of Sparc 5 and Solaris 2.4.= When the 102125-02 patch was applied Vat started to work as expected. Most other things like NeVot and "cat > /dev/audio" does however still not work... /H=E5kan = E-mail: Hakan.Lennestal@cdt.luth.se Hakan.Lennestal@lu.erisoft.se = = | Phone: +46-920-42844 | Work: | Home: o o = = | Fax: +46-920-97545 | erisoft AB | Hakan Lennestal = = | Home: +46-920-68253 | Box 920 o | Sodra Kungsgatan= 32 = | Memo: ERI.EPL.EPLHLL | S-97128 Lulea, SWEDEN | S-97235 Lulea, S= WEDEN = | From list-mgr@ISI.EDU Fri Apr 7 17:08:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 04:08:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 04:08:22 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 04:08:17 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.11/8.6.9) id OAA01582; Fri, 7 Apr 1995 14:08:11 +0300 Date: Fri, 7 Apr 1995 14:08:11 +0300 Message-Id: <199504071108.OAA01582@silver.sms.fi> From: Petri Helenius To: mbone Subject: HP-UX 9.05 patches Anyone know how to set the default samplerate with HP-UX's /dev/audio, vat seems not to change that from the default of 16000 Hz. Pete From list-mgr@ISI.EDU Fri Apr 7 14:00:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 05:19:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 05:18:51 -0700 Received: from mailhost.lut.ac.uk (bgate.lut.ac.uk) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 05:18:32 -0700 Received: from suna ([158.125.101.100]) by suna.lut.ac.uk (8.6.11/8.6.11) with SMTP id NAA25824; Fri, 7 Apr 1995 13:17:24 +0100 Date: Fri, 7 Apr 1995 13:00:43 +0100 (BST) From: "Jon P. Knight" Subject: Re: nv and cuseeme To: Jim Bogard BIX Cc: mbone In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 6 Apr 1995, Jim Bogard BIX wrote: > On a related note, reflect (3.0b3) croaks when I try to set it up with > multicast parameters. Bombs immediately with >[...] > recvfrom error on nv_ucast_sock : Socket operation on non-socket: FATAL > ERROR: EXITING > > What is it trying to do with unicast? Anyone else have this problem? I > have the multicast kernel and mrouted(3.4) running on the same machine.. > SunOs 4.1.4. Conflict? I've seen this with the Cornell reflector code before. As I rather needed to use it, I tore it apart in the debugger to find out what was up. It turns out that they appear to try socket magic on oridinary file descriptors. I applied a judicious amount of commenting out of these operations and it then seemed to chug along nicely. I filed a bug report with Cornell but I can't remember getting a reply. Anyway, I've tarred up my working code (source and a SunOS4.1.x binary) and stuck it up on . This runs fine for me on a machine running SunOS4.1.4. YMMV. Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Research Student in High Performance Networking and Distributed Systems in the Department of _Computer_Studies_ at Loughborough University. * It's not how big your share is, its how much you share that's important * From list-mgr@ISI.EDU Fri Apr 7 05:18:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 06:19:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 06:19:07 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 06:19:05 -0700 Received: from CAES-SUN-3.MIT.EDU by MIT.EDU with SMTP id AA00854; Fri, 7 Apr 95 09:18:55 EDT Received: by caes-sun-3.MIT.EDU (5.0/4.7) id AA01746; Fri, 7 Apr 1995 09:18:55 -0400 Message-Id: <9504071318.AA01746@caes-sun-3.MIT.EDU> To: rem-conf@es.net, mbone Cc: bailey@farnsworth.mit.edu, nomad@nmis.org, jimmy@MIT.EDU Subject: Internet Economic Workshop (rebroadcast) Date: Fri, 07 Apr 1995 09:18:54 EDT From: Chi-ming Lai Content-Length: 258 Greetings, Due to some technical problem, the broadcast was delayed by 15 min., and it started at 9.15am (EDT) today (April 7th). I would like to ask for your comment on the quality of the audio and video, if you have a chance to watch it. Thanks, Jimmy From list-mgr@ISI.EDU Fri Apr 7 05:53:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 09:19:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 09:18:24 -0700 Received: from mons.uio.no by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 09:18:19 -0700 Received: from ulrik.uio.no by mons.uio.no with local-SMTP (PP) id <21863-0@mons.uio.no>; Fri, 7 Apr 1995 18:07:41 +0200 Received: from habrok.uio.no by ask.uio.no ; Fri, 7 Apr 1995 15:55:27 +0200 From: terje.vernly@usit.uio.no Received: by habrok.uio.no ; Fri, 7 Apr 1995 09:53:00 -0400 Date: Fri, 7 Apr 1995 09:53:00 -0400 Message-Id: <199504071353.JAA29588@habrok.uio.no> To: pete@silver.sms.fi Cc: mbone In-Reply-To: <199504071108.OAA01582@silver.sms.fi> (message from Petri Helenius on Fri, 7 Apr 1995 14:08:11 +0300) Subject: Re: HP-UX 9.05 patches Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII With a BIG smile, Petri Helenius wrote: > Anyone know how to set the default samplerate with HP-UX's /dev/audio, > vat seems not to change that from the default of 16000 Hz. The following pice of code will do the trick: -----------cut here------------ #include #include #include #include int main(int argc, char **argv) { int afd; if ((afd=open("/dev/audioCtl",O_RDWR|O_NONBLOCK))!=-1) ioctl(afd,AUDIO_SET_SAMPLE_RATE,8000); close(afd); } -----------cut here------------ The default samplerate is supposed to be 8 kHz, but due to a bug in the audio device-driver it is not reset on the last close(2) on /dev/audio. As a result, the last configured samplerate will be used as the default for the next open(2) of /dev/audio. I think patch PHKL_5049 is supposed to fix the problem, but I haven't had time to try it yet. Terje From list-mgr@ISI.EDU Sat Apr 8 18:30:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 19:34:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 19:34:10 -0700 Received: from jupiter.cc.nus.sg by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 7 Apr 1995 19:34:07 -0700 Received: (from engp4057@localhost) by jupiter.cc.nus.sg (8.6.9/8.6.9) id KAA00828; Sat, 8 Apr 1995 10:30:49 +0800 Date: Sat, 8 Apr 1995 10:30:48 +0800 (SST) From: Song Choo Beng To: mbone Subject: unsubscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! could anyone please tell me how should i unsubscribe from this mailing list. I understand that mbone@isi.edu has been divided to various regional sites, however, from the mails that I received I am still remained at mbone@isi.edu. Thus, where should I locate the request site that I should forward my unsubscribe message? regards. song From list-mgr@ISI.EDU Sat Apr 8 16:52:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 8 Apr 1995 05:53:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 8 Apr 1995 05:52:24 -0700 Received: from concorde.inria.fr by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 8 Apr 1995 05:52:10 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id OAA05173 for ; Sat, 8 Apr 1995 14:52:03 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id OAA26966 for ; Sat, 8 Apr 1995 14:52:02 +0200 Message-Id: <199504081252.OAA26966@givry.inria.fr> From: Francis Dupont To: mbone Subject: a little bug in SunOS IP multicast Date: Sat, 08 Apr 1995 14:52:01 +0200 Sender: Francis.Dupont@inria.fr I've found a little but annoying bug in the SunOS IP multicast, I've already pointed out it but it is still here in current distribs. In the file sys/netinet/ip_output.c the function ip_setmoptions() the route structure variable "ro" is not fully initialized. I propose to replace the line: ro.ro_rt = NULL; by bzero((caddr_t)&ro, sizeof (ro)); It is far more correct and it works with multicast host routes (rtalloc() uses a bcmp on the whole sockaddr structure for host route matching). Francis.Dupont@inria.fr From list-mgr@ISI.EDU Sun Apr 9 14:11:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 9 Apr 1995 15:12:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 9 Apr 1995 15:11:54 -0700 Received: from ANDREW.CMU.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 9 Apr 1995 15:11:53 -0700 Received: (from postman@localhost) by andrew.cmu.edu (8.6.9/8.6.9) id SAA10726 for mbone@isi.edu; Sun, 9 Apr 1995 18:11:51 -0400 Received: via switchmail; Sun, 9 Apr 1995 18:11:50 -0400 (EDT) Received: from pcs9.andrew.cmu.edu via qmail ID ; Sun, 9 Apr 1995 18:11:16 -0400 (EDT) Received: from pcs9.andrew.cmu.edu via qmail ID ; Sun, 9 Apr 1995 18:11:14 -0400 (EDT) Received: from mms.4.60.Jan.26.1995.18.43.47.sun4c.411.EzMail.Client.2.0.CUILIB.3.45.SNAP.NOT.LINKED.pcs9.andrew.cmu.edu.sun4c.411 via MS.5.6.pcs9.andrew.cmu.edu.sun4c_411; Sun, 9 Apr 1995 18:11:14 -0400 (EDT) Message-Id: Date: Sun, 9 Apr 1995 18:11:14 -0400 (EDT) From: Matthew G Newcomb To: mbone Subject: What is this? Cc: G'day, Can anyone tell me more about this service? Doesn't sound like mbone. Matt ---------- Forwarded message begins here ---------- INTERNET AUDIO NEW YORK (AP) -- A new company will give broadcasters a first glimpse Monday at a way to listen to things through the Internet without using a cumbersome and disliked technical process. The breakthrough will allow audio-on-demand services on the global computer network, an appealing advance for consumers, broadcasters and other sound-oriented companies. For instance, a local radio station could make its newscasts or sports play-by-plays accessible to someone living in another state anytime that person wants. The product, dubbed RealAudio, was developed by Progressive Networks, a year-old Seattle software company. From list-mgr@ISI.EDU Sun Apr 9 11:58:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 9 Apr 1995 18:59:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 9 Apr 1995 18:58:55 -0700 Received: from osi-east.es.net by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 9 Apr 1995 18:58:54 -0700 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <07388-0@osi-east.es.net>; Sun, 9 Apr 1995 18:58:50 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA13023; Sun, 9 Apr 95 18:58:48 PDT Date: Sun, 9 Apr 95 18:58:48 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9504100158.AA13023@viipuri.nersc.gov> To: mbone, mn2g+@andrew.cmu.edu Subject: RealAudio (was What is this?) >Can anyone tell me more about this service? Doesn't sound like mbone. It appears to be demand-delivered audio from server(s) using a proprietary client (which they intend to distribute for free) and server (which they will sell). According to the rest of the story, the client can operate using a 14.4 modem and prvide "AM quality" audio. I'm sure more on this will appear in the press during this week as RealAudio is being lauched at the NAB show in LasVegas. Apparently ABC is planning to distribute hourly newscasts, NPR is planning to provide access to the MorningProgram and All Things Considered, while On-Ramp will use REalAudio to distribute its programs beginning 4/10! Progressive has a Web page at http://www.prognet.com where you might be able to sign up as a beta tester (the same page is accessible through http://www.realaudio.com). It's definitely NOT Mbone! It would be interesting if someone involved would explain whether it's TCP or UDP based... ----------------------D--I--S--C--L--A--I--M--E--R-------------------------- NOTHING in this posting should be misconstrued to represent the view(s) and/or official position of the US Government, Department of Energy, University of California, LLNL, RECOM Technologies Inc. or of anyone else other than the undersigned Ari@ES.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 ~~RECOM Technologies Inc.~~ From list-mgr@ISI.EDU Sun Apr 9 23:44:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 00:44:53 -0700 Received: from relay2.UU.NET by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 00:44:51 -0700 Received: from alterdial.UU.NET by relay2.UU.NET with SMTP id QQykve25381; Mon, 10 Apr 1995 03:44:46 -0400 Received: from [198.4.181.158] by alterdial.UU.NET with SMTP id QQykve08137; Mon, 10 Apr 1995 03:44:41 -0400 Date: Mon, 10 Apr 1995 03:44:41 -0400 X-Sender: mail00821@alterdial.uu.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone-na From: adamgood@voices.com (Adam Goodman) Subject: RealAudio You know, we spend so much time worrying about the MBONE's bandwidth requirements, and yet, stuff like this is so much worse! Somebody please correct me if I am wrong about this, but isn't the MBONE at an extreme bandwidth usage advantage over a system like RealAudio? Won't RealAudio be sending lots of LARGE streams of unicast data to everyone that logs onto their server? Won't it be detrimental to already overloaded Internet backbones to offer this service to every non-technical person with a PC connected to the Internet today? At least with the MBONE you kind of have to know what you are doing. . . -Adam Adam M. Goodman Mulsanne Communications 19 W. 44th St. Ste. 1217 New York, NY 10036 ph# (212) 221-7065 fx# (212) 221-1413 From list-mgr@ISI.EDU Fri Apr 10 05:27:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 04:27:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 04:27:09 -0700 Received: from alink-gw.apple.com by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 04:27:07 -0700 Received: by alink-gw.apple.com (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA27682; Mon, 10 Apr 95 04:26:57 -0700 for MBONE@ISI.EDU Date: 10 Apr 95 05:27 GMT From: CREIGHTON.B@AppleLink.Apple.COM (Creighton, Bert) Subject: UNSUBSCRIBE To: MBONE Message-Id: <797513217.4271071@AppleLink.Apple.COM> Greetings, Can someone help me with unsubscribing from the MBONE list? Thanks for any assistance... Bert From list-mgr@ISI.EDU Mon Apr 10 04:47:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 11:48:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 11:47:44 -0700 Received: from osi-east.es.net by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 11:47:40 -0700 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <23798-0@osi-east.es.net>; Mon, 10 Apr 1995 11:47:11 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA13863; Mon, 10 Apr 95 11:47:09 PDT Date: Mon, 10 Apr 95 11:47:09 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9504101847.AA13863@viipuri.nersc.gov> To: mbone Subject: PN's announcement of RealAudio PROGRESSIVE NETWORKS LAUNCHES THE FIRST COMMERCIAL AUDIO-ON-DEMAND SYSTEM OVER THE INTERNET SEATTLE, April 10, 1995 - Progressive Networks (PN), an interactive communications company focused on the delivery of real-time audio on demand over the Internet, was launched today. The company also introduced its RealAudio(TM) audio-on-demand development and delivery system (http://www.RealAudio.com/) and announced that its first two content partners are the American Broadcasting Company (ABC) and National Public Radio (NPR). Leading-edge website providers Metaverse, HotWired, GNN and RadioNetHuman/Factor, among others, will also be producing audio entertainment and news using RealAudio technology that can be enjoyed by their users at the touch of a button. The RealAudio system enables users equipped with conventional multimedia personal computers and voice-grade telephone lines to browse, select and play back audio or audio-based multimedia content on demand, as easily as using a standard video cassette player/recorder. PN's RealAudio system makes it possible for providers of entertainment, information and news content to deliver audio-on-demand services that can be accessed and played back immediately. This is a real breakthrough compared to typical download times encountered with delivery of audio over conventional on-line methods, in which audio is downloaded at a rate that is five to ten times longer than the actual program - e.g., the listener must wait 25 minutes before listening to just five minutes of audio. Progressive Networks was founded by Rob Glaser, formerly vice president of Multimedia and Consumer Systems at Microsoft Corporation. Progressive Networks' lead outside investor is Mitchell Kapor, founder of Lotus Development Corporation and the Electronic Frontier Foundation. "We recognized an immediate opportunity for content providers to develop and offer exciting on-demand services today, years ahead of the infrastructure investment needed for video on demand. We are bringing one of the oldest and most popular forms of electronically transmitted entertainment, sports, music and news programming, called radio - into the next century," said Glaser. "We can now help audio content providers make a wealth of programming available to Internet users and enable users to access this material for the first time on demand." "Our involvement with PN is part of ABC's continuing commitment to using today's innovative technologies to bring news, sports and entertainment programming to our audience," said ABC's Kathryn Dillon, vice president of Production and Technology in the Capital Cities/ABC Multimedia Group. "Our audio library consists of hundreds of thousands of hours of great entertainment as well as memorable news and sporting events. RealAudio affords us an opportunity to make this programming available to today's Internet and on-line users as well as an ability to create innovative new multimedia programming that will attract new users." "RealAudio provides NPR listeners with a unique new way to hear selections from their favorite NPR programs. This opportunity will be especially important for listeners whose crowded schedules cause them to miss over-the-air broadcasts by our member stations," said Del Lewis, president of NPR. "We are eager to continue working with Progressive Networks to use their innovative new Internet technology to provide improved services to our listeners and member stations." "We are excited to offer RealAudio programming that our customers can instantly access," said Adam Curry, president, Metaverse. "This will greatly expand our audio programming opportunities for an even richer Internet experience." PN's RealAudio Product Line In order to build the market for audio-on-demand, PN is introducing three RealAudio products, each designed for a specific market segment: RealAudio Player for consumers, RealAudio Studio for content creators and RealAudio Server for on-line publishers. The products work together to provide a comprehensive distributed client/server system. RealAudio Player is client-based software that enables Internet and on-line users to access existing audio for instant playback. Available free over the Internet for Windows, Macintosh and select UNIX workstations, the RealAudio Player can be used either in a standalone fashion or through integration with standard Internet Web browsers. RealAudio Studio, the second RealAudio product being introduced, enables multimedia on-line creators to develop their own programs delivering audio-on-demand or audio-based multimedia streams. Studio will be available in three forms: a trial version that can be downloaded freely for evaluation purposes, a standard version and a professional version. The standard and professional versions will be available first for Windows, with other versions to follow as market demand develops. RealAudio Server, the third product, enables major media content providers to distribute audio or audio-based multimedia streams over the Internet to a broad base of consumers and end users. RealAudio Servers will be available for Windows NT and a range of UNIX-based server platforms. Beta versions of the RealAudio Player, Studio and Server products are available now on a limited basis. Production versions of the RealAudio Player for Windows and Server for UNIX and Windows NT will be available by mid-year. Production versions of the RealAudio Player for Macintosh and the RealAudio Studio will be available in the third quarter. Content Delivery using PN's RealAudio Products PN plans to work with content and media partners in two ways: by providing RealAudio Server software to media companies that already have an on-line presence, and by selectively distributing content from media partners and providing it directly to consumers on Internet sites managed and maintained by PN. PN is working with independent content publishers such as Metaverse, HotWired, GNN and RadioNet who are interested in using RealAudio to enhance their own Web sites. They will be offering RealAudio entertainment and information programming for their users. The ABC and NPR relationships are examples of cases where PN will be involved in the distribution of content. ABC's initial offering will consist of RealAudio-based news content, to be updated on a hourly basis. NPR is licensing content from four of its popular programs to Progressive Networks, including "All Things Considered" and "Morning Edition," which will be accessible to users on the RealAudio Internet site. About Progressive Networks Progressive Networks, based in Seattle, develops and markets software products and services designed to enable users of personal computers and other digital devices to send and receive audio and audio-based multimedia services using the existing infrastructure. For additional information, please contact us on the Web at http://www.RealAudio.com, e-mail us at info@realaudio.com. If you're with the press, you can contact one of the following people: Progressive Networks Maria Cantwell, 206-447-0567 x231 KillerApp Communications Allison Thomas/Lauri Burrier/Katie Cotton, 818-509-3700 Rachel McCallister/Scott Grogin, 213-939-5991 ----------------------D--I--S--C--L--A--I--M--E--R-------------------------- NOTHING in this posting should be misconstrued to represent the view(s) and/or official position of the US Government, Department of Energy, University of California, LLNL, RECOM Technologies Inc. or of anyone else other than the undersigned Ari@ES.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 ~~RECOM Technologies Inc.~~ From list-mgr@ISI.EDU Mon Apr 10 11:50:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 12:51:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 12:51:01 -0700 Received: from relay.nswc.navy.mil by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 12:51:00 -0700 Received: from sunoco (sunoco.nswc.navy.mil) by relay.nswc.navy.mil (4.1/SMI-4.1) id AA17261; Mon, 10 Apr 95 15:50:53 EDT Received: from sparhawk.b35ita.sunoco by sunoco (5.x/SMI-SVR4) id AA08909; Mon, 10 Apr 1995 15:50:56 -0400 Received: by sparhawk.b35ita.sunoco (5.x/SMI-SVR4) id AA18093; Mon, 10 Apr 1995 15:50:55 -0400 Date: Mon, 10 Apr 1995 15:50:55 -0400 From: tplunke@relay.nswc.navy.mil (Tim Plunkett) Message-Id: <9504101950.AA18093@sparhawk.b35ita.sunoco> To: mbone Subject: recordings of the IETF mbone sessions X-Sun-Charset: US-ASCII Are there any anonymous ftp sites that hold recorded vat or nv sessions from last weeks IETF? Tim Plunkett tplunke@relay.nswc.navy.mil From list-mgr@ISI.EDU Mon Apr 10 10:32:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 17:35:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 17:33:13 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 17:33:11 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA06620; Mon, 10 Apr 95 17:32:12 PDT Date: Mon, 10 Apr 1995 17:32:11 -0700 (PDT) From: Michael Macedonia To: mbone Cc: rem-conf@es.net Subject: MIT is jamming mbone In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We are getting lots of icmp packets from krypton.mit.edu. on the I3dg symposium mcast. Can someone at MIT help fix it? Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From list-mgr@ISI.EDU Tue Apr 11 17:40:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 18:41:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 18:40:57 -0700 Received: from einstein.technet.sg by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 10 Apr 1995 18:40:54 -0700 Received: (from hweecher@localhost) by einstein.technet.sg (8.6.11/8.6.9) id JAA14800; Tue, 11 Apr 1995 09:40:49 +0800 Date: Tue, 11 Apr 1995 09:40:46 +0800 (SST) From: Tan Hwee Cher To: Song Choo Beng Cc: mbone Subject: Re: unsubscribe In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII yeap, it's done. rgds, hweecher Technet Unit On Fri, 7 Apr 1995, Song Choo Beng wrote: From list-mgr@ISI.EDU Tue Apr 11 07:28:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 11 Apr 1995 14:28:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 11 Apr 1995 14:28:25 -0700 Received: from sgi.sgi.com (SGI.COM) by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 11 Apr 1995 14:28:24 -0700 Received: from tree.engr.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for <@sgi.sgi.com:mbone@isi.edu> id OAA12007; Tue, 11 Apr 1995 14:28:24 -0700 Received: by tree.engr.sgi.com (940816.SGI.8.6.9/911001.SGI) for mbone@isi.edu id OAA29882; Tue, 11 Apr 1995 14:28:19 -0700 From: "Bill Nowicki" Message-Id: <9504111428.ZM29880@tree.engr.sgi.com> Date: Tue, 11 Apr 1995 14:28:15 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: mbone Subject: IETF 32 Multicast Postmortem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To clear up some rumors: the machines used to multicast the last IETF were not "PCs" but Silicon Graphics Indys with 100 Mhz R4000 CPUs, 1MB Secondary Cache and 64 MB RAM. There were problems the first day with using audio from the viedo camera microphones instead of the house audio line. There were unknown electrical problems with one of the video connections that caused distorted video on one channel at some times. One entire session was missed Thursday morning due to a software bug combined with misconfiguration (evidently the video library needs to have working name service!). Someone slid the data rate up by accident. Probably some other glitches. The lesson is that this is still experimental technology. Considering it was all donated equipment being used for the first time by volunteers, all the people from FTP, BBN, SGI, ISI, Xerox, etc. who helped deserve our thanks. Let us continue to improve. - Bill Nowicki Silicon Graphics From list-mgr@ISI.EDU Tue Apr 11 12:08:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 11 Apr 1995 15:11:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 11 Apr 1995 15:10:57 -0700 Received: from fnal.fnal.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 11 Apr 1995 15:10:54 -0700 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HP7XV7Z2XS00MH5Z@FNAL.FNAL.GOV>; Tue, 11 Apr 1995 17:10:12 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA27436; Tue, 11 Apr 95 17:08:59 CDT Date: Tue, 11 Apr 1995 17:08:58 -0500 From: Matt Crawford Subject: ipmulti3.3-sunos413x build failure In-Reply-To: Your message of Mon, 20 Mar 95 19:04:48 PST. <95Mar20.190458pst.49859@crevenia.parc.xerox.com> Sender: crawdad@munin.fnal.gov To: Bill Fenner Cc: mbone Message-Id: <9504112208.AA27436@munin.fnal.gov> Content-Transfer-Encoding: 7BIT When I build a kernel with MULTICAST (and the manadatory RSVP_ISI) but *without* MROUTING, I get the following undefined symbols. loading vmunix ld: Undefined symbol _mrt_ioctl _legal_vif_num I see that they are referenced in route.o and ip_output.o, respectively, but no stubs for them are in ip_mroute.c. So it looks like another "unfortunate error" (I'm quoting from README-3.3) for the binary-only users. No, I take that back. Even in the source, the references to mrt_ioctl and legal_vif_num are not inside #ifdef MROUTING. If I start pulling routines in ip_mroute.c outside the #ifdef MROUTING, I pretty soon wind up with just about everything, don't I? I'm adding the following stubs to ip_mroute.c. It links. I'll know soon if it runs. int mrt_ioctl(cmd, data) int cmd; caddr_t data; { return (EINVAL); } int legal_vif_num(vif) int vif; { return(0); } _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From list-mgr@ISI.EDU Wed Apr 12 06:35:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 07:36:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 07:35:50 -0700 Received: from cyclops.ece.ncsu.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 07:35:48 -0700 Received: by cyclops.ece.ncsu.edu (8.6.11/EC06jan95) id KAA00780; Wed, 12 Apr 1995 10:35:44 -0400 From: "Leigh Anne Rettinger" Message-Id: <9504121035.ZM778@eos.ncsu.edu> Date: Wed, 12 Apr 1995 10:35:43 -0400 X-Mailer: Z-Mail (3.2.1 15feb95) To: mbone, rem-conf@es.net Subject: MBone Announcement: Electronic Access to the EPA (18 Apr 95) Cc: alan_schueler@ncsu.edu, tkm@eos.ncsu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii MBone Announcement: Electronic Access to the EPA (18 Apr 95) Title: Electronic Access to EPA and Other Environmental Information Date: Tuesday, 18 Apr 95 Time: 12noon-4pm US/Eastern (16:00-20:00 GMT) Media: Audio (vat), Video (nv), Whiteboard (wb) (session will be announced in 'sd' on Tuesday morning) TTL: 127 Contact: Leigh Anne Rettinger (larettin@eos.ncsu.edu) Info at: http://www2.ncsu.edu/eos/service/ece/project/succeed_info/epainfo/ Abstract -------- This workshop will provide an overview of the various means of public access to EPA information through Internet and other systems, including the public access server, online library system, and OAQPS Technology Transfer Network BBS. Other sources of environmental information on the World Wide Web, such as NOAA, DOE, universities, and state governments will also be covered. Use of these resources will be demonstrated with basic, widely-available Internet tools. From list-mgr@ISI.EDU Wed Apr 12 06:56:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 07:56:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 07:56:05 -0700 Received: from MERCKX.GRAPHICS.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 07:56:03 -0700 Received: by merckx.graphics.cornell.edu (5.65/DEC-Ultrix/4.3) id AA16071; Wed, 12 Apr 1995 10:56:30 -0400 Message-Id: <9504121456.AA16071@merckx.graphics.cornell.edu> Received: by verdi.graphics.cornell.edu (1.37.109.8/16.2) id AA22966; Wed, 12 Apr 1995 10:56:27 -0400 From: Hurf Sheldon Subject: ATM Switch cost To: MBONE Date: Wed, 12 Apr 1995 10:56:27 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 515 Hi, We are trying to plan an ATM setup for research. I have seen ATM literate comments on the mbone list. Would those who know send me some ball park figures for something like an 8port ATM switch and atm cards for HP700 (eisa) & SGI IndigoII systems? Any reccommendations/caveats would be great, as well. thanks, Hurf -- Hurf Sheldon Network: hurf@graphics.cornell.edu Program of Computer Graphics Phone: 607 255 6713 580 Eng. Theory Center, Cornell University, Ithaca, N.Y. 14853 From list-mgr@ISI.EDU Wed Apr 12 17:10:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 08:12:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 08:11:49 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 08:11:47 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 12 Apr 1995 08:11:42 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Apr 1995 16:10:31 +0100 To: Hurf Sheldon Cc: MBONE Subject: Re: ATM Switch cost In-Reply-To: Your message of "Wed, 12 Apr 95 10:56:27 EDT." <9504121456.AA16071@merckx.graphics.cornell.edu> Date: Wed, 12 Apr 95 16:10:30 +0100 Message-Id: <2697.797699430@cs.ucl.ac.uk> From: Jon Crowcroft >We are trying to plan an ATM setup for research. I have seen >ATM literate comments on the mbone list. Would those >who know send me some ball park figures for something >like an 8port ATM switch and atm cards for HP700 (eisa) & SGI IndigoII >systems? Any reccommendations/caveats would be great, as well. >thanks, Hurf 50k dollars ought to get you an ASX200, and all the host cards necessary for the HP & SGI set up with a bit spare for maintenance etc meanwhile, Telecom Finalnd seem to think that IP is good enough for voice serices (see Comms Weekly Intl) so I'm not sure what ATM is good for:-) jon From list-mgr@ISI.EDU Thu Apr 13 10:01:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 09:04:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 09:04:02 -0700 Received: from daiduk.kaist.ac.kr by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 09:03:58 -0700 Received: from eldorado.kaist.ac.kr (eldorado.kaist.ac.kr [143.248.141.67]) by daiduk.kaist.ac.kr (8.6.10/KAIST_MX_Cheon) with SMTP id BAA13992 for ; Thu, 13 Apr 1995 01:05:30 +0900 Received: by eldorado.kaist.ac.kr (5.0/SMI-SVR4) id AA07798; Thu, 13 Apr 1995 01:01:12 --900 From: suh@eldorado.kaist.ac.kr (Bongsue Suh) Message-Id: <9504121601.AA07798@eldorado.kaist.ac.kr> Subject: subscribe To: MBONE Date: Thu, 13 Apr 1995 01:01:11 +0900 (KST) X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Content-Length: 40 Subscribe me, suh@eldorado.kaist.ac.kr From list-mgr@ISI.EDU Wed Apr 12 02:08:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 09:28:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 09:27:56 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 09:27:55 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 12 Apr 1995 09:10:47 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA03623; Wed, 12 Apr 95 09:08:12 PDT Date: Wed, 12 Apr 1995 09:08:11 -0700 (PDT) From: Michael Macedonia To: Dorrie Hall Cc: rem-conf@es.net, "MIT Walter A. Aviles" , mbone Subject: KRYPTON at MIT is jamming net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dorrie and anyone at MIT, You have a bad router thats sending tons of icmp messages to the I3DG symposium. Its krypton.mit.edu. We have a 40% loss because of it. Please find it and kill it or stop watching the symposium. Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From list-mgr@ISI.EDU Wed Apr 12 05:16:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 10:16:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 10:16:22 -0700 Received: from fsa.cpsc.ucalgary.ca by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 10:16:19 -0700 Received: from [136.159.220.111] (ryoken.nx.cpsc.ucalgary.ca [136.159.220.111]) by fsa.cpsc.ucalgary.ca (1.8) id ; Wed, 12 Apr 1995 11:10:29 -0600 X-Sender: franks@fsc.cpsc.ucalgary.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Apr 1995 11:16:14 -0600 To: Hurf Sheldon , MBONE From: franks@cpsc.ucalgary.ca (Steve Franks) Subject: Re: ATM Switch cost ATM cards for the SGI Indy and Indigo currently run about $2000 from Fore and Newbridge. These are OC3 cards, which are a bit of an overkill. We have actually got a Fore card for the Indy and a Sun, Newbridge says they will be shipping "Real Soon" At 10:56 AM 4/12/95, Hurf Sheldon wrote: >Hi, >We are trying to plan an ATM setup for research. I have seen >ATM literate comments on the mbone list. Would those >who know send me some ball park figures for something >like an 8port ATM switch and atm cards for HP700 (eisa) & SGI IndigoII >systems? Any reccommendations/caveats would be great, as well. >thanks, >Hurf > >-- > Hurf Sheldon Network: hurf@graphics.cornell.edu > Program of Computer Graphics Phone: 607 255 6713 > 580 Eng. Theory Center, Cornell University, Ithaca, N.Y. 14853 > -------------------------------------------------------------------------- Steve Franks - PGP Key Available @ http://www.cpsc.ucalgary.ca/~franks EMail: franks@cpsc.ucalgary.ca franks@ryoken.nx.cpsc.ucalgary.ca (Eudora Mail, source for this msg) From list-mgr@ISI.EDU Wed Apr 12 23:43:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 10:43:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 10:43:23 -0700 Received: from cs.tut.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 10:43:21 -0700 Received: from kaarne.cs.tut.fi (mit@kaarne.cs.tut.fi [130.230.3.2]) by cs.tut.fi (8.6.12/8.6.4) with ESMTP id UAA16788; Wed, 12 Apr 1995 20:47:02 +0300 From: Tsokkinen Mikko Received: (mit@localhost) by kaarne.cs.tut.fi (8.6.10/8.6.4) id UAA16601; Wed, 12 Apr 1995 20:43:09 +0300 Date: Wed, 12 Apr 1995 20:43:09 +0300 Message-Id: <199504121743.UAA16601@kaarne.cs.tut.fi> To: Jon Crowcroft Cc: MBONE Subject: Re: ATM Switch cost In-Reply-To: <2697.797699430@cs.ucl.ac.uk> References: <9504121456.AA16071@merckx.graphics.cornell.edu> <2697.797699430@cs.ucl.ac.uk> Jon Crowcroft writes: > meanwhile, Telecom Finalnd seem to think that IP is good enough for > voice serices (see Comms Weekly Intl) so I'm not sure what ATM is good > for:-) IP and ATM are not contradictionary in terms. Mikko I. Tsokkinen xxxxx Mit R & D Engineer Telecom Finland Ltd./Telegate/Medialaboratory "The universal language of the Net will be spoken 53 bytes at a time." - S.G.Steinberg From list-mgr@ISI.EDU Thu Apr 13 02:51:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 13:53:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 13:52:34 -0700 Received: from lohi.dat.tele.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 13:52:31 -0700 Message-Id: <199504122052.AA05837@venera.isi.edu> Received: from lohi.dat.tele.fi by lohi.dat.tele.fi id <29919-0@lohi.dat.tele.fi>; Wed, 12 Apr 1995 23:51:52 +0300 To: mit@cs.tut.fi Cc: J.Crowcroft@cs.ucl.ac.uk, MBONE In-Reply-To: <199504121743.UAA16601@kaarne.cs.tut.fi> (mit@cs.tut.fi) Subject: Re: ATM Switch cost Date: Wed, 12 Apr 1995 23:51:52 +0300 From: Juha Heinanen Sender: Juha.Heinanen@lohi.dat.tele.fi Jon Crowcroft writes: > meanwhile, Telecom Finalnd seem to think that IP is good enough for > voice serices (see Comms Weekly Intl) so I'm not sure what ATM is good > for:-) IP and ATM are not contradictionary in terms. jon, i would have not expected you to write this kind of comment. first, i have not seen the article, but the general rule is that editors don't ever get it right. stories are written to attract attention. the reason why we get good enough quality for voice is that we run IP over ATM on a dedicated VC. sure you may get the same with rsvp when it is someday implemented. ATM, however, has some additional advantages, that i'm not sure if you can ever get with router technology. one of them is scalability in terms of bandwidth and price. or can you give me a pointer who is selling 16 port OC3 sonet routers at $1k per port? well, i don't actually want to get into this depate any deaper than this. -- juha From list-mgr@ISI.EDU Wed Apr 12 12:55:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 13:56:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 13:56:23 -0700 Received: from titan.sprintlink.net by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 13:56:20 -0700 Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id QAA13439; Wed, 12 Apr 1995 16:55:51 -0400 Date: Wed, 12 Apr 1995 16:55:51 -0400 From: Vadim Antonov Message-Id: <199504122055.QAA13439@titan.sprintlink.net> To: J.Crowcroft@cs.ucl.ac.uk, mit@cs.tut.fi Subject: Re: ATM Switch cost Cc: MBONE > Jon Crowcroft writes: > > meanwhile, Telecom Finalnd seem to think that IP is good enough for > > voice serices (see Comms Weekly Intl) so I'm not sure what ATM is good > > for:-) > IP and ATM are not contradictionary in terms. They simply don't work together. Meanwhile, some people still believe that the Earth is flat. > Mikko I. Tsokkinen xxxxx Mit > R & D Engineer >"The universal language of the Net will be spoken 53 bytes at a time." > - S.G.Steinberg "Nobody will ever want more than 640K of memory". My quote beats yours, partially because the author managed to make obscene amount of money peddling his "vision". --vadim PS I also work for a telephone company. From list-mgr@ISI.EDU Thu Apr 13 17:13:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 18:15:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 18:15:08 -0700 Received: from iti.gov.sg ([160.96.25.10]) by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 18:15:05 -0700 Received: (from mailer@localhost) by iti.gov.sg (8.6.11/8.6.11) id JAA03239; Thu, 13 Apr 1995 09:19:55 +0800 Received: from unknown(192.122.132.130) by iti.gov.sg via smap (V1.3) id sma003235; Thu Apr 13 09:19:34 1995 Received: by iti.gov.sg (4.1/SMI-4.1) id AA15850; Thu, 13 Apr 95 09:14:11 SST Received: from unknown(192.122.133.25) by genesis via smap (V1.3mjr) id sma015816; Thu Apr 13 09:13:19 1995 Received: by capella.gov.sg (5.x/SMI-SVR4) id AA02349; Thu, 13 Apr 1995 09:13:16 +0800 Date: Thu, 13 Apr 1995 09:13:16 +0800 From: kslai@iti.gov.sg (Lai Kwai Seng) Message-Id: <9504130113.AA02349@capella.gov.sg> To: mbone, rem-conf@es.net, larettin@eos.ncsu.edu Subject: UNSUBSCRIBE X-Sun-Charset: US-ASCII UNSUBSCRIBE From list-mgr@ISI.EDU Thu Apr 13 20:44:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 19:50:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 19:49:44 -0700 Received: from fgwmail.fujitsu.co.jp by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 19:49:40 -0700 Received: from fdmmail.fujitsu.co.jp by fgwmail.fujitsu.co.jp (8.6.12+2.4W/3.3W5-MX941209-Fujitsu Mail Gateway) id LAA00781; Thu, 13 Apr 1995 11:49:26 +0900 Received: from pfrad.pfu.fujitsu.co.jp by fdmmail.fujitsu.co.jp (8.6.12+2.4W/3.3W5-MX950127-Fujitsu Domain Mail Master) id LAA19029; Thu, 13 Apr 1995 11:48:54 +0900 Received: by pfrad.pfu.fujitsu.co.jp (4.12/6.4J.6-PFU-2.0) id AA01400; Thu, 13 Apr 95 11:51:24 JST Received: by minami.trad.pfu.fujitsu.co.jp (5.0/6.4J.6-PFU-2.0) id AA01110; Thu, 13 Apr 1995 11:44:55 --900 Message-Id: <9504130244.AA01110@minami.trad.pfu.fujitsu.co.jp> To: mbone Subject: UNSUBSCRIBE Date: Thu, 13 Apr 1995 11:44:52 +0900 From: liyuekai Content-Length: 14 UNSUBSCRIBE From list-mgr@ISI.EDU Thu Apr 13 20:03:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 21:04:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 21:03:56 -0700 Received: from sunstation2.tsinghua.edu.cn ([166.111.8.10]) by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 12 Apr 1995 21:03:51 -0700 Received: from csnet4.tsinghua.edu.cn ([166.111.166.17]) by sunstation2.tsinghua.edu.cn (4.1/SMI-4.1) id AA04102; Thu, 13 Apr 95 12:02:11 CDT Received: by csnet4.tsinghua.edu.cn (5.0/SMI-SVR4) id AA00600; Thu, 13 Apr 1995 12:03:43 --800 Date: Thu, 13 Apr 1995 12:03:43 --800 From: wsg@csnet4.tsinghua.edu.cn (Wu Shangguang) Message-Id: <9504130303.AA00600@csnet4.tsinghua.edu.cn> To: mbone Subject: UNSUBSCRIBE X-Sun-Charset: US-ASCII Content-Length: 12 UNSUBSCRIBE From list-mgr@ISI.EDU Thu Apr 13 12:38:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 03:46:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 03:44:49 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 03:44:48 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 13 Apr 1995 03:40:22 -0700 Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Apr 1995 11:38:34 +0100 To: Tsokkinen Mikko Cc: MBONE Subject: Re: ATM Switch cost In-Reply-To: Your message of "Wed, 12 Apr 95 20:43:09 +0200." <199504121743.UAA16601@kaarne.cs.tut.fi> Date: Thu, 13 Apr 95 11:38:29 +0100 Message-Id: <2174.797769509@cs.ucl.ac.uk> From: Jon Crowcroft > > meanwhile, Telecom Finalnd seem to think that IP is good enough for > > voice serices (see Comms Weekly Intl) so I'm not sure what ATM is good > > for:-) >IP and ATM are not contradictionary in terms. Mikko 1. ATM has a cell size aimed at carry ing CBR voice from legacy telephone exchanges to avoid a switching time across a typical number of switches that would introduce a delay so large as to make echo cancellors necessary on all such ATM interconnected exchanges. if you put aan IP header i nthe packet, you break this design 'feature' by causing the switchign time to increase if you switch the IP packet thru ordinary routers, you make it worse => contradiction #1 2. if you have actually tried running IP over ATM nets in the large, you will find that there are a number of problems i nthe mismatch of circuit and datagram services, and variable size packets and shredding these into tiny cells, and more subltelly, between the basic model of service most _large_ ATM switches actually give (e.g. Peak Cell Rate policing, or requireing the application, transport user to state a CDV preference, neither of which means much to the average FTP, X, NFS, HTTP, or even mbone user) - the requirement for a circuit of a QoS to be established below a datagram service (even when one day it will have RSVP and IP6 flowids) is contrary to the basic premise that a) most the time there is enough bandwidth, therefore a call setup wastes time more often than it saves time b) large distributed applications have to be fault tolerant. making their fault tolerance depend on so-cal;led reliable virtual circuits doesn't work in practice (the circuits have independent failure modes) and just means that they have to take accoutn of new failure modes (e.g circuit failures need to cause the applcaiton to request a nerw circuit) whic hleads to added complexity in the applcation, which leads to lower reliability and performance => contradiction #2, #3, #4... 3. WWW traffic patters fit none of the design expectations of ATM nets => contradiction #n attached is a report on 1 tiny bit of work we did trying to use ATM with non toy/LAN switches....sure it worked, but if we'd just glued our Cisco 7000s together with 34Mbps point to point links, it would have worked a whole lot quicker, better etc etc.. When the PNNI spec and the full service spec for UNI 4 are out, this may be a bit better....but i wouldn't hold your breath:-) cheers sorry for those who've seen the report before... jon --------------------------------------------------------- this report contains some hypotheses which are not scientifically proven since it is based on partly anecodotal evidence of what configurations were in place when and where. nevertheless, i believe that given the evidence, it is a reasoanble description of what may have been going on. we are going to conduct a series of controlled experiments over the next few months to establish really what was happening in detail (using a couple of HP broadband analysers, as tcpdump doesn't work on an SDH 155Mbps fiber link between two ATM switches yet:-) this is not for wider circulation yet, as we need to check it with BT ... but since their side of the network appears to have operated very well, i doubt they will block this ... there's nothing deep here - its all just what you can actually do now... any comments will be most welcome, especially on experiements you might like to see done.... cheers jon ----------------- Experiences with IP & ATM on the European PNO Pilot: Shaping and Policing. Jon Crowcroft, Anne Hutton, Mark Handley, Stuart Clayman In the Internet, there are 3 basic traffic patterns from applications that cause significant traffic loads: 1/ TCP over IP [FTP, HTTP etc] 2/ UDP over IP [NFS, DNS] 3/ RTP (over UDP) over IP [Mbone applications: vic/vat/wb] Traffic as seen at the IP layer: TCP applications are reactive. They can expand to use whatever bandwidth is available. They backoff when bandwidth decreases as soon as they learn - they learn through detection of lost packets. TCP generally has variable, but not particularly bursty traffic patterns. After loss, TCP recovers well if the aggregate buffering in the network is around the famous 'bandwidth*delay product' needed to not let the "pipe drain". UDP based applications do not back off, and typically are massively bursty - NFS for instance sends (by default) 8K of data in a single request or response, and this will be typically as fast as the source can send. Both UDP and TCP usually use the MTU as seen at the host interface for local traffic, and a default otherwise - this can be around 512 bytes (but is settable). RTP applications are _mainly_ smooth, and relatively steady. VAT sends audio, typically at just over 64kbps and at 140 byte packets. With silence supression on, vat is a classic "on/off" source. Vic sends video, and is more variable, but still has a mean and peak, though the packet size varies (from around 100-700 bytes). Traffic as seen at the ATM layer: IP is encapsulated at source in AAL5 frames, which are then shredded into 48 byte payloads. Without any source "rate control", these will be sent at line rate. Thus a single IP packet of 700 bytes, for example, results in 15 cells at line speed. Depending on whether the host adaptor does this shredding directly from host memory, or else dma's first to buffers on the card, there may be speed coupling problems here. If the source host rate limits within a VC, then the cells will be sent at the rate set, and so long as the layer above, the IP source, and the layer above that (TCP, UDP or RTP) don't exceed the rate, buffers won't be exhausted, and cell loss will not be experienced. If the rate control is not accurate, or else is above the rate of the slowest link in the path from source adaptor to sink, then there is a high chance that even if the source application is "well behaved" the cell rate for the bottleneck is exceeded temporarily, unless there is shaping. Shaping is basically the use of buffers to trade jitter for delay - as cells arrive more closely (i.e. the temporary cell rate is higher than the mean or even peak, up to some number of cells) they are stored for slightly longer intervals that their interarrival times, and slowly "leaked" out to the net at the appropriate rate. Basically, the scheduling of cells is done by varying the delay between them - this can be done at source or in intermediate switches. If done at source, it requires global knowledge of bottlenecks. If done in switches, it can be done at the edges of bottlenecks only. This will work well for RTP based applications provided that the buffering is AT LEAST the IP packets worth of cells, and probably somewhat more, and the VC at the bottleneck is set to peak rate the same as the peak RTP rate. For TCP, you actually want less long term buffering, but more short term buffering - you want _exactly_ the IP MTU's worth of ATM cell payloads of buffering, and you really want the source (ideally source/entry switch, but failing that, end system) to rate control explicitly at the bottleneck speed. If not, you want _immediate_ loss at the bottleneck switch, as this will cause the source TCP to adjust its rate anyhow, leaving only 1 IP packetsworth' of play. With DNS and NFS, there is no obvious solution. Basically, ATM is unsuited to bursty transaction oriented traffic, full stop. [NFS _can_ be run over TCP if need be, then the rules above apply]. Of course, the problem is that at the IP level, you can't trivially tell which packets are TCP and which RTP, so there is a conflict in how to configure the hops in source adaptor and the switches... In any case, no amount of shaping will help TCP, though without it, you also have no chance of making it work. What is required there is, as stated above, adequate (large, in terms of most ATM switch designers' views so far) buffering in the ATM switch, unless you take the approach described next. [Note that simple buffering in the ATM switch does not amount to shaping: that depends on the queueing discipline serving the buffer onto the output ports. For example, it would be perfectly possible under non-overload conditions, albeit perverse, to maintain arrival timing in output, simply introducing a delay all the time of the worst case traffic delay. Shaping implies some concious design for a particular change between inter-arrival and inter-departure times for cells.] However, all is not lost, as one can take an alternate approach: If we connect hosts via conventional networks to routers, and the routers via ATM, then the routers can aggregate traffic from many sources over the ATM "cloud". Then the solution may be different - for example, a VP between routers with mean=peak, and peak policing only, will behave just like a physical circuit for IP, which would suit TCP traffic ok. Efficient TCP loss recovery then depends on the buffering in the router, rather than in the switch. What you lose then is the benefit of ATM guarantees for the RTP based traffic. One possible solution would be to run RTP from hosts with ATM adaptors direct ('native') and all other IP traffic via routers. In the PNO pilot, it would appear that only the router approach works right now, since the host adaptors most people are using do not do rate control (pacing) properly, so even the small bursts of an IP packets worth can overrun some hop or other where there is an impedence mismatch. The PNO Configurations for the G7 Demonstration, 24-26/2/95 We tried a number of different configurations for access to the PNO pilot for the G7 demo. Applications: THe requirement was for 4 countries to run the MICE applications. In this case, these were IVS for video and audio and wb for shared whiteboard. We did make some use of Vic and Vat as alternative Video and Audio tools while setting things up, as well as the usual diagnostic tools, ping, traceroute and TTCP during the configuration work. However, the bulk of our traffic was a) RTP on UDP on IP b) Multicast Topology: RUS to London was provided by SMDS, seemlessly, between the German SMDS net and the SuperJANET SMDS network, using Interworking units to make the PNO ATM hop simply connect the two SMDS areas. This worked very well after initial teething problems (the German and UK ends are different technology). For the others, French and Belgian and UK PNO access was direct to the Pilot switches. The connectivity requirements from the applications were to have multipoint IP between INRIA at Sophia Antipolis and Grenoble, Brussels, RUS and UCL/London. The PNO does not as such provide point-multipoint ATM VPs. This still left a number of possibilities for where to place the fanout. Each site would have an "Mbone" router, typically a Sun with ether or FDDI, and an ATM card. Each site also has an access ATM switch, and an access line (typically 155 Mbps SDH) to the PNO national switch. All sites also had routers with ATM adaptors. The PNO switches are cross-connected by 34Mbps (i.e. E3) PDH links. The VPs configured for us were peak cell rate (PCR) 1Mbps, mean cell rate 1 Mbps. Given experience with the applications on E1 and T1 lines, this should have been generous. The UK node is capable of more sophisticated policing as it supports dual egress buffers, bu as symmetry was preferred for the configuration for the MICE tools in use for the G7 demonstration, this was not enabled. The Mbone router would forward IP traffic from the site IP networks across the PNO "cloud", replicating packets to all the other Mbone routers, and thence onto the receiver IP hosts at all sites. The Mbone router could be connected to the PNO cloud in several different ways: 0/ "Mbone" routers attached to the PNO switches. Rukled out because of lack of a tested PNO point-multipoint VP service. 1/ Mbone routers attached to site switches. If all the sites possessed Fore ASX200s, we could have made use of a set of VPs on the PNO switches to provide a point-multipoint ATM configuration. The Mbone routers would then simply connect to the site switch via ATM host adaptors. We ruled this out as too experimental at this late stage: Point-multipoint ATM support of IP in general is in very early development. 2/ Mbone routers attached to PNO, or site switches with many point-to-point ATM VCs to each and every other Mbone router - this seemed most promising in terms of matching bandwidth and topology. However, in terms of traffic shaping and policing, it is a bit of an unknown. 3/ Mbone routers attached to site routers, which are in turn attached to the PNO switches via many point-to-point VCs. This was the final working configuration. Traffic Shape Requirement Clearly, there are two major speed mismatches in the configuration at the join between national access and the International connections: i) The line speed goes from 155Mbps to 34Mbps (i.e. there is a VC from an input port on the PNO switch to an output port with these speeds). It is not clear that at sauch a low speed, this is a problem i nthis case. ii) The actual VC configured was PCR 1 Mbps. There was another mismatch at the site hosts (Mbone routers) and site switches - most our access adaptors are 100Mbps TAXI. Results with ATM LAN Sources.(i.e. 1) We were able to establish ATM connectivity, and get pings through, but performance was not good. We had hoped that shaping of cells output from the ASX200 switches would help smooth the cell bursts to conform to the PNO VP configuration. It would appear that this is not implemented in the current software generation, though Fore report that the hardware can do this and future releases will make use of this. Results with ATM Source Hosts. (i.e. 2) As with site switches, the host adaptors were not much better at shaping the traffic to within the PNO's policing requirements. We had hoped that we could use the inter-cell spacing parameter available in the Fore SBA200 through the latest driver (2.3), but this did not have enough effect. Specifying the PCR for the VC in the SBA200 did not appear to affect the intercell spacing very much (and setting it very low caused the sending host to lose cells inside the adaptor!). Results with IP Routers at the ATM Bottleneck. This was what finally worked. The shaping from the output port on the site Cisco 7000 routers' ATM adaptors appeared to just about do the right thing in terms of not overruning the input buffers on the PNO switches. However, interposing a router that has good output smoothing directly at the lowest speed hop (the bottleneck) also allowed higher level smoothing. If the output queue from the Cisco to the VC to the PNO switch was blocked, it could buffer very large numbers of IP packets. This would permit extremely bursty source behaviour. Here was the Cisco Configuration that worked: --------------------------------------------------------------- interface ATM2/0 no ip address atm rate-queue 0 2 atm rate-queue 1 2 ! .... ! interface ATM2/0.2 multipoint ip address 194.36.80.254 255.255.255.0 map-group atm-mice-trial /* peak rate = 2000 Kbits/s average rate = 1000 Kbits/s max burst size = 1 * 32 cells */ atm pvc 3 32 57 aal5mux ip 2000 1000 1 /* INRIA : VPI/VCI = 32/57 */ atm pvc 5 30 57 aal5snap 2000 1000 1 /* Brussels : VPI/VCI = 30/57 */ ! .... ! map-list atm-mice-trial ip 194.36.80.252 atm-vc 5 /* Brussels Cisco */ ip 194.36.80.253 atm-vc 3 /* INRIA Cisco * --------------------------------------------------------------- Burstiness Measures In theory, RTP/UDP/IP sources from capture devices such as a Sun Sparc audio or SunVideo card can be made to provide fairly smooth IP packet rates (although, as we've said, without inter-cell spacing, the cell rate 'within' an IP packet is typically at or near output adaptor's line rate). However, measurements of the Inter-packet arrival times from IVS, VIC and Vat show that there are still a small number of 'back-to-back' IP packets generated. There are three reasons for this: 1/ Scheduling in the application. We are not using real-time operating systems to run out applications. It is possible for an application to generate a packet, get de-scheduled, get re-scheduled, send the first packet and generate and send the 2nd right away. Obviously, the probability of this happening for 3 or more packets decreases approximately exponentially, and that is roughly what we see for VAT. 2/ For IVS, there appears to be a bug that causes generation of more than the expected number of back to back packets. 3/ A source machine may be running multiple applications, thus packets from different applications might get sent together. Conclusions IP multicast over ATM is both feasible, and probably an attractive way to provide higher bandwidth to many organisations around Europe. The state of ATM is such that it is not manageable to make the traffic management or VC/VP management visible to sites or end systems. Signaling is immature. Policing is excellent, but traffic shaping is completely inadequate in current state-of-the-art switches for IP traffic, even modestly bursty traffic. However, traffic shaoping from at least one vendor's IP routers with ATM appears to be adequate (albeit a little wasteful of bandwidth). It also offers the possibility of future exploitation of integrating IP multicast in native routers and of utilising point-multipoint VPs on the PNO pilot, which would lead to a large increase in efficiency. ------------------------------------------------------------- Acknowledgements Thanks to BT, ISD and INRIA. ----------------------------------- References A. Romanow and S. Floyd, ftp://playground.sun.com/pub/tcp_atm/tcpatm_dyn.03.ps.Z Dynamics of TCP traffic over ATM networks," see also 6th IEEE LAN/MAN Workshop, 1993. A. Romanow, ftp://playground.sun.com/pub/tcp_atm/tcp_forum.7_93.ps.Z TCP over ATM: Some performance results, Contribution to ATM Forum, Traffic Management Sub-Working Group (ATM Forum 93-784), July 1993. S. Floyd and V. Jacobson, "Traffic phase effects in packet-switched gateways," ACM Computer Communication Review, vol. 21, no. 2, pp. 26--42, 1991. S. Floyd and V. Jacobson, "Random early detection gateways for congestion avoidance," IEEE/ACM Transactions on Networking, vol. 1, pp. 397--413, Aug. 1993 S. Floyd and V. Jacobson, ftp://ftp.ee.lbl.gov/papers/sync.ps.Z The synchronization of periodic routing messages in SIGCOMM Symposium on Communications Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, California), pp. 33--44, ACM, Sept. 1993. S. Floyd, ftp://ftp.ee.lbl.gov/papers/slides_92.ps Issues in flexible resource management for datagram networks in Proceedings of the Third Workshop on Very High Speed Networks, (Maryland), IEEE, Mar. 1992. S. Floyd, ftp://ftp.ee.lbl.gov/papers/link.ps.Z Link-sharing and resource management models for packet networks, unpublished memorandum, Sept. 1993. V. Paxson and S. Floyd, ftp://ftp.ee.lbl.gov/papers/poisson.ps.Z Wide-area traffic: the failure of Poisson modeling, in SIGCOMM Symposium on Communications Architectures and Protocols>, (London, United Kingdom), pp. --, ACM, Aug. 1994. C. Villamizar and C. Song, ftp://ftp.ans.net/pub/papers/tcp-performance.ps High performance TCP in ANSNET, technical note, Advanced Network & Services, Inc. (ANSNET), Sept. 1994. G. J. Armitage and K. M. Adams, "Packet reassembly during cell loss," IEEE Network, vol. 7, pp. 26--34, Sept. 1993. C. E. Bagwell and J. N. Daigle, "ATM cell delay and loss for best-effort TCP in the presence of isochronous traffic," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (Toronto, Canada), June 1994. R. Caceres, ftp://tenet.berkeley.edu/pub/tenet/Papers/Caceres91b.ps Efficiency of asynchronous transfer mode networks in transporting wide-area data traffic, technical report, UC Berkeley, 1991. J. D. Cavanaugh, ftp://ftp.magic.net/pub/magic/overhead.ps Protocol overhead in IP/ATM networks, tech. rep., Minnesota Supercomputer Center, Aug. 1994. K. C. Claffy, H.-W. Braun, and G. C. Polyzos, ftp://ftp.sdsc.edu/pub/sdsc/anr/papers/flows.ps.Z Internet traffic flow profiling, submitted for publication, Mar. 1994. D. E. McDysan and M. E. Conn, Key issues in transporting TCP/IP over public data networks, in Proceedings of the International Networking Conference (INET), (San Francisco, California), pp. CDD--1 -- CDD--9, Internet Society, Aug. 1993. A. Wolman, G. Voelker, and C. A. Thekkath, "Latency analysis of TCP on ATM network," in Proceedings of the Winter USENIX Conference, (San Francisco, California), pp. 167--179, Usenix, Jan. 1994. L. Wei, F. Liaw, D. Estrin, A. Romanow, and T. Lyon, "Analysis of a resequencer model for multicast over ATM networks," in Third International Workshop on network and operating system support for digital audio and video, (San Diego, California), pp. 197--208, IEEE Communications Society, Nov. 1992. B. Braden, D. Clark, and S. Shenker, ftp://ds.internic.net/internet-drafts/draft-braden-realtime-outline.00.txt Integrated services in the Internet architecture: an overview Internet Draft, USC-ISI, Oct. 1993. Work in progress. R. Braden, D. Clark, and S. Shenker, ftp://ds.internic.net/rfc/rfc1633.txt Integrated services in the internet architecture: an overview. Request for Comments (Informational) RFC 1633, Internet Engineering Task Force, June 1994 E. Cooper, O. Menzilcioglu, R. Sansom, and F. Bitz, "Host interface design for ATM LANs," in IEEE Conference on Local Computer Networks, (Minneapolis, Minnesota), pp. 247--258, IEEE, Oct. 1991. I. Leslie and D. McAuley, "Fairisle: an ATM network for the local area," in SIGCOMM Symposium on Communications Architectures and Protocols (Zurich, Switzerland), pp. 327--336, ACM, Sept. 1991. From list-mgr@ISI.EDU Thu Apr 13 12:46:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 03:49:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 03:47:15 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 03:47:14 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 13 Apr 1995 03:47:10 -0700 Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Apr 1995 11:46:35 +0100 To: Juha Heinanen Cc: mit@cs.tut.fi, MBONE Subject: Re: ATM Switch cost In-Reply-To: Your message of "Wed, 12 Apr 95 23:51:52 +0200." Date: Thu, 13 Apr 95 11:46:33 +0100 Message-Id: <2228.797769993@cs.ucl.ac.uk> From: Jon Crowcroft > Jon Crowcroft writes: > > meanwhile, Telecom Finalnd seem to think that IP is good enough for > > voice serices (see Comms Weekly Intl) so I'm not sure what ATM is good > > for:-) > IP and ATM are not contradictionary in terms. >i would have not expected you to write this kind of comment. first, i >have not seen the article, but the general rule is that editors don't >ever get it right. stories are written to attract attention. well, you sure got attention - i was simply reporting the article for those who might want to seek it out and read it. If you don't think they got it right, issue a telecom finland formal press release on what you are actually doing. >the reason why we get good enough quality for voice is that we run IP >over ATM on a dedicated VC. sure you may get the same with rsvp when it >is someday implemented. ATM, however, has some additional advantages, >that i'm not sure if you can ever get with router technology. one of >them is scalability in terms of bandwidth and price. or can you give me >a pointer who is selling 16 port OC3 sonet routers at $1k per port? can you buy 10Mbps host adaptors for 50 pounds? >well, i don't actually want to get into this depate any deaper than this. why not? if you are using dedicated atm between phone exchanges (i.e. you do NOT break out in to the actual internet) why on earth are you wasting bandwidth putting IP headers (and presumably UDP and RTP) in the voice samples......? ATM has 2 legitamate goals. 1 is interconenctio nof legacy phone exxhcnages at 64kbps CBR, the other is as managed shared backbone between switch-routers (possibly with RSVP to the routers, and Q.2931 between the routers to let the end systems access the QoS control, and save the routers having to implement fancy queueing directly...but rely simply on the cell based shapers/buffers and policers....maybe...) what the article implied you were doing was neither of these, but if it was the use of the mbone to do away with settlement based interconnects of telephony nets, rather than the dedicated VC setup you desribe, i would quite understand the point....but you seem to imply it isn't so....? puzzled.... jon From list-mgr@ISI.EDU Thu Apr 13 19:26:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 06:22:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 06:22:15 -0700 Received: from cs.tut.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 06:22:11 -0700 Received: from isosotka.cs.tut.fi (mit@isosotka.cs.tut.fi [130.230.17.14]) by cs.tut.fi (8.6.12/8.6.4) with ESMTP id QAA29680; Thu, 13 Apr 1995 16:26:03 +0300 From: Tsokkinen Mikko Received: (mit@localhost) by isosotka.cs.tut.fi (8.6.10/8.6.4) id QAA09010; Thu, 13 Apr 1995 16:26:25 +0300 Date: Thu, 13 Apr 1995 16:26:25 +0300 Message-Id: <199504131326.QAA09010@isosotka.cs.tut.fi> To: Jon Crowcroft Cc: MBONE Subject: Re: ATM Switch cost In-Reply-To: <2174.797769509@cs.ucl.ac.uk> References: <199504121743.UAA16601@kaarne.cs.tut.fi> <2174.797769509@cs.ucl.ac.uk> Jon Crowcroft writes: > > > meanwhile, Telecom Finalnd seem to think that IP is good enough for > > > voice serices (see Comms Weekly Intl) so I'm not sure what ATM is good > > > for:-) > >IP and ATM are not contradictionary in terms. > > 1. > ATM has a cell size aimed at carry ing CBR voice from legacy > telephone exchanges to avoid a switching time across a typical number > of switches that would introduce a delay so large as to make echo > cancellors necessary on all such ATM interconnected exchanges. > > if you put aan IP header i nthe packet, you break this design > 'feature' by causing the switchign time to increase > > if you switch the IP packet thru ordinary routers, you make it worse [cut cut cut] I cannot see what is the point you are trying to make. Are you trying to say that IP cannot be run over ATM efficiently in any case, or since telephone services can be implemented on top of IP, ATM has no use, or something else? Mikko I. Tsokkinen xxxxx Mit From list-mgr@ISI.EDU Thu Apr 13 15:34:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 06:35:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 06:35:18 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 06:35:17 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 13 Apr 1995 06:35:16 -0700 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Apr 1995 14:34:38 +0100 To: Tsokkinen Mikko Cc: MBONE Subject: Re: ATM Switch cost In-Reply-To: Your message of "Thu, 13 Apr 95 16:26:25 +0200." <199504131326.QAA09010@isosotka.cs.tut.fi> Date: Thu, 13 Apr 95 14:34:34 +0100 Message-Id: <671.797780074@cs.ucl.ac.uk> From: Jon Crowcroft >Are you trying to say that IP cannot be run over ATM efficiently in >any case, or since telephone services can be implemented on top of IP, >ATM has no use, or something else? it isn't very complicated: telephone services over IP over ATM cannot be run efficiently mbone and other Internet applications can be run efficiently over iP and not over ATM or over IP over ATM telephone services can be run efficiently over ATM directly, since it was designed that way. ok? jon if you like, you can come on our MSc in Telecommuncaitons, or our MSc in Data Networksd and Distributed SYstems, or even do a Masters by research in telecommunciations, and be taught by at least 2 professors who used to direct optical and ATM research at British Telecom....:-) From list-mgr@ISI.EDU Thu Apr 13 19:56:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 07:00:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 07:00:08 -0700 Received: from lohi.dat.tele.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 06:57:27 -0700 Message-Id: <199504131357.AA06091@venera.isi.edu> Received: from lohi.dat.tele.fi by lohi.dat.tele.fi id <09998-0@lohi.dat.tele.fi>; Thu, 13 Apr 1995 16:56:45 +0300 To: J.Crowcroft@cs.ucl.ac.uk Cc: mit@cs.tut.fi, MBONE In-Reply-To: <2228.797769993@cs.ucl.ac.uk> (J.Crowcroft@cs.ucl.ac.uk) Subject: Re: ATM Switch cost Date: Thu, 13 Apr 1995 16:56:45 +0300 From: Juha Heinanen Sender: Juha.Heinanen@lohi.dat.tele.fi jon, i still have not seen the article and looks like i don't even want to see it. we are definitely not connecting pbxes or telephone exchanges over IP/ATM. we simply have an ISDN/Internet gateway that allows IP hosts to place and receeive phone calls. if the IP hosts happens to sit on ATM, it uses a dedicated VC to the gateway and the result is much better than over the growded router network that can't provide any QoS. i'm sorry if that application offended you as an example of IP misuse. we simply did what one of our customers was asking for, since they didn't understand why they still would need both the phone and the terminal on their desk, if the terminal is connected to ATM. -- juha From list-mgr@ISI.EDU Thu Apr 13 06:12:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 07:13:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 07:12:40 -0700 Received: from mail06.mail.aol.com by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 07:12:39 -0700 Received: by mail06.mail.aol.com (1.37.109.11/16.2) id AA271542357; Thu, 13 Apr 1995 10:12:37 -0400 Date: Thu, 13 Apr 1995 10:12:37 -0400 From: JDaly0817@aol.com Message-Id: <950413101236_81817608@aol.com> To: mbone Subject: UNSUBSCRIBE UNSUBSCRIBE From list-mgr@ISI.EDU Thu Apr 13 20:08:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 07:11:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 07:11:03 -0700 Received: from lohi.dat.tele.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 07:10:51 -0700 Message-Id: <199504131410.AA06467@venera.isi.edu> Received: from lohi.dat.tele.fi by lohi.dat.tele.fi id <10088-0@lohi.dat.tele.fi>; Thu, 13 Apr 1995 17:08:23 +0300 To: J.Crowcroft@cs.ucl.ac.uk Cc: mit@cs.tut.fi, MBONE In-Reply-To: <671.797780074@cs.ucl.ac.uk> (J.Crowcroft@cs.ucl.ac.uk) Subject: Re: ATM Switch cost Date: Thu, 13 Apr 1995 17:08:23 +0300 From: Juha Heinanen Sender: Juha.Heinanen@lohi.dat.tele.fi jon, mbone and other Internet applications can be run efficiently over iP and not over ATM or over IP over ATM i agree that there is the cell header overhead that you have to pay if you run IP over atm, but otherwise i don't understand your point. may be you are reffering to the current ATM products that in many casds are not a very good match for IP. however, if you implementr fair queueing along with early frame drop, i can't see why it would be a worse solution for IP than the current fifo based routers. looks like i coudn't resist to get rid of this debate. -- juha From list-mgr@ISI.EDU Thu Apr 13 16:23:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 07:25:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 07:24:50 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 07:24:49 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 13 Apr 1995 07:24:48 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Apr 1995 15:23:39 +0100 To: Juha Heinanen Cc: mit@cs.tut.fi, MBONE Subject: Re: ATM Switch cost In-Reply-To: Your message of "Thu, 13 Apr 95 17:08:23 +0200." Date: Thu, 13 Apr 95 15:23:35 +0100 Message-Id: <1019.797783015@cs.ucl.ac.uk> From: Jon Crowcroft >not a very good match for IP. however, if you implementr fair queueing >along with early frame drop, i can't see why it would be a worse >solution for IP than the current fifo based routers. yes, we are now in 100% agreement - you can make an ATM switch who'se cell forwarding is a good match for the range of IP traffic flows, probably.....->p.s. but you've still lost dynamic routing and efficient multicast (now you'll tell me that the PNNI spec will had these in soon....:-) jon p.s. although it is not certainly that AAL matched cell discard policies will be perfect - there are stil lopportunities for weird traffic phase effects that could cause consistent lock out of a particular IP or other AAL5 based flow... you have to keep a lot of state in the early frame/cell discard to make sure you do it to different frames flows each round, so you don't just keep losing a diferent cell in the overal IP packet each time its retransmitted.....or another frame from the same flow is sent when a switch is congested, it drops a cell at random. but this leads to the rest of the cells in a frame being discarded....now if soruces have different frame sizes (or adapt them along with frame rate, depending on the perceived loss), you can get unfairness...unless the switch keeps track of the frame rate, frame size distribution and so on....as well as the cell rate and CDV etc... basically, you end up implementng an IP6 int-serv router that operates inside an ATM switch.. From list-mgr@ISI.EDU Thu Apr 13 08:01:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 09:03:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 09:02:54 -0700 Received: from titan.sprintlink.net by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 09:02:52 -0700 Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id MAA15763; Thu, 13 Apr 1995 12:01:51 -0400 Date: Thu, 13 Apr 1995 12:01:51 -0400 From: Vadim Antonov Message-Id: <199504131601.MAA15763@titan.sprintlink.net> To: J.Crowcroft@cs.ucl.ac.uk, Juha.Heinanen@lohi.dat.tele.fi Subject: Re: ATM Switch cost Cc: MBONE, mit@cs.tut.fi In the real life cost of long-distance lines far outweights the cost of switches/routers. So, 30% of T-3 capacity in the real life is a lot more than $40k difference in switch-router price (if you count yearly expenses). Don't also forget that unlike cost of routers cost of links is recurring. ATM makes sense (economically, not technically) for people who purchase it from telcos for subsidized rates, and with bandwidth overcommittment on the backbone (which is to say ATM does not handle well). For telcos ATM is a pure loss. If you can't see why IP over ATM does not work well you probably should read relevant papers on cooperative congestion control and think about how it works in cell-based networks with big bandwidth*delay product. --vadim jon, mbone and other Internet applications can be run efficiently over iP and not over ATM or over IP over ATM i agree that there is the cell header overhead that you have to pay if you run IP over atm, but otherwise i don't understand your point. may be you are reffering to the current ATM products that in many casds are not a very good match for IP. however, if you implementr fair queueing along with early frame drop, i can't see why it would be a worse solution for IP than the current fifo based routers. looks like i coudn't resist to get rid of this debate. -- juha From list-mgr@ISI.EDU Thu Apr 13 09:09:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 10:11:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 10:11:16 -0700 Received: from PO8.ANDREW.CMU.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 10:11:12 -0700 Received: (from postman@localhost) by po8.andrew.cmu.edu (8.6.9/8.6.9) id NAA08974 for mbone@ISI.EDU; Thu, 13 Apr 1995 13:11:00 -0400 Received: via switchmail; Thu, 13 Apr 1995 13:10:57 -0400 (EDT) Received: from pcs17.andrew.cmu.edu via qmail ID ; Thu, 13 Apr 1995 13:09:10 -0400 (EDT) Received: from pcs17.andrew.cmu.edu via qmail ID ; Thu, 13 Apr 1995 13:09:08 -0400 (EDT) Received: from mms.4.170.Jan.26.1995.20.06.54.sun4c.411.MacMail.5.2.CUILIB.3.45.SNAP.NOT.LINKED.pcs17.andrew.cmu.edu.sun4m.412 via MS.5.6.pcs17.andrew.cmu.edu.sun4c_411; Thu, 13 Apr 1995 13:09:07 -0400 (EDT) Message-Id: Date: Thu, 13 Apr 1995 13:09:07 -0400 (EDT) From: Ashish Bisarya To: mbone Subject: UNSUBSCRIBE Cc: UNSUBSCRIBE From list-mgr@ISI.EDU Fri Apr 14 06:00:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 17:02:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 17:01:41 -0700 Received: from cs.tut.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 17:01:38 -0700 Received: from kaarne.cs.tut.fi (root@kaarne.cs.tut.fi [130.230.3.2]) by cs.tut.fi (8.6.12/8.6.4) with ESMTP id DAA05874; Fri, 14 Apr 1995 03:05:30 +0300 From: Tsokkinen Mikko Received: (mit@localhost) by kaarne.cs.tut.fi (8.6.10/8.6.4) id DAA05792; Fri, 14 Apr 1995 03:00:29 +0300 Date: Fri, 14 Apr 1995 03:00:29 +0300 Message-Id: <199504140000.DAA05792@kaarne.cs.tut.fi> To: Jon Crowcroft Cc: MBONE Subject: Re: ATM Switch cost In-Reply-To: <2228.797769993@cs.ucl.ac.uk> References: <2228.797769993@cs.ucl.ac.uk> Jon Crowcroft writes: > >Are you trying to say that IP cannot be run over ATM efficiently in > >any case, or since telephone services can be implemented on top of IP, > >ATM has no use, or something else? > >it isn't very complicated: >telephone services over IP over ATM cannot be run efficiently It depends on what you are comparing it to and how you define "efficient". >mbone and other Internet applications can be run efficiently over iP and >not over ATM or over IP over ATM Is mbone implementation where workstations waste processing time doing work of routers and where all traffic is sent to everywhere whether somebody is listening or not (unless you happen to have just the right kind of workstation with certain os revision) efficient? Is sending uncompressed ascii documents within IP packets in http efficient? In the future these services can be implemented more efficiently, the same goes for workstation phone services over ATM. In some references Internet is defined as networks using IETF protocols, probably they run most efficiently over network technology available at the time protocols were designed or over networks based on the same technology. ATM can be used for much more than just IP services, whether it is feasible or not to run IP over ATM depends on many factors e.g. whether you can have some other 155Mbps WAN IP connection to your WWW server or some other network giving you similar throughput, or not. What is relevant here is the service, use your workstation connected only to computer network to call anyone within the reach of POTS using gateways located somewhere in the network you are connected to. The exact implementation is not that important. This idea is not new and there are similar services in some other places. This implementation happens to be running over IP over ATM for several reasons which are left as an exercise for the reader ;) Since I haven't seen the article I cannot say what is said there. >telephone services can be run efficiently over ATM directly, since it >was designed that way. Surely the overhead of 5 bytes in each 53byte ATM cell is inefficient when it is compared to raw SDH or PDH connections for telephone services? ok? ;) Mikko I. Tsokkinen xxxxx Mit From list-mgr@ISI.EDU Thu Apr 13 18:04:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 18:04:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 18:04:13 -0700 Received: from hubbub.cisco.com by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 18:04:10 -0700 Received: from Slaptoy.Stupi.SE (tli-home-pc.cisco.com [198.92.110.147]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id SAA28644; Thu, 13 Apr 1995 18:04:09 -0700 Date: Fri, 14 Apr 95 0:28:22 MET DST From: Peter Lothberg To: Juha Heinanen Cc: mit@cs.tut.fi, J.Crowcroft@cs.ucl.ac.uk, MBONE Subject: Re: ATM Switch cost In-Reply-To: Your message of Wed, 12 Apr 1995 23:51:52 +0300 Message-Id: > is someday implemented. ATM, however, has some additional advantages, > that i'm not sure if you can ever get with router technology. one of > them is scalability in terms of bandwidth and price. or can you give me > a pointer who is selling 16 port OC3 sonet routers at $1k per port? I have a phurcase order for the 1K$/OC3-port ATM Swicth, please have your sales-person call me... --Peter From list-mgr@ISI.EDU Fri Apr 14 04:27:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 18:28:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 18:27:40 -0700 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 18:27:38 -0700 Received: from by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AB22530; Thu, 13 Apr 95 18:26:58 PDT Message-Id: <9504140126.AB22530@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Apr 1995 03:27:02 +0100 To: Tsokkinen Mikko , Jon Crowcroft , Juha Heinanen From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: ATM Switch cost - actually questioning IP over ATM Cc: mbone It seems to me the relevant question is that if one puts any sort of service over IP and then over ATM (which is over some sort of link level service - e.g. SONET), what does ATM contribute? Jon has described some of the costs that using ATM creates from simple overhead to sources of packet loss, etc. What does ATM contribute in this scenario? I personally don't know of anything it contributes when run under IP - I would like to hear about such values. Is anyone doing side by side comparisons: 1. Application over IP over ATM over X vs. 2. Application over IP over X (X = T3, OC3, OC23, taxi, FCS, ...) ? --Jed -> http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Thu Apr 13 18:57:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 18:57:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 18:57:28 -0700 Received: from hubbub.cisco.com by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 18:57:26 -0700 Received: from Slaptoy.Stupi.SE (tli-home-pc.cisco.com [198.92.110.147]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id SAA02672; Thu, 13 Apr 1995 18:56:42 -0700 Date: Fri, 14 Apr 95 3:56:39 MET DST From: Peter Lothberg To: Vadim Antonov Cc: J.Crowcroft@cs.ucl.ac.uk, Juha.Heinanen@lohi.dat.tele.fi, MBONE, mit@cs.tut.fi Subject: Re: ATM Switch cost In-Reply-To: Your message of Thu, 13 Apr 1995 12:01:51 -0400 Message-Id: > -- juha::: > i agree that there is the cell header overhead that you have to pay if > you run IP over atm, but otherwise i don't understand your point. may > be you are reffering to the current ATM products that in many casds are > not a very good match for IP. The "Cell-Tax" we have to pay for using ATM, actually becomes real money. Asume a intercontinental DS3 link, just guessing on the price, 8M$/Year. Comparing HDLC with ATM we end up paying 800K$/Year in Cell-Tax, (for something we can't make use of..) > however, if you implementr fair queueing > along with early frame drop, i can't see why it would be a worse > solution for IP than the current fifo based routers. So, ATM is like RISC computers, let someone else do the job, as you said, 'frame-drop'. Taking this to it's extent... "Glass fibers are good for IP and VOICE, you just have to add the end- equipment. The fiber itself is really CHEAP..." I asume you mean 'tail-dropping' routers when you say 'fifo-routers', then you are wrong, there are routers that implement RED. From list-mgr@ISI.EDU Thu Apr 13 17:16:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 20:03:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 20:02:23 -0700 Received: from ipoint.vlsi.uiuc.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 13 Apr 1995 20:02:22 -0700 Received: by ipoint.vlsi.uiuc.edu id AA03282 (5.65c/IDA-1.4.4 for mbone@isi.edu); Thu, 13 Apr 1995 22:16:34 -0500 From: John Lockwood Message-Id: <199504140316.AA03282@ipoint.vlsi.uiuc.edu> Subject: Re: ATM Switch cost (fwd) To: mbone Date: Thu, 13 Apr 95 22:16:33 CDT X-Mailer: ELM [version 2.3 PL11] Forwarded message: > "Glass fibers are good for IP and VOICE, you just have to add the end- > equipment. The fiber itself is really CHEAP..." This argument over a 20% overhead of the ATM cell is out of hand. Fiber bandwidth is cheap. The cost to send a bit down a fiber (previously, wire) has been dropping by half every few years for the last few decades. In a world where each telnet keystroke costs the transmission of an entire TCP/IP packet (Overhead, about 5,000%); and where ASCII is used (rather than tightly formed binary strings) for Mosaic documents; and where email headers are often larger than the message (i.e., this group, often) how can we *really* worry about the 5 byte overhead of the ATM cell. The *real* cost that people have been discussing for T3 and T1 service comes from *regulation*, mostly, as well as *profit* by local TELCOs. More (often a factor of 2 over the transmission cost) comes from billing overhead. Most of the remaining cost comes from the price of the equipment (endpoint and network). A tiny portion comes from the cost of sending bits. John Lockwood | Electrical & Computer Engineering lockwood@ipoint.vlsi.uiuc.edu | University of Illinois phone: (217) 244-1565; Fax (217) 244-8371 address: 405 N. Mathews Ave., Urbana, IL 61801 http://ipoint.vlsi.uiuc.edu/people/lockwood/lockwood.html From list-mgr@ISI.EDU Fri Apr 14 05:01:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 06:02:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 06:01:48 -0700 Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 06:01:47 -0700 Received: by rodan.UU.NET id QQylku13949; Fri, 14 Apr 1995 09:01:46 -0400 Date: Fri, 14 Apr 1995 09:01:46 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: mbone Subject: re: "Fiber bandwidth is cheap." Cc: mo@uunet.uu.net Mr. Lockwood, If you can actually introduce me to your source of astonishingly cheap bandwidth, I'd very much appreciate it because I've not been able to find the provider you base your price assertions on. Oh yes, tell Lothberg too - some of his wires go across oceans and they are even more astonishingly expensive. So how much of your time do you spend talking to and working with the people who own the fiber, and hence install it, upgrade it, manage it, etc, etc?? I know I spend some part of EVERY working day doing that, and based on my understanding of reality, this quaint notion that Bandwidth is (or will be) too cheap to meter is just wrong. dead wrong. and this is NOT just some artifact of regulation. People seem to believe that bandwidth falls from the sky, or that you can get more by simply waving your hands. sorry, but on my planet it doesn't work that way. companies spend enormous amounts of money installing fiber and terminations and all the other stuff it takes to make the fiber actually carry bits, and they don't install an infinite amount because they don't have infinite money. and while your explanation of the bandwidth cost structure is an amusing contribution to the continuing urban legend, it is somewhere between incorrect and irrelevant. on the tehnical front, the notion that you can just keep pushing single-mode fiber faster and faster is also proving to be much harder than hoped. talk to the people doing real trials with 40-gigabit technology. serious voodoo going on there. They will *probably* get it working eventually, but it ain't soup yet. This business of designing systems based on "free bandwidth" is even more pernicious than designing sofware assuming "memory is free". and even if bandwidth were free, the speed of light isn't for sale at any known price, so latecy remains a fact of life. People are behaving as if they think how badly they want something to be true will cause it to be so. well, guess what: "Nature neither seeks nor abides your opinion." We now return you to your regularly schedule rant. cheers! -Mike O'Dell Resident Crank From list-mgr@ISI.EDU Fri Apr 14 17:00:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 08:01:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 08:01:13 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 08:01:12 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 14 Apr 1995 08:01:11 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Apr 1995 16:00:51 +0100 To: MBONE Subject: Re: ATM Switch cost (last 53 words) In-Reply-To: Your message of "Thu, 13 Apr 95 15:23:35 BST." <1019.797783015@cs.ucl.ac.uk> Date: Fri, 14 Apr 95 16:00:54 +0100 Message-Id: <7215.797871654@cs.ucl.ac.uk> From: Jon Crowcroft ok - having displeed the misinformatio nthat i was promulgating about telecom finalnd (they are doing what a lot of us want!), i'd like to add a bit on atm (sorry!) (putting on kevlar underwear...) the follwing comments are based on real, large ATM net experience not 3 switch in a lab type stuff: what really gets my goat about ATM isn't the lack of consideration for data in the design, its the lack of cosideration in the implementation conspiracy theories may be out of fashion, but one thing i observe about IP is that it is possible for rank amateurs to build networks that provide high degrees of satisfaction - the UK academic net is run by professionals, and is a wonder to behold, yet those same professionals take 3-5 days to get a 3 site ATM trial up using _products_ due to lack of routing, signaling, auto-configueation, decent address allocation guidelines, default QoS settings for existing traffic types and so on and so on basically, even the most IP friendly switch (probably the Fore ASX200) is dionsaur like compared to a similar price/performance router in terms of management when it comes to heterogeneity and interworking, it is really really sad - the two things one would hope that were got right were support for highly bursty traffic like IP (whether Mbone style of Plain Old FTP), and CBR voice/video, since the mass market is in these two things right now and what do we actually get ? well, two sorts of switches, one good at IP and bad at voice, the other good at CBR but too simple for UBR/ABR now, the consiparcy says - ha the phone companies think the internet was a good experiemtn, and now they want it, but they want a "real superhighway" to look too hard for the talented amateur to run - they want it all if we spent the amount per mbone site on better routers that we've spent on ATM kit, and we got the raw bandwidth etween them that we are allowed to get for ATM "eperiemtns" in the name of "superhighway" R&D, the mbone would be a damn fine service (and its not that shoddy now) not that ATM desn't have a place, its a question of priorities though, and basing them on sound engineering comparisons... i'd love to know from BAGNET and others how much _people time_ has gone in to getting things working when raw IP on SONET could have flown..... now back to working on the RSVP-Q2931 interworking architecture.... jon From list-mgr@ISI.EDU Fri Apr 14 01:24:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 08:24:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 08:24:31 -0700 Received: from framsparc.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 08:24:30 -0700 Received: by framsparc.ocf.llnl.gov (4.1/SMI-4.0) id AA09111; Fri, 14 Apr 95 08:24:27 PDT From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian) Message-Id: <9504141524.AA09111@framsparc.ocf.llnl.gov> Subject: Re: ATM Switch cost (fwd) To: lockwood@ipoint.vlsi.uiuc.edu (John Lockwood) Date: Fri, 14 Apr 1995 08:24:26 -0700 (PDT) Cc: mbone In-Reply-To: <199504140316.AA03282@ipoint.vlsi.uiuc.edu> from "John Lockwood" at Apr 13, 95 10:16:33 pm X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 815 >In a world where each telnet keystroke costs the transmission of an >entire TCP/IP packet (Overhead, about 5,000%); and where ASCII >is used (rather than tightly formed binary strings) for Mosaic documents; >and where email headers are often larger than the message (i.e., this >group, often) how can we *really* worry about the 5 byte overhead of the >ATM cell. It sounds like you're saying that, given that we already have so much overhead in some protocols, how can it hurt to have even more. That's not a very convincing argument. In fact, it would seem to be a possibly useful argument against adding further overhead... For what it's worth, telnet traffic accounted for less that 4% of the bytes transmitted on the NSFNET backbone in January, 1995, and smtp came in at slightly more than 5%. booloo From list-mgr@ISI.EDU Fri Apr 14 05:50:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 08:36:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 08:36:00 -0700 Received: from ipoint.vlsi.uiuc.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 08:35:59 -0700 Received: by ipoint.vlsi.uiuc.edu id AA03883 (5.65c/IDA-1.4.4 for mbone@isi.edu); Fri, 14 Apr 1995 10:50:11 -0500 From: John Lockwood Message-Id: <199504141550.AA03883@ipoint.vlsi.uiuc.edu> Subject: re: "Fiber bandwidth is cheap." (fwd) To: mbone Date: Fri, 14 Apr 95 10:50:11 CDT X-Mailer: ELM [version 2.3 PL11] > > on the tehnical front, the notion that you can just keep pushing > single-mode fiber faster and faster is also proving to be much > harder than hoped. talk to the people doing real trials with > 40-gigabit technology. serious voodoo going on there. > They will *probably* get it working eventually, but it ain't soup yet. My assertions on inexpensive bandwidth are based on the technology. For single mode fiber, laser devices, and receivers; the bandwidth can easily be pushed to ~ 5 Gbps (in research, going to 10-40 Gbps). This is up by orders of magnitude from 20 years ago, no? For each generation of technology, the regeneration ciruits have incurred a (relatively) fixed cost. With soliton technology, you can eliminate the repeaters (as *is* being done on the next generation undersea fiber links). Using multiple wavelengths and fiber regeneration circuits, existing fiber can carry multiple channels. 2-64 wavelenth systems have been demonstrated. > > This business of designing systems based on "free bandwidth" is > even more pernicious than designing sofware assuming "memory is free". > Do you want to argue DRAM prices? How much memory did *your* machine have 20 years ago. How much did it cost? $35/MByte for Si DRAM is orders of magnitude cheaper than core/tube/tranistor memory. Software designers *have* (pretty much) assumed free memory over the last 20 years. They were not too far off. > > and even if bandwidth were free, the speed of light isn't for sale at > any known price, so latecy remains a fact of life. > The speed of light limits latency, not bandwidth. From list-mgr@ISI.EDU Fri Apr 14 01:49:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 08:51:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 08:51:10 -0700 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 08:51:09 -0700 Received: by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA27308; Fri, 14 Apr 95 08:49:53 PDT Date: Fri, 14 Apr 95 08:49:53 PDT From: wiltzius@ocfmail.ocf.llnl.gov (David P Wiltzius) Message-Id: <9504141549.AA27308@ocfmail.ocf.llnl.gov> To: J.Crowcroft@cs.ucl.ac.uk, MBONE Subject: Re: ATM Switch cost (last 53 words) > and so on basically, even the most IP friendly switch (probably the Fore > ASX200) is dionsaur like compared to a similar price/performance router in > terms of management I worked with some of the first ciscos and Wellfleet routers. The ease of setup varied, but it was not easy. Indeed, when we went from bridging to routing I heard the same disparaging comments comparing the plug-and-play bridges and those confounding routers. > i'd love to know from BAGNET and others how much _people time_ has > gone in to getting things working when raw IP on SONET could have > flown..... I did not participate in setting up the "public" switches (we only have 3), but I did configure two on-site switches with *numerous* configurations - in my spare time (but those were long weeks). Once the tools/scripts are in place, no problem. But I can't compare it to IP/SONET - can you? ATM has a few more years at least before it is ready for prime time. When the medicine is not worse than the disease, take the medicine. But not earlier. Dave From list-mgr@ISI.EDU Fri Apr 14 11:25:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 12:25:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 12:25:34 -0700 Received: from titan.sprintlink.net by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 12:25:32 -0700 Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id PAA19119; Fri, 14 Apr 1995 15:25:26 -0400 Date: Fri, 14 Apr 1995 15:25:26 -0400 From: Vadim Antonov Message-Id: <199504141925.PAA19119@titan.sprintlink.net> To: lockwood@ipoint.vlsi.uiuc.edu, mbone Subject: re: "Fiber bandwidth is cheap." (fwd) >From: John Lockwood > My assertions on inexpensive bandwidth are based on the technology. > For single mode fiber, laser devices, and receivers; the bandwidth can > easily be pushed to ~ 5 Gbps (in research, going to 10-40 Gbps). > This is up by orders of magnitude from 20 years ago, no? Traffic on the networks is more than three orders of magnitude from 20 years ago. (And telephone companies already push the fiber close to the limit; Sprint, for example, has 2.4 Gbps fiber backbone). > For each generation of technology, the regeneration ciruits have > incurred a (relatively) fixed cost. Things are a bit different in the world where order of magnitude is two years worth of growth. > With soliton technology, you can eliminate the repeaters (as *is* being > done on the next generation undersea fiber links). Using multiple > wavelengths and fiber regeneration circuits, existing fiber can carry > multiple channels. 2-64 wavelenth systems have been demonstrated. By that time when that technology is ready bandwidth requirements will strain it to the litits, ok? >> This business of designing systems based on "free bandwidth" is >> even more pernicious than designing sofware assuming "memory is free". >Do you want to argue DRAM prices? How much memory did *your* machine >have 20 years ago. How much did it cost? $35/MByte for Si DRAM >is orders of magnitude cheaper than core/tube/tranistor memory. Software >designers *have* (pretty much) assumed free memory over the last 20 years. >They were not too far off. Sure. Ten years ago i was using a WYSIWYG text editor which took 30Kb of RAM. Nowadays you need 6Mb of RAM to produce the same paper, and it is *slower*, because it needs to get all those 6Mb and buses didn't get a lot faster since then. Sorree... the argument about free memory is as bogus as argument about unlimited virtual memory. Large memory footprints make programs slow, no matter how much physical memory the machine has. Turns your 100MHz Pentium into equivalent of PDP-11 :) > and even if bandwidth were free, the speed of light isn't for sale at > any known price, so latecy remains a fact of life. >The speed of light limits latency, not bandwidth. Latency remains the same, bandwith grows, congestion control problems grow proportionally to bandwidth*delay. ATM only makes the problem worse, because its design completely ignored 20 year of Internet experience. --vadim From list-mgr@ISI.EDU Fri Apr 14 06:22:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 13:23:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 13:22:47 -0700 Received: from cincsac.arc.nasa.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 13:22:46 -0700 Received: from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (8.6.11/1.5T) id NAA05429; Fri, 14 Apr 1995 13:22:02 -0700 Message-Id: <199504142022.NAA05429@cincsac.arc.nasa.gov> To: Jon Crowcroft Cc: Tsokkinen Mikko , MBONE Subject: Re: ATM Switch cost In-Reply-To: Your message of "Thu, 13 Apr 95 11:38:29 BST." <2174.797769509@cs.ucl.ac.uk> Date: Fri, 14 Apr 95 13:22:02 -0700 From: "Milo S. Medin" (NASA Ames Research Center) John, part of the problem here isn't that people wouldn't like to build raw IP based networks out of routers at high speed, but rather, the router vendors simply aren't making products suitable as hub routers. Look at cisco's product line, and see how many DS-3's you can support in one box. Port density is awful! You can't get a interface that does OC-3c without ATM support. When you ask them for a box that supports half a dozen DS-3's, they point you to an ATM switch product. So, it doesn't matter if ATM is the right answer or not - you're being forced into to it for high speed network support by the products the vendors are building. And by what they are charging. Look at what a maxed out 7000 with HSSI interfaces costs compared to an ATM switch with reasonable buffers and frame oriented drops. What's a network builder to do? Do some traceroutes around some of the backbones in the Internet, and you'll see extra hops directly attributable to the lousy port density problem. Several of us have complained for years about this and have gotten squat for response. Cisco isn't the only vendor that has this problem either. Thanks, Milo From list-mgr@ISI.EDU Fri Apr 14 09:33:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 13:34:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 13:33:58 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 13:33:53 -0700 Received: by chops.icp.net id <20653>; Fri, 14 Apr 1995 13:33:38 -0400 From: Sean Doran To: J.Crowcroft@cs.ucl.ac.uk, MBONE Subject: Re: ATM Switch cost (last 53 words) Message-Id: <95Apr14.133338-0400_pdt.20653+25@chops.icp.net> Date: Fri, 14 Apr 1995 13:33:37 -0400 | now, the consiparcy says - ha the phone companies think the internet | was a good experiemtn, and now they want it, but they want a "real | superhighway" to look too hard for the talented amateur to run - they | want it all Interestingly, most of the negative voices here have been people who work for phone companies or who have phone company backgrounds. There is no question that I'm a greedy bastard working for an evil telco, but the way to make money from the Internet is to make it work properly, not to kill it off in favour of a "real superhighway", whatever the heck that is. The talented amateur is our biggest customer base -- she or he is very good at running local services and handholding customers, and recognizes that running long-haul (cross-continent, trans-ocean) connections is not something for him or her to do. Whether the talented amateur is vulnerable to other players entering into the market is the subject of much speculation, however, if I was a talented amateur, I wouldn't be panicking right now. | if we spent the amount per mbone site on better routers that we've | spent on ATM kit, and we got the raw bandwidth etween them that we are | allowed to get for ATM "eperiemtns" in the name of "superhighway" R&D, | the mbone would be a damn fine service (and its not that shoddy now) Yes. Agreed. I, for one, like the idea of multicast (or oligocast anyway) being available to everybody for both sending and receiving, whether they're cable companies, Hollywood giants, or small-time performance artists, or sex on demand folks or whatever. There's lots of work to do to get there, starting with getting things like PIM working and evolving, so the overhead of the mbone is no more than one packet per link per packet transmitted, and is generally only one packet per link that has someone downstream who specificially wants it per packet transmitted. (Not to mention congestion sensitivity and other things to make the mbone nicer in the current global Internet, so that the number of "FOO is transmitting 8 Mbits/second of video noise" messages drops to zero). On the other hand, I also like the idea of working on parallel on-demand multimedia stuff that can be done over TCP, for example, for recorded and "only nearly live" material. I don't see how the letters "ATM" will help accomplish any of that. Sean. - -- Sean Doran / From list-mgr@ISI.EDU Sat Apr 15 03:19:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 16:21:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 16:19:40 -0700 Received: from eunet.EU.net by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 16:19:34 -0700 Received: from spades.EU.net (spades.EU.net [192.16.202.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id BAA09425; Sat, 15 Apr 1995 01:19:32 +0200 Received: by spades.EU.net id AA23475 (5.67a/IDA-1.5); Sat, 15 Apr 1995 01:19:31 +0200 Message-Id: <199504142319.AA23475@spades.EU.net> From: Per Gregers Bilse Date: Sat, 15 Apr 1995 01:19:31 +0200 In-Reply-To: <199504141550.AA03883@ipoint.vlsi.uiuc.edu> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: John Lockwood Subject: re: "Fiber bandwidth is cheap." (fwd) Cc: mbone On Apr 14, 10:50, John Lockwood wrote: > My assertions on inexpensive bandwidth are based on the technology. Not to flog a dead horse, but that's irrelevant. The bottom line is value in return for money. At the bandwidths we're talking about -- in particular for somebody like us who go international (pan-European and transatlantic) big time -- just a few percent means very sizeable amounts of real hard money. What do we get in return for a 10% overhead? What is -improved- by repackaging our packets? If there's no gain, nobody will buy -- unless they have other considerations than cost effectiveness. -- === ___ === Per G. Bilse, Sr. Network Engineer === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, Holland === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Fri Apr 14 17:06:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 21:26:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 21:26:16 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 14 Apr 1995 21:26:15 -0700 Received: by chops.icp.net id <20652>; Fri, 14 Apr 1995 21:06:47 -0400 From: Sean Doran To: J.Crowcroft@cs.ucl.ac.uk, medin@nsipo.nasa.gov Subject: Re: ATM Switch cost Cc: MBONE, mit@cs.tut.fi Message-Id: <95Apr14.210647-0400_pdt.20652+38@chops.icp.net> Date: Fri, 14 Apr 1995 21:06:40 -0400 | So, it doesn't matter if ATM is the right answer or not - you're being | forced into to it for high speed network support by the products the | vendors are building. And by what they are charging. Look at what a maxed | out 7000 with HSSI interfaces costs compared to an ATM switch with reasonable | buffers and frame oriented drops. And look at how quickly the builders and potential builders of high-speed IP networks are snapping those products up, and how happy they are with them... (note heavy irony). | What's a network builder to do? Despite lots of people thinking the opposite it's still a buyer's market out there; end users just want their applications to work so that can satisfy their need for sex-on-demand or whatever, and people providing those services want to make money by making those applications able to talk to each other properly and quickly. There's alot of money involved in the whole thing, and it's all driven by the end user. Anyone who thinks that they control the market such that they can sell products and protocols that ultimately don't help the end users do their thing is in for a bit of a shock. Fortunately, some people who make decisions for certain vendors are beginning to realize that it makes economic sense to listen to what people like you and Mike O'Dell are asking for, and that it _isn't_ ATM. We shall see what happens... Speaking of Mike O'Dell, he has some nifty analogies about this whole issue that you should steal and quote regularly. You'd get great mileage from them. Sean. P.S.: ObMBONE - (tie-in with fast-packet) has anyone done significant amounts of multicast IP using multicast features of fast-packet switches? If anyone has any experience doing a full mbone feed during IETF week on a fast-packet fabric with ten or more members per multicast group, I'd be interested in hearing about that. The last time I asked, I was told that the fastest way to kill a well known fast-packet-using touchdown point would be to do lots of multicast traffic... From list-mgr@ISI.EDU Sat Apr 15 07:18:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 10:04:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 10:04:20 -0700 Received: from ipoint.vlsi.uiuc.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 10:04:19 -0700 Received: by ipoint.vlsi.uiuc.edu id AA07197 (5.65c/IDA-1.4.4 for mbone@isi.edu); Sat, 15 Apr 1995 12:18:33 -0500 From: John Lockwood Message-Id: <199504151718.AA07197@ipoint.vlsi.uiuc.edu> Subject: Re: ATM Switch cost (fwd) To: mbone Date: Sat, 15 Apr 95 12:18:33 CDT X-Mailer: ELM [version 2.3 PL11] Forwarded message: > > P.S.: ObMBONE - (tie-in with fast-packet) has anyone done > significant amounts of multicast IP using multicast > features of fast-packet switches? If anyone has any > experience doing a full mbone feed during IETF week on a > fast-packet fabric with ten or more members per multicast > group, I'd be interested in hearing about that. > > The last time I asked, I was told that the fastest way > to kill a well known fast-packet-using touchdown point > would be to do lots of multicast traffic... > On a slight variant, on the Xunet testbed we experimented with running the MBone on the IP-ATM routers (still using mrouted, with software-based multicast, but with the benefit of a fast (45mbps) ATM interface and an SGI router) On the wide area network (NJ,IL,CA,WI), we were able to run 12 simultaneous NV video transmissions and an audio session. All told, we could handle about 7-8 Mbps of Mbone multicast traffic. (It was held within the network to avoid flooding the MBone) We are in progress of using the IP-multicast -> ATM-multicast, but this is far from primetime. Some details are available at: http://ipoint.vlsi.uiuc.edu/people/lockwood/xunet.html, and through links from there. -john lockwod From list-mgr@ISI.EDU Sun Apr 16 01:27:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 15:28:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 15:27:38 -0700 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 15:27:35 -0700 Received: from [129.69.30.90] (ksmac1.rus.uni-stuttgart.de) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA13544; Sat, 15 Apr 95 15:27:23 PDT Message-Id: <9504152227.AA13544@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 16 Apr 1995 00:27:27 +0100 To: mbone From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: ATM Switch cost - a different view (Tome) This comment in the "ATM Switch cost" thread is divided into three parts: A. RESPONSES to what various people have been saying in the thread, B. A description of the PROBLEM as I see it in architecting a network for the higher bandwidths both available and needed for "individual video" and other services that people want, C. A description of a potential problem solution, JITS, and D. A SUMMARY. While the sections don't really stand alone too well - it may be appropriate to skip around at first to minimize reading time. For example, one could read A, D, and then only B and/or C if interested. _____________________________________ A. RESPONSES: When John Lockwood says: >This argument over a 20% overhead of the ATM cell is out of hand. >Fiber bandwidth is cheap. The cost to send a bit down a fiber >(previously, wire) has been dropping by half every few years for the >last few decades. I support this position. I don't believe that a 20% overhead is a substantial cost for ATM. It must be traded off vs. the value contributed, but it doesn't seem to be a significant factor to me. I also believe that the cost of fiber bandwidth is dropping at a substantial rate (more about this later). I also agree with Mark Boolootian when he says: >We tried bringing up a Fore ATM interface on a Meiko CS-2 yesterday and I >was absolutely boggled by the amount of diddling required on the host to >become a part of Bagnet. Too much knowledge about the net has to be built >into the host. Perhaps that will be fixed over time. Namely, as things stand the administrative issues with current ATM technology are so high as to make it an impractical solution when compared with direct IP (over say SONET). When Dave Wiltzius says: >>... I can't compare it to IP/SONET - can you? while I don't have a clear idea of the costs of installing ATM currently (except from discussions like this one), I do have quite a clear idea of what it costs to put IP over SONET. Namely, it is quite similar to putting IP over T3 lines. I don't know exactly what will happen to the routers as the load goes up, but this is a fairly well understood problem. I believe that up to the levels that people are currently using ATM (OC3 links) and probably even up to the levels that they plan to use ATM in the near future (OC12 links) IP routing is reasonable (packet sizes may need to increase). I agree with Dave Wiltzius when he says: >When the medicine (ATM) is not worse than the disease (direct IP), >take the medicine. But not earlier. I wonder, however, if this particular medicine will ever be better than this particular disease. I believe that both have serious problems when bandwidths get significantly higher than that of multiple OC12 level lines coming into a switching system. I agree with John Lockwood's points about bandwidth becoming more readily available: >The *real* cost that people have been discussing for T3 and T1 >service comes from *regulation*, mostly, as well as *profit* by local >TELCOs. More (often a factor of 2 over the transmission cost) comes >from billing overhead. Most of the remaining cost comes from the price of the >equipment (endpoint and network). A tiny portion comes from the cost of >sending bits. and: >My assertions on inexpensive bandwidth are based on the technology. >For single mode fiber, laser devices, and receivers; the bandwidth can >easily be pushed to ~ 5 Gbps (in research, going to 10-40 Gbps). >This is up by orders of magnitude from 20 years ago, no? > >For each generation of technology, the regeneration circuits have >incurred a (relatively) fixed cost. > >With soliton technology, you can eliminate the repeaters (as *is* being >done on the next generation undersea fiber links). Using multiple >wavelengths and fiber regeneration circuits, existing fiber can carry >multiple channels. 2-64 wavelength systems have been demonstrated. >> >> This business of designing systems based on "free bandwidth" is >> even more pernicious than designing software assuming "memory is free". >> >Do you want to argue DRAM prices? How much memory did *your* machine >have 20 years ago. How much did it cost? $35/MByte for Si DRAM >is orders of magnitude cheaper than core/tube/transistor memory. Software >designers *have* (pretty much) assumed free memory over the last 20 years. >They were not too far off. >> >> and even if bandwidth were free, the speed of light isn't for sale at >> any known price, so latency remains a fact of life. >> >The speed of light limits latency, not bandwidth. (on this last point, I believe that every point on the earth is within about .06 great circle light seconds of every other. This makes round trips of .12 second possible - I believe this is below the level of human detectability for audio and video). While I agree with Mike O'Dell's point that much effort (read money) is spent by those "people who own the fiber, and hence install it, upgrade it, manage it, etc., etc.??", I basically disagree with his seeming assertion that this implies that the cost of communications will not continue falling and falling steeply as John Lockwood asserts. I think the basic disagreement on this point comes from the fact that while there is a relatively fixed (but certainly large) cost for putting in and supporting cable (copper, fiber, etc. - even with amplifiers, etc.), the amount of communication that one gets for that cost is going up exponentially. Compare the 45 megabit/sec T3 rate with that of the OC48 equipment that is being field tested today - 2.5 gigabits/sec. If anything I am probably even more optimistic than John Lockwood in the future I see for high bandwidth communications. The bandwidth available from wavelength division multiplexing has not even yet begun to be tapped. I believe that basically one or two chips (a transceiver or a transmitter and receiver chip that WDM muxes 16-128 gigabit/sec signals on a fiber) is all that is needed to begin to exploit substantial portions of this available bandwidth at even lower costs than are experienced today with SONET equipment. (I happen to also agree with John in his point about memory costs, but that is a diversion). _______________________________________________ B. The PROBLEM However, let's stay out of "voodoo" land for the moment. Let's take the 10 gigabit/sec systems that are being tested in the lab today as a reasonable guess about what will be available in 3-5 years. With these systems I don't even believe some of the issues with optical amplification come in to play. To simplify things even further, let's just focus on the LAN/MAN area for the moment where re amplification is not a substantial issue even with electrical systems (though I have great hope for the WAN cables like Teleglobes CANTAT-3 [4 x OC3 in place] and planned CANUS-1 [optically amplified in development] - see my Computer and Communications WWW page for a reference). What seems like a reasonable number of fibers to use in a central trunk system in a MAN area (e.g. the SF Bay area)? I would think that 100 fibers is certainly a reasonable number. One can buy 128 fiber cables. Remember we are talking about the main trunk routes, not the leaf areas. Also we are talking about the "Information Superhighway" :-) and a replacement for and upgrade to telephone equipment. Of course with a number like this and using the 10 gigabit/sec number chosen above, we are talking about a huge, expensive, and hot set of switching equipment with current technology - this is the subject I want to address, specifically as it relates to ATM Switch costs. Before I do though, I should say that I see no problem with use of (what some would call "demand" for) so much bandwidth. With the experience we all share on the MBone I think it is clear that people would love to be able to direct their sight remotely with telecommunications equipment they way they can now direct their hearing. Look how people watch those tiny, flickering, noisy, MBone images. Look how much time people spend watching television. Of course people aren't going to pay much more than they do today for communications (~$20-$200/mo.), but there is the opportunity to get so much more for that amount! I believe that if somebody offers people a remote video transmit and receive capability (not to mention all the lesser bandwidth Internet services that we are used to) for about what they now pay for telephone services, they will eagerly switch. This means upgrading bandwidth from roughly 64 kbit/sec for a "connection" to at least 4 mbit/sec (if you are a compression fan - which I am not). This suggests that the ability to sell at least a 100 fold increase in communication capacity - not for more money (as perhaps the current monopolistic carriers would like it) but for greater market share - is definitely realistic. So we have buyers ready for "individual" video and we have capacity in the fiber. What is stopping us? Here is another point where I agree with John Lockwood, when he says: >The *real* cost that people have been discussing for T3 and T1 >service comes from *regulation*, mostly, as well as *profit* by local >TELCOs. More (often a factor of 2 over the transmission cost) comes >from billing overhead. Most of the remaining cost comes from the price of the >equipment (endpoint and network). A tiny portion comes from the cost of >sending bits. I believe that ONE major reason that we are not getting substantially increased communications capacity for our fixed costs is regulation - specifically the monopoly position enjoyed by the local carriers. This is in turn required by the "Universal Access" that we hear so much about lately. If local carriers are required to cross subsidize rural access, they essentially must be a monopoly (unless the government is willing to tax somebody to directly subsidize rural communication - an unlikely proposition). I believe that if anyone with fiber in the ground was allowed to sell that fiber to whoever could turn it into communication capacity that could be sold to people close to that fiber (often urban people) then the delivered capacity per cost would increase rapidly in urban areas. I even it believe it would increase rapidly in rural areas (though not as quickly). I also believe that it would increase in rural areas at a faster pace than if "universal access" and its concomitant subsidies are required to continue. This regulation issue is why communication costs are roughly 10 times as high here in Europe as they are in the US. The Europeans certainly don't have a more difficult set of technical problems putting in and supporting the cables - quite the contrary - everything is so close here (e.g. Germany) that these problems are reduced. Rather than continue getting sucked into this political black hole, let me tie back into the "cost of ATM switching" topic of this note. I believe the major technical issue that is stopping us from delivering this additional available capacity is the inability of switching systems to keep up with it. Specifically I believe that ATM switching and IP routing run out of gas at about the same point, well short of what is required to adequately deliver effective individual video. Before I tie this up, let me distinguish this argument from the others made against ATM. I fully support Jon Crowcroft in his assertion that running IP over ATM makes no sense. In this case ATM contributes costs and no value. You basically get the worst (i.e. the costs) of both worlds. I believe the problems of supporting a two level networking structure (IP over ATM over links) is VERY substantial. Anyone who has suffered with the European efforts at IP over X.25 over links knows many of these problems first hand. For those that support ATM this leaves (from my viewpoint) the option of a pure ATM SVC world. One could argue (and I think many do) that one should eventually replace TCP connections with ATM SVCs and have a much more scallable system. Tying in Dave Wiltzius' point about waiting until the medicine is better than the disease, this would suggest that one should wait until ATM SVC setup time is the same or better than TCP connection setup time - i.e. one or two round trip packet times - point to point speed of light latency. I am not sure that ATM will ever reach this speed in circuit setup. If not then this is just another mark against it. Even if so I believe that many of the practical issues that Jon and others have brought up are serious reasons for sticking with IP over links for some time to come. Just as those that wanted to replace silicon with GaS for processing or perhaps with bubbles for memory were premature (i.e. the silicon curve is still being effectively ridden further), I believe that those that want to jump from IP to ATM are quite premature. This argument would seem to support Dave Wiltzius' argument that we simply need to wait for ATM to mature. However, the problem with this approach is that it assumes that ATM over links will deliver something that IP over links will not after ATM does mature. I don't believe that ATM will ever deliver any substantial added value. I don't want to get distracted with a Quality Of Service discussion - except to say that I believe this whole area of hype for ATM is overblown. ATM may be able to "overbook" QOS requests by a factor of 2 or 4 (I think less than 1 more likely), but it won't be a factor of 10 let alone the factor of 100 that is needed. Beyond all the above arguments, my problem with ATM is that I simply don't believe that ATM switches can be built that will switch at adequate rates. If you take the supply side numbers above: 100 fibers, 10 gigabits/sec each, and say 5-6 trunks coming into a switching center, you end up with 5-6 terabits/sec aggregate capacity required in the switch. I believe that if you take the "demand" side of the equation for what I have called "individual" video, you come up with similar numbers. I believe that these comparable supply and demand numbers are a fairly conservative target for the 5-10 year future. I believe that such individual video would be purchased if it could be made available. If the regulation was out of the way, the fiber capacity could be there, but what about the switching? This is the point where I think I start venturing into somewhat new territory (thanks for sticking with me this long if you are reading this). I don't believe that ATM switching systems will scale up to these aggregate rates at reasonable costs (in dollars, heat, reliability, etc.). If you look at an ATM switch like the UofI iPoint switch (Hi John!), it is pushing pretty hard to get to 800 mbit/sec. They argue that by basically turning it into a supercomputer (GaS technology, substantial parallelism, etc.) they can reach 100 gigabits/sec. This is still a factor of 10 short of what I argue is available in the lines and needed by the applications. I really believe this case is understated, but I hope it is adequate to make my point. In my opinion ATM switches are just not going to cut it. Much of the discussion in the iPoint switch paper is about the constraints on the switch imposed by the ATM architecture. ________________________________ C. A possible solution, Just In Time Switching (JITS). Well, if not ATM, then what? I have argued (I think with Jon Crowcroft) that we should ride the IP over links technology that we are now using as far as it can carry us. However, I believe that IP over links will run out of gas (i.e. we will not be able to make adequately performing routers) at about the same point that ATM switching starts to have problems. Those that argue for "pure" ATM (i.e. not IP over ATM) when we get to high speeds often believe that IP switching (i.e. routing) will start having problems long before ATM switching becomes unreasonable. I don't happen to agree with this viewpoint, but I am not sure that it matters too much. The other problems with ATM (and there are more beyond those discussed above) are such that I don't think ATM is worth putting into place if it is just a temporary intermediate to something that will be needed for individual video. I remember many of the discussions of "self routing" ATM switches in the early days (many out of Washington U.). I noticed that such technology was not proposed for the iPoint switch. I am seriously concerned that ATM switching at the speeds required for "individual video" will just not be practical. At this point anyone still reading may think that I have set them up for an argument in favor of "all optical" networking. I certainly do think that WDM is a viable technology for the medium term future (e.g. 5 years out). I also think that "all optical" switching will be wonderful if/when we get there. However, I don't presently see the components coming to make such networking possible in the 10 year future. I don't want to wait this long and I don't think we need do so. JITS: I believe that a rather minor variation on circuit switching technology can suffice to deliver adequate switching for the performance levels that I have argued are necessary, AND can be suitably architected so that it will work with all optical networking if/when it becomes available. There may be many other approaches that are workable solutions to this problem. However, the one that I mention here I believe will suffice. I think that it is important to get on with solving this problem and not let ourselves be dragged along by the hype and research dollars available for ever more ATM testing and problem solving. If ATM is not an intermediate solution and it is not a long term solution, then it isn't a solution at all - it is part of the problem. I think we should go ahead and put IP over SONET and push IP routing technology to its limits. However, I believe that in the mean time we should be developing something that will be there when this approach (and the ATM approach if this medicine does indeed become better than the IP routing "disease") simply will not cut it any longer. I will describe the "Just In Time Switching" (JITS - suggestions on the name are, of course, solicited) approach that I believe is A solution to this switching performance problem that does not need to wait for all optical components. The requirements are for 2 terabit/sec and greater aggregate switching capacity, fast "connection" setup (on the order of a round trip packet time), flexible bandwidth multiplexing, and the ability to adapt to all optical solutions. I don't want to go into this architecture in detail here - I hope to do that in a paper as the ideas play themselves out. I want to try to convey enough of the basic concepts here so that anyone following can criticize them. The JITS idea can perhaps best be thought of in terms of a railroad train analogy. Think of the links as being 100s to 1000s of tracks coming into a switching yard. By throwing switches at the right times it is possible to route trains of arbitrary size to their appropriate destinations. Multicast is possible (sans the train analogy) by copying the bits onto multiple outgoing channels. Without any buffering one basically has the world that the all optical people talk about. However, in the less "voodoo" world that we are likely to occupy 5 years from now, this switching can be accomplished electronically, and we can even buffer data (i.e. run it temporarily onto "side tracks") if there is no space on any appropriate outgoing links when incoming data arrives. In many ways this approach is like SONET/SDH. I basically think that the older BISDN circuit switching folks were closer to being right than the eventual ATM winners. If one could do fast "circuit" setup and could get adequate aggregate switch throughput with SONET then I would be happy with SONET. However, I don't think this is possible with STM (i.e. SONET) circuits. I don't know if fast circuit setup is possible. People keep telling me that it isn't. I am not sure why. However, I believe that the SONET "matrix" approach for shifting parts of frames around is electronically intensive enough that, while it seems better to me than ATM, it is unlikely to be able to cost effectively achieve the aggregate switching capacity that I believe is needed. With JITS the electronics needed for switching are minimized. With all optical components they could be eliminated all together (without changing the architecture). However, this would require very fast optical switching. With electrical switching, however, an ordinary Clos switching matrix can be used. An architecture like that built into the pieces of the Fibre Channel switch at LLNL would work fine. In such an architecture cross bar chips are combined to build a non blocking 2k x 2k switch with 1 gigabit/sec port and link speeds. Unlike in the Fibre Channel architecture, however, with JITS the channels would stay serial the whole time. There is no "in band" signaling. Control signals are sent on a separate store and forward packet switched channel that is also used to establish clock synchronization. I am certainly no expert on clock synchronization, so this is an area that may well be weak. I believe that a so-called "plesiochronous" (sp?) clocking scheme (each node with an independent clock trying to run at "the same" rate) makes the most sense. It also makes sense to me that the rates for the links be the same as those for SONET so that the SONET clocking can be used when available. This sort of independent clocking scheme requires enough buffering (some small number of bits) in the electronics to shift phases as the signals pass through the switch matrix from the clock of the sender to that of the receiver (the next sender). It also places some constraints on the size of packets in that they can't be so large that during a single packet transit through a switch the phases will shift enough to overrun the minimal phase shift buffering in the receiving logic. The switching requirements basically amount to a set of times at which the cross bars have to be thrown in different directions. Electronic cross bars can be thrown very quickly (under a microsecond - how much under I don't know because I don't have the data in front of me - anyone know?). The time during which a crossbar is being thrown is time during which no data can be incoming. This means that the packets must be large enough to amortize the cost of this "dead time" between packets. A quick note about latency. There are some people that argue that small ATM cell sizes are needed to allow fast and cost effective switching. As noted here I don't believe that such small cell sizes help solve this problem, but I can respect their position. There are a few people that continue to argue that small ATM cell sizes are needed to support adequately low latency for voice and video. I believe these people are VERY wrong (I basically support Van Jacobson's position on this). For JITS I believe the latency constraints for audio and video translate into an upper bound on the repetition rate at about .05 sec. This is small enough to be a small part of the latency induced by speed of light considerations for distant points. It also translates into roughly a 512 byte "packet" for 64 kbit/sec audio. Switching such small packets by themselves is not very efficient with JITS. If switched separately and we accept the 1 microsecond time for throwing a crossbar (I actually think it can be much less, but...) then the "dead time" overhead for separately switching such small audio packets with 1 gigabit/second links would be about 25%. It gets linearly worse with increasing link speeds. As I see this, the distinction between ATM and JITS in this regard is that ATM took a voice viewpoint and basically froze it into its architecture. JITS adopts a more "open" approach. It can accept multiple channel rates. As channel rates increase packet sizes can increase as well, reducing the switching overhead. Voice may become less efficient at these higher rates (sans effective grouping strategies), but then voice is a less significant part of the load. I believe those that think of 53 bytes as the "word" size of ATM and believe that this is no more significant than dealing with 8 bit bytes or whatever are missing a VERY important point. The problem with the ATM cells is not a unit size problem per se, but rather the fact that each of these units must be looked at and a rather complex set of decisions must be made for each cell as it passes through the switch. JITS avoids looking at the data altogether. In this way, even though it may not be "all optical", it is as protocol transparent (except possibly for analog protocols) as the all optical approach is. There are quite a number of interesting connection setup, routing, and buffering strategies that can be considered with this architecture. JITS makes no attempt to attain the "overbooking" value that ATM strives for. I argue simply that ATM's efforts in this area are likely to deliver too little at too high a price. However, JITS can achieve essentially complete channel packing at the cost of buffering similar to that for SONET (but not as much as the delay X bandwidth buffering that many think ATM will require). JITS circuits will have a "repetition rate" somewhat like with SONET (though established with connection setup, not fixed). By buffering enough data to cover the largest such repetition rate for each incoming channel, JITS can guarantee essentially full packing of channels. I believe (Mike O'Dell would probably say hope) that with the communications bandwidths that will soon be available, buffering in JITS will play an insignificant if not nonexistent role. This would allow available bandwidth to be traded off against switch simplification and corresponding reduced cost. It is interesting to ask how packets can be grouped while flowing through JITS switches to reduce the need for switching. Namely, if two packets to different destinations happen to be following the same route through a switch, it would reduce the number of required switch throwings if they were "next" to each other. How much this can be done is a matter that must be analyzed in the context of connection setup. As with the SONET discussion above, buffering of one "repetition" period is adequate to insure that any sort of "grouping" requirements can be met. Sub multiplexing (i.e. TDM) and super multiplexing (i.e. "striping") of channels are both possible with JITS. An interface that requires the higher speeds of striping will likely be somewhat more expensive. However, any such activities by the host adapters are invisible to the network. Since JITS makes no requirements on packet sizes and link speeds (other than that they directly coincide with the SONET basic rates), the architecture can scale just like conventional circuit technology, but can achieve the sort of multiplexing value (even QOS) that people are looking for in ATM (except for overbooking). If communication costs continue to drop, I argue that the (questionable) overbooking added value of ATM is not worth ATM's architectural costs. I should mention here that I feel that the current set of high speed LAN architectures, FDDI, fast Ethernets, and even more importantly HIPPI (serial) and Fibre Channel in my opinion are very seriously flawed. They are flawed because they didn't go far enough - literally. I have come to accept the argument made by ATM advocates that to be effective a high speed networking architecture must extend to WAN distances. None of the LAN architectures mentioned above accomplish this. I believe that JITS is not substantially more complex than serial HIPPI or Fibre Channel. I believe it would be an even more effective LAN architecture which would cost less and deliver more (specifically more flexible multiplexing). When compared to Fibre Channel, for example, the one JITS circuit paradigm would eliminate the need for much of the multiple class complexity of Fibre Channel. Most importantly, JITS extends its circuits to the WAN world effectively. I believe (with hindsight) that serial HIPPI and Fibre Channel are seriously flawed in not supporting such circuit extension. _________________________________ D. SUMMARY: 1. IP over ATM over X (e.g. SONET) makes no sense. As long as we are using IP, let's put it directly over high speed links, use high speed IP routers as long as we can and simplify our world to something that we understand today. 2. Whether with direct IP (as above), IP over ATM, or with "pure" ATM, the problems of electrically looking at cell (frame) headers, routing cells (frames), dealing with collisions (congestion), traffic shaping, etc., etc. will make either IP routers or ATM switches too expensive to use at the high aggregate bandwidths required for the next distinct service offering that I believe there is a market for - what I call individual video. I believe that we are in for a bumpy ride on Internet over the next 5 years or so with or without ATM as people put (or try to put) more audio, video, and higher quality data (e.g. graphics, virtual worlds, etc.) on Internet. 3. It is time to get on with designing a network architecture that can scale to rates beyond those for which IP routing or ATM switching make sense (2 terabit/sec switch aggregates and up). It is time to design and start building an architecture that can support bandwidths suitable for "individual video." 4. While I am very enthusiastic about "all optical" networking in the long run, I don't believe that it is needed to support these levels of performance. I proposed the Just In Time Switching (JITS) architecture as an approach that will work by utilizing classical circuit switching to achieve high bandwidth while still supporting "virtual circuits" with flexible "Quality Of Service" control. The major aspect of ATM switching that this approach gives up is "overbooking." I argue that with bandwidth costs continuing to fall, such overbooking is not worth the costs that ATM switching brings with it. Thanks for taking the time to read this lengthy note. Any comments/criticisms are appreciated. --Jed -> http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Sat Apr 15 15:10:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 16:07:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 16:06:57 -0700 Received: from wanda.pond.com by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 16:06:54 -0700 Received: from [198.69.82.127] by wanda.pond.com (8.6.9/gw.1.0) id TAA05440; Sat, 15 Apr 1995 19:08:21 -0400 Message-Id: <199504152308.TAA05440@wanda.pond.com> X-Sender: landpost@mail.pond.com. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 2 (High) Date: Sat, 15 Apr 1995 19:10:29 -0400 To: mbone From: landpost@pond.com (Tim McCarthy) Subject: UNSUBSCRIBE UNSUBSCRIBE From list-mgr@ISI.EDU Sun Apr 16 02:23:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 16:23:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 16:23:38 -0700 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 16:23:37 -0700 Received: from [129.69.30.90] (ksmac1.rus.uni-stuttgart.de) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA13807; Sat, 15 Apr 95 16:23:29 PDT Message-Id: <9504152323.AA13807@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 16 Apr 1995 01:23:32 +0100 To: mbone From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: ATM Switch cost - no high speed IP routers I received Milo's note: >John (sic - Jon), part of the problem here isn't that people wouldn't like to >build >raw IP based networks out of routers at high speed, but rather, the router >vendors simply aren't making products suitable as hub routers. Look at >cisco's product line, and see how many DS-3's you can support in one box. >Port density is awful! You can't get an interface that does OC-3c without >ATM support. When you ask them for a box that supports half a dozen >DS-3's, they point you to an ATM switch product. to late to include in my tome, but I certainly agree with this point. It seems to me that this is a market waiting to be tapped (unless there is a technical problem that I don't see there). Incidently, is the port density problem that you refer to one of packets/sec or bits/sec? It certainly seems reasonable to me to expect that average packet size will have to increase as aggregate bandwidths increase to keep IP routing technology running to much higher bandwidths. Regarding: >So, it doesn't matter if ATM is the right answer or not - you're being >forced into to it for high speed network support by the products the >vendors are building. And by what they are charging. Look at what a maxed >out 7000 with HSSI interfaces costs compared to an ATM switch with reasonable >buffers and frame oriented drops. This is well and good, but will it (ATM) work? I guess that is what all these ATM test beds are trying to figure out. With the kind of performance numbers and problems that I am hearing for ATM, this medicine (in Dave Wiltzius' words) is not yet better than the disease of low performance in IP routers. However given Milo's argument, perhaps if some of the wrinkles in ATM can be worked out, it may be an intermediate term solution. But what about the issue of whether it is a long term solution? Does anyone believe that ATM switches in the multiple terabit/sec aggregate area are viable (Mr. Lockwood?)? We are all putting so much effort into ATM that I will not be happy with it if it has to be almost immediately replaced with yet another architectural generation. The current telcos are so slow at such generation turnover that I may not live to see the generation after ATM. Of course one answer to this would be to start competing with the telcos (i.e. John Lockwood's and my argument about the costs induced by regulation), but I would like to see the competition happen using a technology with a "long term" future, i.e. one that at leasts supports what I called "individual video." Who all thinks ATM meets this need? --Jed -> http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Sat Apr 15 16:19:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 23:22:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 23:19:32 -0700 Received: from Hana.CS.UCLA.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 23:19:31 -0700 Received: by hana.cs.ucla.edu (4.1/SMI-4.1) id AA11001; Sat, 15 Apr 95 23:19:17 PDT From: yu@CS.UCLA.EDU (Yu Uny Cao) Message-Id: <9504160619.AA11001@hana.cs.ucla.edu> Subject: Audio patch for SunOS4.1.3_U1B? To: mbone Date: Sat, 15 Apr 1995 23:19:14 -0700 (PDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 602 Hi, People might be sick to death to see this question again, but I could not find the patch. I patched a kernel with 101508-06 last summer, but now at ftp://sunsolve1.sun.com/pub/patches/ I was pointed to 102161. However I was not able to find it on that site. My problem with the audio port now is that it just doesn't play. It once worked, but now it's simply dead, e.g.: uny@caledonian 34% showaudio Playing audio on caledonian using /dev/audio, one moment please... /dev/audio: No such device (probably this problem does not have anything to do with the patch anyway ) Thanks. - Uny From list-mgr@ISI.EDU Sat Apr 15 16:16:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 23:19:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 23:16:28 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 15 Apr 1995 23:16:28 -0700 Received: by rx7.ee.lbl.gov (8.6.11/1.43r) id XAA00430; Sat, 15 Apr 1995 23:16:41 -0700 Message-Id: <199504160616.XAA00430@rx7.ee.lbl.gov> To: Jon Crowcroft Cc: MBONE Subject: Re: ATM Switch cost (last 53 words) In-Reply-To: Your message of Fri, 14 Apr 95 16:00:54 BST. Date: Sat, 15 Apr 95 23:16:41 PDT From: Van Jacobson > i'd love to know from BAGNET and others how much _people time_ > has gone in to getting things working when raw IP on SONET could > have flown Jon, I'm only peripherally involved in BAGNET (at best) but my impression is that it has gone exactly the same as your SuperJANET ATM pilot. Most of the sites have invested large amounts of time in getting first IP then (a limited form of) IP multicast up and the work isn't nearly done yet. And although the performance results are slightly better than you reported, they are still pathetic: With very careful packet and cell pacing, the 155 Mb/s ATM net delivers a rousing 10-12Mb/s throughput for unicast traffic and 4-5Mb/s for multicast traffic. Considering that the one PPP-over-SONET OC-3c test I'm aware of delivered 150Mb/s IP throughput straight out the box with essentially no setup required, ATM looks pretty pathetic. The local ATM zealots claim that all the setup problems are due to lack of SVCs in the current generation of switches & all the performance problems are due to the woefully inadequate buffering in the current generation of switches. Having read Q.931, I have trouble believing the SVCs will result in easier or more robust configuration and I'd be more confident about performance improvements if I knew of even one switch vendor who understood the current problems or planned to address them in the next generation (when I've checked out vendor claims of "dramatic buffering improvements" it turns out they're talking about increasing per-port buffering from 64 cells to 512 -- almost 5% of the amount they actually need). But, since I've always heard that you learn more from failures than success, ATM seems destined to be a great teaching tool. - Van From list-mgr@ISI.EDU Sun Apr 16 13:27:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 16 Apr 1995 04:28:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 16 Apr 1995 04:27:52 -0700 Received: from sirius.brunel.ac.uk by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 16 Apr 1995 04:27:50 -0700 Received: from spare-240.brunel.ac.uk by sirius.brunel.ac.uk with SMTP (PP) id <08246-0@sirius.brunel.ac.uk>; Sun, 16 Apr 1995 12:27:21 +0100 From: Nik Clayton Message-Id: <1072.9504161127@spare-240.brunel.ac.uk> Subject: MBONE query: Picking a host/port pair To: mbone Date: Sun, 16 Apr 1995 12:27:12 +0100 (BST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 943 Hi, I'm working on a pair of programs which will be broadcasting over Brunel's local bit of the MBONE (all the packets have ttl of 16 or less, so there should be no danger of leakage to other sites). My question is, how should I pick the host/port pair that the clients and server will connect to? Is there some canonical method for doing this? Better yet, is there some FAQ which covers issues like this when programming for the MBONE? Many thanks for any advice that the members of this list can provide. Please note that I'm not a member of this list, so if any replies could be cc'd to me as well as to the list I would obviously appreciate it. Once again, many thanks, N =-[Opinion, n: See the above text for an example]=-=[Kibo #: e]-[RYRYRY]=-= =-[The Silly Sod Society: To perfect and to swerve]=-[beable]-=[TP U BG]=-= Confession is good for the soul only in the sense that a tweed coat is good for dandruff. -- Peter de Vries From list-mgr@ISI.EDU Sun Apr 16 12:10:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 16 Apr 1995 19:10:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 16 Apr 1995 19:09:40 -0700 Received: from nsipo.arc.nasa.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 16 Apr 1995 19:09:39 -0700 Received: from localhost.arc.nasa.gov by nsipo.arc.nasa.gov (8.6.11/1.5) id TAA13676; Sun, 16 Apr 1995 19:10:43 -0700 Message-Id: <199504170210.TAA13676@nsipo.arc.nasa.gov> To: jed@llnl.gov (James E. [Jed] Donnelley) Cc: mbone Subject: Re: ATM Switch cost - no high speed IP routers In-Reply-To: Your message of "Sun, 16 Apr 95 01:23:32 BST." <9504152323.AA13807@ocfmail.ocf.llnl.gov> Date: Sun, 16 Apr 95 19:10:42 -0700 From: "Milo S. Medin" (NASA Ames Research Center) Jed, my port density comment was related to the number of DS-3's that could be accomodated in one box. For example, currently, a cisco 7000 has 5 useful slots in it. Each HSSI interface requires it's own slot. Which maxes it out at 5 DS-3's. Typically, you'll want to glue this together with other routers, so you burn another slot for a LAN interface. The fastest non-ATM interface supported today is FDDI at 100 Mbps half-duplex (though DEC gear supports full duplex FDDI on switched interfaces). If you want a faster interface, your only choice is ATM (at 155 Mbps full duplex). So the lack of port density is compunded by lack of a fast interconnect bus to glue the multiple routers together (4 DS-3's at 90 Mbps each (45 in and out per interface) of offerred load = 360 Mbps, not a good fit for FDDI). So, if you want to avoid ATM in a switching system, you need high port density to avoid using LAN interconnects for routers, becuase outside of HiPPI and fiber channel, there aren't any LAN interconnect technologies out there to glue routers together. All this has occured because the vendors have in essence bet the farm on ATM technologies. This is why Cisco tells me to use a lightstream box when I comaplain about anemia in the 7000's. Now, I'm not saying it's impossible to build a reasonably working ATM switch that will deal with ATM acceptably. After all, if I have a BOX, and that BOX has links going in and links going out, it shouldn't matter if it's ATM based or a router, AS LONG AS IT DOES THE SAME THINGS with the data going through it. For example, if you build a switch with a large amount of cell buffers, and do frame by frame discard, and all the other things we're used to routers doing, then they perform in generally the same way. Now, it takes a LOT more effort to do this with ATM than raw IP, but as we say in NASA, with enough thrust, anything can fly. The BIG problem with ATM so far is that vendors have been working very hard to duplicate the mistakes of early routing vendors, and not paying attention to how high speed data flows actually work end to end, and including through switches. As a wise man once said, it's ok to make mistakes, as long as they are new ones. There are a few switches that are built like routers, and I understand they work OK. But few carriers build networks out of these devices, because they don't do CBR right, etc... On the signalling issue, this isn't really a problem as long as you want to deal with static routing. It's possible to buuild IP networks today that just use static routing internally. People tend not to do this because of various problems, but if you are willing to live with those problems, then you should be able to live with PVC's. :-) In reality, this reflects the sad state of standards in this area, and most vendors offer some proprietary implementation that handles this acceptably, though it won't work in a multivendor environment. In retrospect, we in the IP community had this problem several years ago too, with various vendors building non-interoperable routing protocols in routers. It's just repeating mistakes that have been made before. The worst problem I actually see with ATM is fundamentally it's disdain of the KISS principle. Complexity has been the source of enormous failure in multiple environments. Just look at the complete fiasco in the Unix arena, where Sun went from 4.1.3 (which can hardly be called simple) to the Sys V based Solaris which was completely unwieldly. Look at SGI which went from IRIX 4.X to 5.X, and DEC that went from Ultrix to OSF/1 (though DEC tried hard to shoot themselves in the foot like others, they unintentionally used a smaller caliber gun, unlike Sun). I can go on and on, with examples in fighter aircraft (the F-16 vs the F-15), spacecraft (Pioneer vs. Galileo), etc... Companies that ignore KISS need to have ready access to cash reserves to deal with the fiascos that always follow. Q.931, like most Telco signalling protocols is a mess - it didn't need to be. ATM congestion control is made much worse by lack of coupling with upper layer protocol transport, and lack of context about what's going on at network layer (dropping full IP frames vs pieces, and difficulty of coupling network level multicast semantics with subnet layer multicasts across the switching fabric). All of this is much more complicated than is required, and requires enormous amounts of resources to make this work, and makes the system far less robust than it needs to be. This is what people are really complaining about (in my opinion of course) when they complain about ATM. To argue that subnet layer switching is always bad is ludicrous - the ARPANET was based on subnet switching technology, and ethernet and other sorts of switching seem to work fine in IP networks. The difference is that ATM is attempting to do what IP already does, or at least some of that, and this makes it enormously complicated to interface to. Ethernet works fine because it's simple. You can get your hands around it, and it doesn't attempt to do what IP is doing. The ARPANET style X.25 networks were slaughtered by router based systems because they were a much simpler way of running IP, however, we have had to develop routing protocols that mimic a lot of the complexity that the old ARPANet system had. Building a large IP network, esp. one that's a backbone is NOT simple by any means. However, coupling that to ATM is really a pain to make work right. Too much duplication of functions between various layers - too many choices. Complexity without significant value added should always be frowned upon. None of this deals with the overhead issue of course. However, people shouldn't complain about overhead in general. The issue is what that overhead buys you. In the case of routers, using simple HDLC introduces some overhead too, but it provides a lot of benefits. PPP introduces more overhead, but also introduces more benefits. Both are successful because the cost/benefit ratio was considered favorable by their customers. People who complain about ATM overhead wouldn't be so vociferous if they viewed ATM as buying them some new functionality that they really needed and that router based systems didn't already supply. That cost/benefit ratio is much different on LAN's vs WAN's because of the high cost of WAN transmission. However, if I can get ATM service that worked reliably at 10% of the cost of a leased line, then I might be willing to put up with all the slicing and dicing. It's a straight business issue. In the end however, if vendors drop efforts in building large backbone hub routers and LAN interconnects, people will be forced into ATM out of necessity. The ironic thing is that some ATM vendors are now trying very hard to learn from the router guys (at least a couple vendors are), and then when ATM switches act just like routers, they'll claim that the core ATM architecture will have been vindicated! Even though they'll have pumped in 100X the resources to get to where IP was in the first place. Just look at Sun, who has dumped ENORMOUS amounts of resources into the Solaris cesspool just to make it work almost as reliably as 4.1.3, and now is declaring that they were right all along, and that Solaris really was the right choice. Perhaps Cisco isn't being original here, just following Sun's example. Revisionist history is great, esp. in a field where few people seem to have any corporate history of past mistakes, and the same debates that recur time after time. It's enough to make you want to go back to nuclear weapons design. :-) Thanks, Milo From list-mgr@ISI.EDU Mon Apr 17 06:00:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 16 Apr 1995 21:04:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 16 Apr 1995 21:03:31 -0700 Received: from subnet.sub.net by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 16 Apr 1995 21:03:29 -0700 Received: from wuff.mayn.sub.de by subnet.sub.net with bsmtp id <6634>; Mon, 17 Apr 1995 06:03:21 +0200 Received: by wuff.franken.de (Linux Smail3.1.29.0-pbr #14) id m0s0g8H-000wxNA; Mon, 17 Apr 95 04:01 MET DST Sender: harald@wanda1.mayn.sub.de Received: from wanda1 (harald@wanda1.mayn.sub.de [127.0.0.1]) by wanda1.mayn.sub.de (8.6.9/8.6.9) with SMTP id DAA00305 for ; Mon, 17 Apr 1995 03:59:36 +0200 Message-Id: <199504170159.DAA00305@wanda1.mayn.sub.de> From: Harald Hopfes Date: Mon, 17 Apr 1995 04:00:37 +0200 Sender: harald@wanda1.mayn.sub.de To: mbone Mime-Version: 1.0 X-Mailer: Mozilla/1.0N (X11; Linux 1.1.91 i486) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Url: file:/home/harald/html/index.html help From list-mgr@ISI.EDU Mon Apr 17 03:29:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 17 Apr 1995 10:26:46 -0700 Received: from mailgate.Cadence.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 17 Apr 1995 10:26:44 -0700 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id KAA09943 for ; Mon, 17 Apr 1995 10:26:39 -0700 Received: from shanghai.cadence.com(158.140.48.8) by mailgate.cadence.com via smap (V1.0mjr) id sma009744; Mon Apr 17 10:26:02 1995 Received: (from nadig@localhost) by shanghai.Cadence.COM (8.6.8/8.6.8) id KAA22391 for mbone-na@isi.edu; Mon, 17 Apr 1995 10:29:10 -0700 Date: Mon, 17 Apr 1995 10:29:10 -0700 From: Deepak Nadig Message-Id: <199504171729.KAA22391@shanghai.Cadence.COM> To: mbone-na Subject: MBONE connectivity using PC Hi, I am looking for information on connecting to the MBONE using a PC. In particular, Does Windows NT support multicasting ? Which sound/video cards do I need to receive MBONE audio/video ? Which video camera do I need to transmit video ? Are there any other configuration (memory) constraints ? I would appreciate any help. Thanks in advance, Deepak Nadig From list-mgr@ISI.EDU Mon Apr 17 18:36:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 17 Apr 1995 19:50:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 17 Apr 1995 19:36:43 -0700 Received: from amber.ccs.neu.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 17 Apr 1995 19:36:41 -0700 Received: from bodum.ccs.neu.edu (bodum.ccs.neu.edu [129.10.114.198]) by amber.ccs.neu.edu (8.6.10/8.6.4) with SMTP id WAA13627; Mon, 17 Apr 1995 22:36:17 -0400 Date: Mon, 17 Apr 1995 22:36:17 -0400 Message-Id: <199504180236.WAA13627@amber.ccs.neu.edu> X-Sender: ivan@ccs.neu.edu X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Nik Clayton , mbone From: ivan@ccs.neu.edu (Ivan Judson) Subject: Re: MBONE query: Picking a host/port pair ** Warning this is only advice (From a weekend of hacking on sd protocols) ** From what I can tell sd picks a single IP for a conference then uses random(?) ports for each of the media for the conference. --Ivan PS If anyone knows of a spec/description of the sd protocol, I'd like a pointer. At 12:27 PM 4/16/95 +0100, Nik Clayton wrote: >Hi, > >I'm working on a pair of programs which will be broadcasting over >Brunel's local bit of the MBONE (all the packets have ttl of 16 or less, >so there should be no danger of leakage to other sites). > >My question is, how should I pick the host/port pair that the clients >and server will connect to? Is there some canonical method for doing >this? Better yet, is there some FAQ which covers issues like this when >programming for the MBONE? > >Many thanks for any advice that the members of this list can provide. >Please note that I'm not a member of this list, so if any replies could >be cc'd to me as well as to the list I would obviously appreciate it. > >Once again, many thanks, > >N >=-[Opinion, n: See the above text for an example]=-=[Kibo #: e]-[RYRYRY]=-= >=-[The Silly Sod Society: To perfect and to swerve]=-[beable]-=[TP U BG]=-= >Confession is good for the soul only in the sense that a tweed coat is >good for dandruff. > -- Peter de Vries > > Ivan R. Judson "This is my mind; welcome to hell." Math/Computer Science ivan@ccs.neu.edu Argonne National Lab judson@mcs.anl.gov From list-mgr@ISI.EDU Tue Apr 18 14:35:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 01:31:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 01:30:51 -0700 Received: from cs.tut.fi by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 01:30:48 -0700 Received: from isosotka.cs.tut.fi (mit@isosotka.cs.tut.fi [130.230.17.14]) by cs.tut.fi (8.6.12/8.6.4) with ESMTP id LAA12571 for ; Tue, 18 Apr 1995 11:34:41 +0300 From: Tsokkinen Mikko Received: (mit@localhost) by isosotka.cs.tut.fi (8.6.10/8.6.4) id LAA14813; Tue, 18 Apr 1995 11:35:04 +0300 Date: Tue, 18 Apr 1995 11:35:04 +0300 Message-Id: <199504180835.LAA14813@isosotka.cs.tut.fi> To: mbone Subject: Multicast3.4 Patches Is this patch for sunos4.1.3_U1 included in the multicast release 3.4, if not, would it be possible is to include it into next release? If it should not be installed please explain. 101587-01 SunOS 4.1.3_U1: security patch for mfree and icmp redirect Thanks. Cheers Mikko Tsokkinen xxxxx Mit mit@cs.tut.fi "Duct tape is like the force... It has a light side, and a dark side, and it holds the universe together..." From list-mgr@ISI.EDU Tue Apr 18 01:40:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 04:44:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 04:40:47 -0700 Received: from sam.NeoSoft.com by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 04:40:45 -0700 Received: from sam-slip-h7.NeoSoft.COM (sam-slip-h7.NeoSoft.COM [198.64.81.110]) by sam.neosoft.com (8.6.10/8.6.10) with SMTP id GAA25739 for ; Tue, 18 Apr 1995 06:40:38 -0500 Date: Tue, 18 Apr 1995 06:40:38 -0500 Message-Id: <199504181140.GAA25739@sam.neosoft.com> X-Sender: channels@popmail.neosoft.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: spd@channels.com (Sean Doherty) Subject: unsubscribe unsubscribe Sean Doherty TEAM Software Houston, Texas USA spd@channels.com From list-mgr@ISI.EDU Mon Apr 17 21:29:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 12:14:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 12:10:09 -0700 Received: from sangam.ncst.ernet.in by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 12:10:05 -0700 Received: (from uucp@localhost) by sangam.ncst.ernet.in (8.6.8.1/8.6.6) with UUCP id SAA09592 for mbone@isi.edu; Mon, 17 Apr 1995 18:13:57 +0530 Received: by henna.iitd.ernet.in (4.1/SMI-4.1-MHS-7.0 ) id AA22893; Mon, 17 Apr 95 15:59:42 IST X-Organisation: Indian Institute of Technology, New Delhi. Date: Mon, 17 Apr 1995 15:59:02 +0530 (IST) From: Operator Subject: Please unsubscribe an old address To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe mbone palepu@henna.iitd.ernet.in From list-mgr@ISI.EDU Mon Apr 17 21:28:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 12:05:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 12:01:42 -0700 Received: from sangam.ncst.ernet.in by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 12:01:35 -0700 Received: (from uucp@localhost) by sangam.ncst.ernet.in (8.6.8.1/8.6.6) with UUCP id SAA09597 for mbone@isi.edu; Mon, 17 Apr 1995 18:13:58 +0530 Received: by henna.iitd.ernet.in (4.1/SMI-4.1-MHS-7.0 ) id AA22749; Mon, 17 Apr 95 15:58:53 IST X-Organisation: Indian Institute of Technology, New Delhi. Date: Mon, 17 Apr 1995 15:58:23 +0530 (IST) From: Operator To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe palepu@iitd.ernet.in From list-mgr@ISI.EDU Tue Apr 18 19:13:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 22:13:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 22:13:13 -0700 Received: from ux4.cso.uiuc.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 18 Apr 1995 22:13:12 -0700 Received: (from gbrauer@localhost) by ux4.cso.uiuc.edu (8.6.11/8.6.11) id AAA28304; Wed, 19 Apr 1995 00:13:06 -0500 From: Greg Brauer Message-Id: <199504190513.AAA28304@ux4.cso.uiuc.edu> Subject: MBONE broadcast Biological Computing Conf. To: rem-conf@es.net Date: Wed, 19 Apr 1995 00:13:05 -0500 (CDT) Cc: mbone, bcarr@uiuc.edu, gbrauer@delphi.beckman.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3458 The National Center for Supercomputing Applications and the Beckman Institute for Advanced Science and Technology are hosting the Second Workshop on Advanced Computing for Biological Imaging on April 28-29, 1995. Because of a large number of requests, I have been asked to arrange for a multicast audio/video session of the conference. This is the first MBone broadcast that I have ever attempted beyond the scope of the UIUC campus network, and I was informed by Charlie Klein, the UIUC network architect, that I should mail this list for discussion of the broadcast. We would like time from about 8:30am to 5:00pm that Friday and Saturday. I have included a copy of the tentative schedule for the conference. Please send any questions or comments to gbrauer@delphi.beckman.uiuc.edu. Thank you. Greg Brauer University of Illinois Beckman Institute Visualization Facility ------------------------------Conference Schedule------------------------------ Friday April 28, 1995 8:30 Opening Remarks Jiri Jonas, Beckman Institute for Advanced Science and Technology Larry Smarr, National Center for Supercomputing Applications Session 1: Instrumentation Integration and Control Chair: Bridget Carraghe 8:45 Real-time and reality in functional magnetic resonance imaging Paul C. Lauterbur and Clinton S. Potter, University of Illinois at Urbana Champaign 9:30 Analysis of optical images of the cortex Larry Sirovich, Yale University 10:15 Break NSCOE/MRI CAVE CRUMBS demonstration 10:45 Light microscopy Lowell Harris, Carnegie Mellon University 11:30 Time-resolved two-photon microscopy Peter So, University of Illinois at Urbana-Champaign 12:15 Lunch Tours of Beckman Institute Facilities 1:30 Near-field scanning optical microscopy: Imaging beyond the diffraction limit Robert Grober, Yale University 2:15 Panel Discussion Computing for Biological Imaging: Speculation on the Future Panelists: Larry Smarr, National Center for Supercomputing Applications Paul C. Lauterbur, University of Illinois at Urbana-Champaign Moderator: Bridget Carragher 3:00 Break CAVE Demonstration 3:30 Remote access to scientific instruments: Telemicroscopy Mark H. Ellisman, University of California at Sa Diego 4:15 Interactive Scanning Tunneling Microscopy Rachael Brady and Joseph Lyding, University of Illinois at Urbana-Champaign 5:00 Session 1: Closing Discussion Saturday April 29, 1995 Session 2: Applications Char: Clinton S. Potter 8:45 Tomography Bridget Carragher and Andrew Belmont, University of Illinois at Urbana-Champaign 9:30 Biocomputation: applying advanced computational and visualization Kelvin Montgomery, NASA Ames Biocomputation Center 10:15 reak NSCOPE/STM CAVE Demonstration 10:45 Image processing in electron microscopy: High performance computing applied to biological systems Benes L. Trus, National Institutes of Health 11:30 High performance computing in function MRI: Image Reconstrution and Registration Douglas Noll, University of Pittsburgh 12:15 Lunch with the machines (ACB) 1:30 Pattern Recognition of scanning probe microscopy and magnetic resonance imagery Ann Bouchard, Sandia National Laboratories 2:15 Cellular Decisions Robert Silver, Marine Biological Laboratory 3:00 Break CAVE CRUMBS Demonstration 3:30 Image Reconstruction Methods Zhi-Pei Liang, University of Illinois at Urbana-Champaign 4:15 Closing Discussion From list-mgr@ISI.EDU Thu Apr 20 10:36:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 20 Apr 1995 00:36:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 19 Apr 1995 23:34:29 -0700 Received: from ifi.informatik.uni-stuttgart.de by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 19 Apr 1995 23:34:26 -0700 Received: from tyranno.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Thu, 20 Apr 95 08:34:20 +0200 From: Lars Holowko Date: Thu, 20 Apr 1995 08:36:15 +0200 Message-Id: <9504200636.AA08517@tyranno.informatik.uni-stuttgart.de.informatik.uni-stuttgart.de> Received: by tyranno.informatik.uni-stuttgart.de.informatik.uni-stuttgart.de; Thu, 20 Apr 1995 08:36:15 +0200 Apparently-To: mbone MBONE seems to work fine on our HP-kernel 9.05 now. But the audio tools (vat 3.4 and nevot 3.22) don't work at all. The main window of vat pops and shows all partipicants of a session. The person that is speaking is inverted but I can't hear anything. The VU meter is empty. Sending is impossible, too (emtpy VU meter). There is no change, when I open more vat-sessions. The "Keep Audio"-button has on effect. The statistics panel of vat shows, that I receive packets. Piers O'Hanlon responded: > Are you running the LLBD audio server deamon? (it is indicated in the > /etc/netncsrc by START_LLBD line). To get vat to work I usually boot the > machine up without LLBD running (ie START_LLBD=0). There has been a patch > mentioned which allows vat to work with the LLBD libraries but I haven't > installed it. The LLBD libraries are used by some of the standard audio > facilities on the HP. > The thing that slightly worries me is that vat will make some noises with the > LLBD libraries running but they're not intelligable noises. To get vat to > generate intelligable sound has been to switch off LLBD. But since you are > getting no sound at all this odd. What audio output devices are you using - > you should be able to click between speaker, line-out and headphones - None of > these work? I killed the "NCS Local Location Broker"-process and I tried all the output devices but no change. May someone point me to the patch described by Piers? My machine is a Model 725/75 (no special hardware). Help is appreciated, Thanks, Lars From list-mgr@ISI.EDU Thu Apr 20 06:11:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 20 Apr 1995 11:10:46 -0700 Received: from ce.fciencias.unam.mx ([132.248.28.1]) by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 20 Apr 1995 11:10:45 -0700 Message-Id: <199504201810.AA16036@venera.isi.edu> Received: from standard-input by ce.fciencias.unam.mx; Thu, 20 Apr 95 12:11:16 CST Date: Thu, 20 Apr 95 12:11:16 CST From: jluis@ce.fciencias.unam.mx (Jose Luis Torres Rodriguez) Sender: jluis@ce.fciencias.unam.mx To: mbone-na Subject: Looking for connection to MBONE Hi, I am looking for information on connecting to the MBONE using a Silicon Graphics or a Sun computer. I'm working in a Iris Crimson, but without sound/video cards. And I'm working in a Sun without video card. Does this equipment support multicasting ?. How I make it this ? Which sound/video cards do I need to receive MBONE audio/video ? Which video equipment do I need to transmit video ? Are there any other configuration (memory, operating sistem, ...) constraints ? I would appreciate any help. Thanks in advance, J. Luis Torres jluis@ce.fciencias.unam.mx From list-mgr@ISI.EDU Thu Apr 20 11:07:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 20 Apr 1995 12:08:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 20 Apr 1995 12:07:59 -0700 Received: from relay.nswc.navy.mil by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 20 Apr 1995 12:07:57 -0700 Received: from sunoco (sunoco.nswc.navy.mil) by relay.nswc.navy.mil (4.1/SMI-4.1) id AA13180; Thu, 20 Apr 95 15:07:39 EDT Received: from sparhawk by sunoco (5.x/SMI-SVR4) id AA16327; Thu, 20 Apr 1995 15:07:52 -0400 Received: by sparhawk (5.x/SMI-SVR4) id AA12321; Thu, 20 Apr 1995 15:07:51 -0400 Date: Thu, 20 Apr 1995 15:07:51 -0400 From: tplunke@relay.nswc.navy.mil (Tim Plunkett) Message-Id: <9504201907.AA12321@sparhawk> To: MBONE Subject: mbone tools over dos/windows X-Sun-Charset: US-ASCII Has anyone managed to get any of the mbone tools (vat,nv,wp,etc) to work at least using unicast on a PC in a dos/windows environment? Just wondering. Tim Plunkett tplunke@relay.nswc.navy.mil From list-mgr@ISI.EDU Thu Apr 20 10:53:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 20 Apr 1995 12:53:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 20 Apr 1995 12:52:48 -0700 Received: from noc.tor.hookup.net by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 20 Apr 1995 12:52:45 -0700 Received: from [165.154.37.168] (joeclark.tor.hookup.net [165.154.37.168]) by noc.tor.hookup.net (8.6.12/1.342) with SMTP id PAA15574; Thu, 20 Apr 1995 15:52:31 -0400 X-Sender: joeclark@noc.tor.hookup.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Apr 1995 15:53:09 -0500 To: casner, dmk@research.att.com, mbone, rem-conf@es.net From: joeclark@hookup.net (Joe Clark) Subject: Doing story on MBone, need help I'm writing a general-interest story for the Toronto _Globe and Mail_ newspaper on MBone and related broadband technologies. Now, before anyone gets all annoyed at another dumb-ass reporter making a mockery of the net.community, I'll mention that I've been online ~5 years and have written dozens of stories on online topics. I don't intend to misrepresent anyone or anything here. There. That's out of the way. I feel much better. Some issues I'll be exploring in the article (or at least hope to explore-- the story may be only 600 words, rather limiting my scope): * Is the requirement to hook yourself up to two different networks (conventional IP and the related but separate MBone) to receive Internet text *and* video likely to choke interest in MBone early on? *Apart from the fact that it's whiz-bang, what are the real applications of Internet video, and who's using it? Is it in fact a frill? * At the moment, the net is a largely textual medium with a rising graphical faction (WWW); will the fact that video transmission is now possible reduce the net to a sort of postliterate personal TV network? (This isn't an exploitative question. I think one of the major advantages of the net is its reliance on text. I'm not opposed to TV and video, but I do wonder if making it easy to stuff a videoclip down the pike to Australia is a worthwhile enough goal to merit all the work on video compression, broadband, etc.) I'd love to hear from actual people working with MBone, and in particular people who have used it for some purpose in the real world. Joe Clark joeclark@hookup.net ~~~~~~~~~~~~~~~~~~~ From list-mgr@ISI.EDU Thu Apr 20 09:39:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 20 Apr 1995 14:38:26 -0700 Received: from roll.san.uc.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 20 Apr 1995 14:38:25 -0700 Received: from ucunix.san.uc.edu by UCBEH.SAN.UC.EDU (PMDF V4.3-10 #7238) id <01HPKJ83QIC08ZH9O6@UCBEH.SAN.UC.EDU>; Thu, 20 Apr 1995 17:35:22 -0500 (EST) Received: (liuzg@localhost) by ucunix.san.uc.edu (8.6.11/8.1) id NAA18841; Thu, 20 Apr 1995 13:40:19 -0400 Date: Thu, 20 Apr 1995 13:39:53 -0400 (EDT) From: Zhong Liu Subject: join to Mbone To: mbone-na Message-Id: <199504201740.NAA18841@ucunix.san.uc.edu> Mime-Version: 1.0 X-Mailer: ELM [version 2.4 PL23] Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 210 Dear Sir: I want to join to the Mbone using the Sun workstation. Could you please tell me how to do? In addition, which network provider should I contact? Your help will be highly appreciated. Zhong Liu From list-mgr@ISI.EDU Sat Apr 22 01:51:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 00:52:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 00:48:26 -0700 Received: from madang.dacom.co.kr by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 00:48:15 -0700 Received: (from nobody@localhost) by madang.dacom.co.kr (8.6.9H1/8.6.9) id QAA16593 for mbone@isi.edu; Fri, 21 Apr 1995 16:51:12 +0900 Date: Fri, 21 Apr 1995 16:51:12 +0900 Message-Id: <199504210751.QAA16593@madang.dacom.co.kr> From: dgguen@madnag.dacom.co.kr Subject: Mailing List - BBS Gateway Apparently-To: mbone [This message was sent through the WebBBS-Madang! email gateway.] -- $)C A&8q: Mailing List - BBS Gateway Hi, There is a BBS for MBONE mailing list archive from Jul 1994. THis is WWW BBS. If you want to see the old mails, You can use this BBS. BBS to Mailing list Posting also available. rem-conf mailing list archive also in this BBS. There is some Hangul(korean character), but don't mind it. The URL is http://madang.dacom.co.kr/ Have a fun! Bye. ======================================= DACOM R&D Center Multimedia Lab Guen DoGyun (dgguen@madang.dacom.co.kr) (http://madang.dacom.co.kr/) Tel: 82 042 220 4232 Fax: 82 042 220 4277 ======================================= From list-mgr@ISI.EDU Fri Apr 21 12:02:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 01:03:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 01:02:54 -0700 Received: from mons.uio.no by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 01:02:51 -0700 Received: from ulrik.uio.no by mons.uio.no with local-SMTP (PP) id <21304-0@mons.uio.no>; Fri, 21 Apr 1995 10:02:08 +0200 X-Mailer: exmh version 1.5.3 12/28/94 To: tplunke@relay.nswc.navy.mil (Tim Plunkett) Cc: MBONE Subject: Re: mbone tools over dos/windows In-Reply-To: Your message of "Thu, 20 Apr 1995 15:07:51 MET DST." <9504201907.AA12321@sparhawk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Apr 1995 10:02:05 +0200 From: Gorm Haug Eriksen Message-Id: <"mons.uio.n.318:21.03.95.08.02.15"@mons.uio.no> tplunke@relay.nswc.navy.mil (Tim Plunkett) klorte ned: -> Has anyone managed to get any of the mbone tools (vat,nv,wp,etc) to work at -> least using unicast on a PC in a dos/windows environment? Just wondering. I tested a version from ftp.nus.sg (windows alpha version), and managed to get sd and vat to work (vat had problems with pcm5 though). You will probalby need a ip-stack from ftp-software to use multicasting (PC/TCP OnNet Kernel 1.1). Cheers, Gorm Haug Eriksen USIT / UiO / Norway PS : i had trouble with nv From list-mgr@ISI.EDU Fri Apr 21 14:46:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 05:49:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 05:48:14 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 05:48:13 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 21 Apr 1995 05:47:37 -0700 Message-Id: <199504211247.AA07851@quark.isi.edu> Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 21 Apr 1995 13:47:00 +0100 X-Mailer: exmh version 1.6delta 4/7/95 From: Piers O'Hanlon Organisation: University College London, AV Dept. Phone: +44 171 636 8333 ext 3056 (Hang on in there...) To: Gorm Haug Eriksen Cc: P.OHanlon@cs.ucl.ac.uk, MBONE Subject: Re: mbone tools over dos/windows In-Reply-To: Your message of "Fri, 21 Apr 95 10:02:05 +0100." <"mons.uio.n.318:21.03.95.08.02.15"@mons.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Apr 95 13:46:57 +0100 Sender: P.OHanlon@cs.ucl.ac.uk > I tested a version from ftp.nus.sg (windows alpha version), and managed to get > sd and vat to work (vat had problems with pcm5 though). You will probalby need > a ip-stack from ftp-software to use multicasting (PC/TCP OnNet Kernel 1.1). > Which IP stack were you using? Thanks Piers O'Hanlon ______________ Audio Visual Centre University College London. From list-mgr@ISI.EDU Fri Apr 21 18:30:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 19:32:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 19:32:27 -0700 Received: from emoryu1.cc.emory.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 19:32:26 -0700 Received: from slacker.cc.emory.edu by emoryu1.cc.emory.edu (5.65/Emory_cc.4.0.1) via SMTP id AA28159 ; Fri, 21 Apr 95 22:32:16 -0400 Return-Path: cfs@unix.cc.emory.edu Received: by slacker.cc.emory.edu (5.x) id AA00638; Fri, 21 Apr 1995 22:30:38 -0400 From: "Charles Stephens" Message-Id: <9504212230.ZM636@emory.edu> Date: Fri, 21 Apr 1995 22:30:36 -0400 X-Face: $KnP{*s19DuSRq/q]TwI3tF|#oC'<@#Br9xf_9i\)h6W$u#:Y"#l":@9.gE&llW.3C(q'``8~(F[^?]EfpHB.=/k:=/>$xrne0~hA8sq*NI*nuS>.:Ux6g'E.,lvhh=f;PI4_nb?wH#5"Z7DJPzHFAP6!i:rCE*_o?q~DzqdxeXHu&QFe0}S X-Mailer: Z-Mail (3.2.1 15feb95) To: mbone Subject: SS5 audio and source to vat Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Two newbie questions: Audio in vat goes away after a while on my SS5 running Sol2.4 and Is there any sources to vat/sd/vic, etc. I don't like running these applications in binary compatability. cfs -- /-------------------\ Charles "Cyber-Buddha" Stephens | HELLO, my name is | UNIX Systems Administrator |-------------------| Network Systems/Open Systems Group, | cfs@emory.edu | Information Technology Division, | Charles Stephens | Emory University, Atlanta, Georgia, USA | | "You shall soon achieve perfection." -Fortune Cookie \-------------------/ http://userwww.service.emory.edu/~cfs From list-mgr@ISI.EDU Fri Apr 21 12:49:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 19:49:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 19:49:38 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 19:49:37 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id TAA18854; Fri, 21 Apr 1995 19:49:37 -0700 Date: Fri, 21 Apr 1995 19:49:37 -0700 From: Dino Farinacci Message-Id: <199504220249.TAA18854@stilton.cisco.com> To: mbone Subject: [Warning - IP multicast bug in 10.2] If you have any questions, send email to multicast-support@cisco.com. Dino ------------------------------------------------------------------------ Date: Fri, 21 Apr 1995 19:45:50 -0700 From: Dino Farinacci To: multicast-beta Subject: Warning - IP multicast bug in 10.2 There was a DVMRP related bug introduced in 10.2(5.1). If you use the default settings for DVMRP interaction, your entire unicast routing table will be advertised out the DVMRP discovered interfaces. This has been traditionally not good for the MBONE. This bug is also in 10.2(5.2), 10.2(5.3), and all releases after 10.3(2). The bug fix will be integrated in 10.2(5.4) and 10.3(2.4). Dino From list-mgr@ISI.EDU Fri Apr 21 13:54:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 20:55:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 20:54:52 -0700 Received: from medoc.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 20:54:50 -0700 Received: from medoc.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by medoc.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id UAA02956; Fri, 21 Apr 1995 20:54:49 -0700 From: Eric Paulos Message-Id: <199504220354.UAA02956@medoc.CS.Berkeley.EDU> To: mbone, Lars Holowko In-Reply-To: Your message of "Thu, 20 Apr 1995 08:36:15 +0200." <9504200636.AA08517@tyranno.informatik.uni-stuttgart.de.informatik.uni-stuttgart.de> Date: Fri, 21 Apr 1995 20:54:46 -0700 LH> MBONE seems to work fine on our HP-kernel 9.05 now. But the LH> audio tools (vat 3.4 and nevot 3.22) don't work at all. LH> Piers O'Hanlon responded: >> Are you running the LLBD audio server deamon? (it is indicated in >> the /etc/netncsrc by START_LLBD line). To get vat to work I >> usually boot the machine up without LLBD running (ie >> START_LLBD=0). There has been a patch mentioned which allows vat >> to work with the LLBD libraries but I haven't installed it. The >> LLBD libraries are used by some of the standard audio facilities >> on the HP. I had same this same problem here at UCB. I left LLBD running and simply executed /usr/audio/bin/make_audio_dev which immediatly created the correct audio devices and I began receiving audio in vat sessions that were already open. Sending was fixed as well. ------------------------------------------------------------------------- Eric Paulos Robotics Laboratory paulos@robotics.eecs.berkeley.edu University of California, Berkeley URL: http://robotics.eecs.berkeley.edu/~paulos/ From list-mgr@ISI.EDU Fri Apr 21 23:30:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 23:31:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 23:30:58 -0700 Received: from madang.dacom.co.kr by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 21 Apr 1995 23:30:54 -0700 Received: (from nobody@localhost) by madang.dacom.co.kr (8.6.9H1/8.6.9) id PAA19142 for mbone@isi.edu; Sat, 22 Apr 1995 15:33:56 +0900 Date: Sat, 22 Apr 1995 15:33:56 +0900 Message-Id: <199504220633.PAA19142@madang.dacom.co.kr> From: dgguen@madang.dacom.co.kr Subject: WebBBS-Madang!'s MBONE Arcive mistake. Apparently-To: mbone [This message was sent through the WebBBS-Madang! email gateway.] -- $)C A&8q: WebBBS-Madang!'s MBONE Arcive mistake. Sorry for wrong archive in MBONE mail archive BBS. I confused this archive with rem-conf. So is there a archive site of MBONR mailing list? If there is, I will convert it to my BBS(http://madang.dacom.co.kr/)). Thanks. ======================================= DACOM R&D Center Multimedia Lab Guen DoGyun (dgguen@madang.dacom.co.kr) (http://madang.dacom.co.kr/) Tel: 82 042 220 4232 Fax: 82 042 220 4277 From list-mgr@ISI.EDU Sun Apr 23 20:05:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 23 Apr 1995 09:06:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 23 Apr 1995 09:05:43 -0700 Received: from sicmail.epfl.ch by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 23 Apr 1995 09:05:42 -0700 Received: from stisun9.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <13736-0@sicmail.epfl.ch>; Sun, 23 Apr 1995 18:05:39 +0200 Received: from localhost by stisun9 (5.x/Epfl-3.1/MX) id AA15073; Sun, 23 Apr 1995 18:05:38 +0200 From: timsit@stisun9.epfl.ch (Richard Timsit) Message-Id: <9504231605.AA15073@stisun9.epfl.ch> X-Mailer: exmh version 1.5.3 12/28/94 To: MBONE Subject: Pruning efficiency ??? Mime-Version: 1.0 Content-Type: text/plain Date: Sun, 23 Apr 1995 18:05:37 +0200 Iam running the new release3.4 of mrouted with SunOS Release 4.1.3_U1. I have only one tunnel with a regional station and no tunnel on my site and pruning on. But we are receiving 1 Go every day even with no one active conference on our subnet !!! Any idea ? +-----------------------------------------------+ | ??? | | {O-O} Richard Timsit | | _^_ SIC STI | | / T \_ EPFL Lausanne | | '` I " 1015 Ecublens,SUISSE | | M (021) 693 22 35 | | | | timsit@sic.epfl.ch | | I I | +-----------------------------------------------+ From list-mgr@ISI.EDU Sun Apr 23 17:06:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 24 Apr 1995 00:08:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 24 Apr 1995 00:07:03 -0700 Received: from Maui.CS.UCLA.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 24 Apr 1995 00:06:59 -0700 Received: by maui.cs.ucla.edu (Sendmail 4.1/3.27) id AA27541; Mon, 24 Apr 95 00:06:58 PDT From: yu@CS.UCLA.EDU (Yu Uny Cao) Message-Id: <9504240706.AA27541@maui.cs.ucla.edu> Subject: simple question about sd To: mbone Date: Mon, 24 Apr 1995 00:06:58 -0700 (PDT) Cc: yu@CS.UCLA.EDU (Yu Uny Cao) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1787 Hi, My sd does not show any world event. Here is "core dump" of connections ================================== # my machine is caledonian caledonian# mrinfo localhost 127.0.0.1 (localhost.cs.ucla.edu) [version 3.4]: 131.179.96.124 -> 0.0.0.0 (?) [1/1/querier] 131.179.113.124 -> 0.0.0.0 (?) [1/1/querier] 131.179.96.124 -> 131.179.224.6 (luna.cs.ucla.edu) [1/16/tunnel] 131.179.96.124 -> 131.179.224.5 (surya.cs.ucla.edu) [1/16/tunnel] caledonian# mrinfo surya 131.179.224.5 (surya.cs.ucla.edu) [version 2.0]: 131.179.224.5 -> 131.179.224.6 (luna.cs.ucla.edu) [1/1/querier] 131.179.224.5 -> 164.67.3.5 (mbone.ucla.edu) [3/1/tunnel] 131.179.224.5 -> 131.179.96.124 (caledonian.cs.ucla.edu) [1/16/tunnel] At this moment the tunnel 131.179.224.5 -> 164.67.3.5 (mbone.ucla.edu) [3/1/tunnel/down] is down, but most of the times it's not. Problem ======= I cannot see any events in sd on my machine during the past 4 days. However, I can New a regional session and it works since I can see it from machine on different subnet. The default "MBONE audio" session does not show up either. My guess of the cause ===================== 1) surya(131.179.224.5)'s problem: 1.1) mrouted is of version 2 1.2) surya's mrouted cannot talk properly to mine (v3.4) 1.3) the following tunnel's thredshold is not right "131.179.224.5 -> 164.67.3.5 (mbone.ucla.edu) [3/1/tunnel] 2) vat doesn't run on my machine yet, which prevents sd from running properly. vat stops after spitting out "AUDIO_FLUSH: Invalid argument" Actually I need to solve that problem also. I patched kernel with ipmulti and patch 102161. showaudio runs, but vat doesn't. 3) I don't have a .sd.tcl file ( explains the "MBone session" problem?) Help. Thanks. - Yu From list-mgr@ISI.EDU Mon Apr 24 06:41:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 24 Apr 1995 07:42:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 24 Apr 1995 07:42:08 -0700 Received: from PO4.ANDREW.CMU.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 24 Apr 1995 07:42:07 -0700 Received: (from postman@localhost) by po4.andrew.cmu.edu (8.6.12/8.6.9) id KAA01817 for mbone@isi.edu; Mon, 24 Apr 1995 10:42:04 -0400 Received: via switchmail; Mon, 24 Apr 1995 10:42:03 -0400 (EDT) Received: from pcs11.andrew.cmu.edu via qmail ID ; Mon, 24 Apr 1995 10:41:37 -0400 (EDT) Received: from pcs11.andrew.cmu.edu via qmail ID ; Mon, 24 Apr 1995 10:41:35 -0400 (EDT) Received: from mms.4.60.Jan.26.1995.18.43.47.sun4c.411.EzMail.PC.2.0.CUILIB.3.45.SNAP.NOT.LINKED.pcs11.andrew.cmu.edu.sun4c.411 via MS.5.6.pcs11.andrew.cmu.edu.sun4c_411; Mon, 24 Apr 1995 10:41:32 -0400 (EDT) Message-Id: Date: Mon, 24 Apr 1995 10:41:32 -0400 (EDT) From: Ashish Bisarya To: mbone Subject: Tcpdump-3.0 Question Cc: Hi, We are trying to do a traffic analysis of the MBONE traffic. We are using tcpdump-3.0 and are having difficulties deciphering the output. If anyone has any updated documentation on tcpdump-3.0, could you give us a pointer to it? Also, we are specifically having trouble figuring out where the sequence number is located in the output. If anyone knows where this sequence number is that would be a big help. Thanks in advance, Ashish and Ming From list-mgr@ISI.EDU Mon Apr 24 17:14:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 24 Apr 1995 08:18:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 24 Apr 1995 08:18:21 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 24 Apr 1995 08:18:20 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Mon, 24 Apr 1995 08:18:19 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Apr 1995 16:16:57 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Ashish Bisarya Cc: mbone Subject: Re: Tcpdump-3.0 Question In-Reply-To: Your message of "Mon, 24 Apr 95 10:41:32 EDT." Date: Mon, 24 Apr 95 16:14:39 +0100 Message-Id: <4672.798736479@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >We are trying to do a traffic analysis of the MBONE traffic. We are >using tcpdump-3.0 and are having difficulties deciphering the output. >If anyone has any updated documentation on tcpdump-3.0, could you give >us a pointer to it? Also, we are specifically having trouble figuring >out where the sequence number is located in the output. If anyone knows >where this sequence number is that would be a big help. Mbone application traffic is basically UDP. UDP has no sequence number. Video applications generally use RTP on top of UDP. Tcpdump has no way to know that it's RTP - all it sees is UDP, so you won't see the RTP sequence numbers in tcpdump's stats - you'll have to look in the payload. See the RTP spec draft-ietf-avt-rtp-07.txt for details. Vat currently uses its own protocol on top of UDP. Again, you won't see its equivalent of sequence numbers with tcpdump. Vat actually doesn't strictly have a sequence number - it has a sample number I believe. I don't think it's described anywhere. Mark From list-mgr@ISI.EDU Mon Apr 24 11:10:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 24 Apr 1995 13:22:59 -0700 Received: from secyt.secyt.gov.ar by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 24 Apr 1995 13:22:47 -0700 Received: by secyt.gov.ar with UUCP id <17742>; Mon, 24 Apr 1995 17:14:14 -0300 Received: by funash.org.ar (UUPC/PcCorreo 3.0) with UUCP; Mon, 24 Apr 95 17:10:18 ARG Date: Mon, 24 Apr 1995 14:10:18 -0300 From: Administrador del Nodo Message-Id: <404dq459@funash.org.ar> X-Mailer: UUPC/PcCorreo 3.0 To: mbone-na Subject: >From Postmaster Mon, 24 Apr 95 13:02:21 ARG remote from funash >Received: by funash.org.ar (UUPC/PcCorreo 3.0) with UUCP; Mon, 24 Apr 95 13:02:21 ARG >Date: Mon, 24 Apr 95 13:02:21 ARG >From: Administrador del Nodo >Message-ID: <344dq462@funash.org.ar> >X-Mailer: UUPC/PcCorreo 3.0 >To: mbone-request@isi.edu > >We are interested in connecting to MBone; but unfortunately, we don't have a >network provider here in Argentina interested or with the appropiate bandwith. > >How can we overcome this difficulty, without turning ourselves into providers? >We would rather stay end-users, as we have no extra time to dedicate to >network admin. > >Thank you very much for your attention. > > =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Santiago Mangudo Escalada postmaster@funash.org.ar =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= From list-mgr@ISI.EDU Tue Apr 25 05:44:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 25 Apr 1995 06:52:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 25 Apr 1995 06:51:54 -0700 Received: from portal (portal.netedge.com) by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 25 Apr 1995 06:51:49 -0700 Received: from NetEdge.COM by portal id AA07964; Tue, 25 Apr 95 09:47:52 EDT Received: from suicidesix.NetEdge.COM by NetEdge.COM id AA29636; Tue, 25 Apr 95 09:51:30 EDT Return-Path: Received: from localhost by suicidesix.NetEdge.COM (4.1/NECL-6.14) id AA19882; Tue, 25 Apr 95 09:44:49 EDT Message-Id: <9504251344.AA19882@NetEdge.COM> To: Dino Farinacci Cc: mbone Subject: Re: [Warning - IP multicast bug in 10.2] In-Reply-To: Your message of "Fri, 21 Apr 1995 19:49:37 PDT." <199504220249.TAA18854@stilton.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <19879.798817488.1@suicidesix> Date: Tue, 25 Apr 1995 09:44:49 -0400 From: Thomas Pusateri In message <199504220249.TAA18854@stilton.cisco.com> you write: > If you have any questions, send email to multicast-support@cisco.com. > >Dino > >------------------------------------------------------------------------ > >Date: Fri, 21 Apr 1995 19:45:50 -0700 >From: Dino Farinacci >To: multicast-beta >Subject: Warning - IP multicast bug in 10.2 > > There was a DVMRP related bug introduced in 10.2(5.1). If you use > the default settings for DVMRP interaction, your entire unicast routing > table will be advertised out the DVMRP discovered interfaces. This > has been traditionally not good for the MBONE. > > This bug is also in 10.2(5.2), 10.2(5.3), and all releases after 10.3(2). > > The bug fix will be integrated in 10.2(5.4) and 10.3(2.4). > >Dino Dino, Where can I get the latest version of PIM/DVMRP for the Cisco 3000 you lent me? Thanks, Tom From list-mgr@ISI.EDU Tue Apr 25 07:45:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 25 Apr 1995 14:45:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 25 Apr 1995 14:45:13 -0700 Received: from tenet.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 25 Apr 1995 14:45:11 -0700 Received: from premise.CS.Berkeley.EDU (premise.CS.Berkeley.EDU [128.32.33.172]) by tenet.CS.Berkeley.EDU (8.6.11/8.6.6) with ESMTP id OAA24190; Tue, 25 Apr 1995 14:45:03 -0700 From: "Bruce A. Mah" Received: from premise.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by premise.CS.Berkeley.EDU (8.6.11/1.3-tenet) with ESMTP id OAA08358; Tue, 25 Apr 1995 14:45:02 -0700 Message-Id: <199504252145.OAA08358@premise.CS.Berkeley.EDU> X-Mailer: exmh version 1.5.3 12/28/94 To: Mark Handley Cc: Ashish Bisarya , mbone, bmah@tenet.CS.Berkeley.EDU Subject: Re: Tcpdump-3.0 Question In-Reply-To: Your message of "Mon, 24 Apr 1995 16:14:39 BST." <4672.798736479@cs.ucl.ac.uk> X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Apr 1995 14:45:00 -0700 Mark Handley writes: > > >We are trying to do a traffic analysis of the MBONE traffic. We are > >using tcpdump-3.0 and are having difficulties deciphering the output. > >If anyone has any updated documentation on tcpdump-3.0, could you give > >us a pointer to it? Also, we are specifically having trouble figuring > >out where the sequence number is located in the output. If anyone knows > >where this sequence number is that would be a big help. > > Mbone application traffic is basically UDP. UDP has no sequence number. > > Video applications generally use RTP on top of UDP. Tcpdump has no > way to know that it's RTP - all it sees is UDP, so you won't see the > RTP sequence numbers in tcpdump's stats - you'll have to look in the > payload. See the RTP spec draft-ietf-avt-rtp-07.txt for details. Try: tcpdump -T rtp to get the stuff out of the RTP header. In general, the man page is a good source of documentation (don't remember if that little tidbit about RTP is in there tho'). If you want to know exactly what it's printing out (w.r.t the RTP header), look in the source code, with a copy of the RTP spec handy. Good luck, Bruce. From list-mgr@ISI.EDU Wed Apr 26 07:46:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 26 Apr 1995 14:47:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 26 Apr 1995 14:47:02 -0700 Received: from hp.com by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 26 Apr 1995 14:47:00 -0700 Received: from hpindlm.cup.hp.com by hp.com with ESMTP (1.37.109.15/15.5+ECS 3.3) id AA177862818; Wed, 26 Apr 1995 14:46:59 -0700 Received: by hpindlm.cup.hp.com (1.37.109.16/15.5+IOS 3.20+cup+OMrelay) id AA069042816; Wed, 26 Apr 1995 14:46:56 -0700 From: Ming Ming Chen Message-Id: <199504262146.AA069042816@hpindlm.cup.hp.com> Subject: Re: Imminent 3.5 multicast release To: fenner@parc.xerox.com (Bill Fenner) Date: Wed, 26 Apr 95 14:46:56 PDT Cc: mbone In-Reply-To: <95Mar20.190458pst.49859@crevenia.parc.xerox.com>; from "Bill Fenner" at Mar 20, 95 7:04 pm Mailer: Elm [revision: 70.85] Hi Bill, > > Folks, > > The 3.5 multicast release (kernel & mrouted) is progressing smoothly, and > should be available about a week after IETF. Here is a list of features/ > bugfixes in the new release. If your favorite bug is not there, let me know > and I will see what I can do about it. If your favorite bug/feature *is* > there, volunteer to test it out for me; I will need some help testing some > of these. > > Note the bracketed comment about potential shaving of the feature list. > > Bill > Could you update us the status and schedule of 3.5 release? Thanks Ming |Ming Ming Chen Hewlett Packard | |Information Network Division 19410 Homestead Road | |mchen@hpindlm.cup.hp.com Cupertino, CA 95014 | |408-447-2357 Mail Stop: 43LM | |_____________________________________________________________________________| From list-mgr@ISI.EDU Wed Apr 26 08:44:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Apr 1995 15:44:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Apr 1995 15:44:32 -0700 Received: from otter (otter.Stanford.EDU) by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 26 Apr 1995 15:44:31 -0700 Received: by otter (NX5.67c/inc-1.0) id AA04635; Wed, 26 Apr 95 15:44:29 -0700 Date: Wed, 26 Apr 95 15:44:29 -0700 From: xinwei@otter.stanford.edu (Sha Xin Wei) Message-Id: <9504262244.AA04635@otter> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: mbone Subject: non-X MBONE > Can one obtain MBONE for NeXTSTEP or Mac? > Where? Any tips on porting MBONE to NeXTSTEP 3.x? --- Sha Xin Wei mathematics and scientific simulations distributed media mail: Academic Software Development Sweet Hall 415 Stanford University Stanford CA 94305-3090 USA telephone: 415/725-3152 (work,msg) 415/725-8240 (fax) internet: xinwei@jessica.stanford.edu nextmail: xinwei@otter.stanford.edu www url: http://www-leland.stanford.edu/~xinwei From list-mgr@ISI.EDU Thu Apr 27 03:24:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 27 Apr 1995 10:25:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 27 Apr 1995 10:25:14 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 27 Apr 1995 10:25:13 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14425(1)>; Thu, 27 Apr 1995 10:25:02 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Thu, 27 Apr 1995 10:24:49 -0700 X-Mailer: exmh version 1.6 4/21/95 To: xinwei@otter.stanford.edu (Sha Xin Wei) Cc: mbone, grio@next.com Subject: Re: non-X MBONE In-Reply-To: Your message of "Wed, 26 Apr 95 15:44:29 PDT." <9504262244.AA04635@otter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Apr 1995 10:24:39 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Apr27.102449pdt.49859@crevenia.parc.xerox.com> In message <9504262244.AA04635@otter> you write: > > Can one obtain MBONE for NeXTSTEP or Mac? > > Where? Any tips on porting MBONE to NeXTSTEP 3.x? NeXTStep 3.3 has the host multicast extensions. I know of no current work on porting any MBONE applications. Bill From list-mgr@ISI.EDU Thu Apr 27 03:38:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 27 Apr 1995 10:39:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 27 Apr 1995 10:39:04 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 27 Apr 1995 10:39:02 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14447(4)>; Thu, 27 Apr 1995 10:38:56 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Thu, 27 Apr 1995 10:38:46 -0700 X-Mailer: exmh version 1.6 4/21/95 To: Ming Ming Chen Cc: mbone Subject: Re: Imminent 3.5 multicast release In-Reply-To: Your message of "Wed, 26 Apr 95 14:46:56 PDT." <199504262146.AA069042816@hpindlm.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Apr 1995 10:38:43 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Apr27.103846pdt.49859@crevenia.parc.xerox.com> In message <199504262146.AA069042816@hpindlm.cup.hp.com> you write: >Could you update us the status and schedule of 3.5 release? Not surprisingly, some unexpected bugs have delayed the release. I am pretty sure that I squashed the last one last night, so I expect to be able to release early next week. Vendors and/or others with OS sources are welcome to contact me for pre-releases for porting purposes. Bill From list-mgr@ISI.EDU Thu Apr 27 14:17:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 27 Apr 1995 15:16:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 27 Apr 1995 15:16:26 -0700 Received: from davinci.gmu.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 27 Apr 1995 15:16:24 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id SAA04353; Thu, 27 Apr 1995 18:17:31 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199504272217.SAA04353@davinci.gmu.edu> Subject: ftp home of wb record To: mbone Date: Thu, 27 Apr 1995 18:17:31 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 260 I have lost the home of wb_record. Does anyone know where this is? Michael -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Fri Apr 28 08:57:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 28 Apr 1995 10:00:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 28 Apr 1995 09:58:03 -0700 Received: from cerc.wvu.edu (cathedral.cerc.wvu.edu) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 28 Apr 1995 09:58:01 -0700 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA08031; Fri, 28 Apr 95 12:57:55 EDT Received: by elk (5.0//ident-1.0) id AA05076; Fri, 28 Apr 1995 12:57:53 -0400 Date: Fri, 28 Apr 1995 12:57:51 -0400 (EDT) From: "Todd L. Montgomery" Subject: An invitation to join a new discussion group (fwd) To: rmp@tenet.icsi.berkeley.edu, mbone, rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2889 I apologize to anyone who has seen this announcement before or who receives this multiple times. John Phelps has been kind enough to set up a mailing list for discussion of the Reliable Multicast Protocol (RMP). However, the forum is very open to discussion about other reliable multicast issues and schemes, including protocol verification and potential projects. Included below is John's instructions for joining the list and the list description. I look forward to participating in the discussions! -- Todd ---------- Forwarded message ---------- Date: Fri, 28 Apr 1995 07:20:00 -0400 (EDT) From: John Phelps To: gscott@mariah.jhuapl.edu, karasik@mariah.jhuapl.edu, whetten@icsi.berkeley.edu, tmont@cerc.wvu.edu, jgf@mariah.jhuapl.edu Subject: An invitation to join a new discussion group I've taken the liberty of setting up another majordomo list to provide an open forum and question/answer line between us and the developers of RMP. The only person that has been `auto-subscribed' has been your's truly so if you'd like to join in on the fun send email to majordomo@aurora.jhuapl.edu with any subject and a body of: subscribe rmp-discuss For user's that may be new to majordomo, add the following: help lists who rmp-discuss For those of you that I've taken by suprise: RMP == Reliable Multicast Protocol -- John Phelps, jbp@aurora.jhuapl.edu OR jbp@raven.jhuapl.edu Welcome to the RMP Discussion List! First, I would like to thank John Phelps for setting this list up. A short description: This mailing list is aimed at providing a forum for discussion of reliable multicast protocols in general, and of the Reliable Multicast Protocol (RMP) more specifically. The goals of this discussion list are: 1) Provide Brian Whetten, Jack Callahan, and Todd Montgomery with feedback and bug reports on the RMP protocol, library, and examples 2) Stimulate discussion on Reliable Multicast Protocols in general, such as whiteboard and other schemes 3) Bounce around ideas for reliable multicast projects and provide intellectual stimulation geared towards this exciting area of distributed computing 4) Coordinate Wide Area tests among RMP users 5) Provide a forum where people can share their experiences, good or bad, with RMP and other reliable multicast schemes 6) Discuss RMP protocol verification activities 7) Some more specific topics of interest: Multicast group flow and congestion control schemes Virtual Synchronous execution model(s) Enhancements/Problems for RMP Ideas for projects using RMP RMP Protocol Verification activites -- Todd Montgomery tmont@cerc.wvu.edu Other RMP Information Sources: http://research.ivv.nasa.gov/projects/RMP/RMP.html ftp://research.ivv.nasa.gov/pub/doc/RMP ftp://research.ivv.nasa.gov/pub/src/RMP From list-mgr@ISI.EDU Mon May 1 01:59:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 29 Apr 1995 21:58:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 29 Apr 1995 21:58:20 -0700 Received: from nova.ballarat.EDU.AU by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 29 Apr 1995 21:58:06 -0700 Received: by nova.ballarat.edu.au (5.0/SMI-SVR4) id AA19546; Sun, 30 Apr 1995 15:59:51 --1000 Date: Sun, 30 Apr 1995 15:59:51 --1000 From: cc7bmk@nova.ballarat.edu.au (Benjamin Kellas) Message-Id: <9504300559.AA19546@nova.ballarat.edu.au> Content-Type: text Content-Length: 1014 Apparently-To: mbone Hello! We are two computing students who, as part of our final year, must complete a major programming project. We are very interested in multi-casting and its applications. We were wondering if anybody would be able to suggest/recommend a suitable project that we could develop over the course of this year. We would prefer to develop an application for Unix, however a Windows application would also be acceptable. As we are new to the whole concept of multi-casting etc., a suitable project would be one that we learn from as well as producing something worth while, so working under the guidance or in co-operation with a team of people experienced in this field would also be advantageous. All and any suggestions considered. Thanks in advance, Craig Hingston & Ben Kellas (Final year computing students, University of Ballarat, Victoria, Australia) Email: cc7cbh@nova.ballarat.edu.au (Craig) cc7bmk@nova.ballarat.edu.au (Ben) From list-mgr@ISI.EDU Sun Apr 30 17:18:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 00:18:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 00:18:17 -0700 Received: from Maui.CS.UCLA.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 1 May 1995 00:18:16 -0700 Received: by maui.cs.ucla.edu (Sendmail 4.1/3.27) id AA08028; Mon, 1 May 95 00:18:15 PDT From: yu@CS.UCLA.EDU (Yu Uny Cao) Message-Id: <9505010718.AA08028@maui.cs.ucla.edu> Subject: WinNV/Vat/SD and TrumpetTCP To: mbone Date: Mon, 1 May 1995 00:18:14 -0700 (PDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 327 Hi, I tried to use WinSd/Vat/NV. It complains "Cannot bind socket". Does this mean that the programs do not work with the TCP suite I have ( TCP from Trumpet) ? In general, where can I find out where the problem is at -- windows is quite different from UNIX. I cannot read something like a man page. Thanks. - Yu From list-mgr@ISI.EDU Mon May 1 05:27:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 06:29:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 06:28:46 -0700 Received: from thepoint.net (dg.thepoint.net) by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 1 May 1995 06:28:44 -0700 Received: by thepoint.net (5.4R3.00/) id AA13623; Mon, 1 May 1995 09:27:05 -0400 Date: Mon, 1 May 1995 09:27:05 -0400 (EDT) From: Arlie Davis Subject: Re: WinNV/Vat/SD and TrumpetTCP To: Yu Uny Cao Cc: mbone In-Reply-To: <9505010718.AA08028@maui.cs.ucla.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Hi, > > I tried to use WinSd/Vat/NV. It complains "Cannot bind socket". Does this > mean that the programs do not work with the TCP suite I have ( TCP from Trumpet) > ? In general, where can I find out where the problem is at -- windows is > quite different from UNIX. I cannot read something like a man page. > > Thanks. It means that your TCP/IP stack does not support the multicast extensions. I had, but lost, the mcast extensions for the Microsoft 32-bit stack (any pointers, anyone?). I'm told that mcast works correctly with Microsoft's stack + extensions, and that FTP Software's mcast kernel works, also. I don't think Trumpet will support mcast in the near future. I could be wrong, though -- I would LIKE to be wrong in this case. -- arlie From list-mgr@ISI.EDU Mon May 1 06:12:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 07:24:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 07:24:05 -0700 Received: from davinci.gmu.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 1 May 1995 07:24:03 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id KAA11455; Mon, 1 May 1995 10:12:33 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199505011412.KAA11455@davinci.gmu.edu> Subject: Re: WinNV/Vat/SD and TrumpetTCP To: yu@CS.UCLA.EDU (Yu Uny Cao) Date: Mon, 1 May 1995 10:12:29 -0400 (EDT) Cc: mbone In-Reply-To: <9505010718.AA08028@maui.cs.ucla.edu> from "Yu Uny Cao" at May 1, 95 00:18:14 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1064 It appears the the WindSd/Vat/NV from University of Singapore requires a multicasting stack that is completely complient with FTP's OnNet stack. (I believe that product is owned by ftp). I have talked with NUS and so far they are not working on a version to be compatible with other stacks. Just to let you know -- Windows 9x will supposidly contain the stack from Wolverine which is multicast compatible. However, this still is still not compatible with OnNet. What the actual differences are, I don't know. Michael > > Hi, > > I tried to use WinSd/Vat/NV. It complains "Cannot bind socket". Does this > mean that the programs do not work with the TCP suite I have ( TCP from Trumpet) > ? In general, where can I find out where the problem is at -- windows is > quite different from UNIX. I cannot read something like a man page. > > Thanks. > > - Yu > -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Mon May 1 21:17:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 08:19:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 08:19:23 -0700 Received: from cardhu.cs.hut.fi (laphroaig.cs.hut.fi) by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 1 May 1995 08:19:12 -0700 Received: by cardhu.cs.hut.fi id AA06125 (5.65c8/HUTCS-C 1.3 for mbone@ISI.EDU); Mon, 1 May 1995 18:17:46 +0300 Date: Mon, 1 May 1995 18:17:46 +0300 From: Sami-Jaakko Tikka Message-Id: <199505011517.AA06125@cardhu.cs.hut.fi> To: mbenson@davinci.gmu.edu (Michael Benson) Cc: yu@CS.UCLA.EDU (Yu Uny Cao), mbone Subject: Re: WinNV/Vat/SD and TrumpetTCP In-Reply-To: <199505011412.KAA11455@davinci.gmu.edu> References: <9505010718.AA08028@maui.cs.ucla.edu> <199505011412.KAA11455@davinci.gmu.edu> >>>>> "Michael" == Michael Benson writes: Michael> Just to let you know -- Windows 9x will supposidly contain Michael> the stack from Wolverine which is multicast compatible. Michael> However, this still is still not compatible with OnNet. What Michael> the actual differences are, I don't know. At WWW'95 there was a guy from Microsoft (head of network technologies of Win95, or something like that) and he was asked if Win95 supports multicast. He answered: "No". -- Sami Tikka home page = http://www.cs.hut.fi/%7Esti/ "Peace and Long Life." "Live Long and Prosper." From list-mgr@ISI.EDU Mon May 1 07:31:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 08:31:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 08:30:42 -0700 Received: from davinci.gmu.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 1 May 1995 08:30:41 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id LAA12145; Mon, 1 May 1995 11:31:14 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199505011531.LAA12145@davinci.gmu.edu> Subject: Re: WinNV/Vat/SD and TrumpetTCP To: sami.tikka@research.nokia.com Date: Mon, 1 May 1995 11:31:10 -0400 (EDT) Cc: mbone In-Reply-To: <199505011509.AA06099@cardhu.cs.hut.fi> from "Sami-Jaakko Tikka" at May 1, 95 06:09:00 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1078 I am not sure where you can find more information on the multicasting aspects of Wolverine or Win95. Perhaps someone here can tell us if it is in the development kit? Are there needed extensions or does it come out of box? Where can documentation be found? Michael > > >>>>> "Michael" == Michael Benson writes: > > Michael> Just to let you know -- Windows 9x will supposidly contain > Michael> the stack from Wolverine which is multicast compatible. > Michael> However, this still is still not compatible with OnNet. What > Michael> the actual differences are, I don't know. > > Where can one find out more about the multicast features of Wolverine? > Is multicast supported right out of the box or does one have to buy > some extensions? > > -- > Sami Tikka > home page = http://www.cs.hut.fi/%7Esti/ > "Peace and Long Life." > "Live Long and Prosper." > -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Mon May 1 17:25:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 08:31:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 08:30:44 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 1 May 1995 08:30:43 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Mon, 1 May 1995 08:30:10 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 1 May 1995 16:25:57 +0100 To: Sami-Jaakko Tikka Cc: mbenson@davinci.gmu.edu (Michael Benson), yu@CS.UCLA.EDU (Yu Uny Cao), mbone Subject: Re: WinNV/Vat/SD and TrumpetTCP In-Reply-To: Your message of "Mon, 01 May 95 18:17:46 +0200." <199505011517.AA06125@cardhu.cs.hut.fi> Date: Mon, 01 May 95 16:25:53 +0100 Message-Id: <2168.799341953@cs.ucl.ac.uk> From: Jon Crowcroft >At WWW'95 there was a guy from Microsoft (head of network technologies >of Win95, or something like that) and he was asked if Win95 supports >multicast. He answered: "No". Sami well he was wrong - i've used it. what can you expect? :-) jon From list-mgr@ISI.EDU Mon May 1 06:37:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 13:38:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 13:37:29 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 1 May 1995 13:37:27 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id NAA23352; Mon, 1 May 1995 13:37:27 -0700 Date: Mon, 1 May 1995 13:37:27 -0700 From: Dino Farinacci Message-Id: <199505012037.NAA23352@stilton.cisco.com> To: mbone Subject: [nitin@cisco.com: 10.3(2.4) images now available] This is the 10.3 release that fixes the MBONE regression problem. Dino ------------------------------------------------------------------------ From: Nitin Dandia |||||||| vvvvvvvv Subject: 10.3(2.4) images now available ^^^^^^^^ |||||||| To: alaska-notification@cisco.com, build-notify@cisco.com Date: Mon, 1 May 95 13:24:43 PDT Cc: nitin@cisco.com (Nitin Dandia) X-Mailer: ELM [version 2.3 PL11] Files can be found at: ====================== /release/103/bin/103-2.4 Images /release/103/sun/103-2.4 Unstripped images /release/103/sym/103-2.4 Symbol tables *** New ROM monitors for this release *** Please reference /release/romreq/Docs/ROMreq.ROMlist for the latest ROM Monitors. Microcode bundled in for 7000: =============================== sp10-9 ssp10-9 eip10-1 trip10-1 fip10-2 hip10-2 fsip10-7 mip176-3 aip174-4 cip176-1 Microcode bundled in for SRS: =============================== sp10-9 trip10-1 fip10-2 Image data sizes are as follows: ================================ -rwxrwxr-x 1 nitin 2454584 Apr 26 19:32 c1000-h-m.103-2.4 -rwxrwxr-x 1 nitin 881296 Apr 26 19:33 c1000-rboot-r.103-2.4 -rwxrwxr-x 1 nitin 1927720 Apr 26 19:33 c1000-y-m.103-2.4 -rwxrwxr-x 1 nitin 3015823 Apr 26 19:59 c4500-boot-m.103-2.4 -rwxrwxr-x 1 nitin 5375119 Apr 26 19:53 c4500-d-m.103-2.4 -rwxrwxr-x 1 nitin 6161551 Apr 26 19:54 c4500-dr-m.103-2.4 -rwxrwxr-x 1 nitin 4326543 Apr 26 19:55 c4500-i-m.103-2.4 -rwxrwxr-x 1 nitin 4785295 Apr 26 19:56 c4500-in-m.103-2.4 -rwxrwxr-x 1 nitin 5571727 Apr 26 19:57 c4500-inr-m.103-2.4 -rwxrwxr-x 1 nitin 5112975 Apr 26 19:58 c4500-ir-m.103-2.4 -rwxrwxr-x 1 nitin 7341199 Apr 26 19:51 c4500-j-m.103-2.4 -rwxrwxr-x 1 nitin 3531036 Apr 26 19:34 cs3-c-m.103-2.4 -rwxrwxr-x 1 nitin 2814680 Apr 26 19:51 cs500-c-m.103-2.4 -rwxrwxr-x 1 nitin 5122412 Apr 26 19:33 gs3-k-m.103-2.4 -rwxrwxr-x 1 nitin 3284722 Apr 26 19:35 gs7-k-mz.103-2.4 -rwxrwxr-x 1 nitin 1441621 Apr 26 19:36 gs7-s-mz.103-2.4 -rwxrwxr-x 1 nitin 1922532 Apr 26 19:50 igs-boot-r.103-2.4 -rwxrwxr-x 1 nitin 3628020 Apr 26 19:43 igs-c-l.103-2.4 -rwxrwxr-x 1 nitin 3874092 Apr 26 19:45 igs-d-l.103-2.4 -rwxrwxr-x 1 nitin 4515164 Apr 26 19:45 igs-dr-l.103-2.4 -rwxrwxr-x 1 nitin 2772204 Apr 26 19:46 igs-f-l.103-2.4 -rwxrwxr-x 1 nitin 2938352 Apr 26 19:47 igs-g-l.103-2.4 -rwxrwxr-x 1 nitin 3016140 Apr 26 19:47 igs-i-l.103-2.4 -rwxrwxr-x 1 nitin 3375892 Apr 26 19:48 igs-in-l.103-2.4 -rwxrwxr-x 1 nitin 4016972 Apr 26 19:49 igs-inr-l.103-2.4 -rwxrwxr-x 1 nitin 3657216 Apr 26 19:49 igs-ir-l.103-2.4 -rwxrwxr-x 1 nitin 5421904 Apr 26 19:43 igs-j-l.103-2.4 -rwxrwxr-x 1 nitin 2113460 Apr 26 19:42 xx-boot-r.103-2.4 -rwxrwxr-x 1 nitin 1880367 Apr 26 19:38 xx-d-mz.103-2.4 -rwxrwxr-x 1 nitin 2165722 Apr 26 19:38 xx-dr-mz.103-2.4 -rwxrwxr-x 1 nitin 1497482 Apr 26 19:39 xx-i-mz.103-2.4 -rwxrwxr-x 1 nitin 1666851 Apr 26 19:40 xx-in-mz.103-2.4 -rwxrwxr-x 1 nitin 1952271 Apr 26 19:41 xx-inr-mz.103-2.4 -rwxrwxr-x 1 nitin 1782998 Apr 26 19:41 xx-ir-mz.103-2.4 -rwxrwxr-x 1 nitin 2566624 Apr 26 19:37 xx-j-mz.103-2.4 c1000-h-m.103-2.4 ----------------- text data bss dec hex 2400544 54008 165740 2620292 27fb84 c1000-y-m.103-2.4 ----------------- text data bss dec hex 1877396 50292 146220 2073908 1fa534 c1000-rboot-r.103-2.4 --------------------- text data bss dec hex 854200 27064 76204 957468 e9c1c gs3-k-m.103-2.4 --------------- text data bss dec hex 5013460 108920 263996 5386376 523088 cs3-c-m.103-2.4 --------------- text data bss dec hex 3460372 70632 189896 3720900 38c6c4 gs7-k-mz.103-2.4 ---------------- text data bss dec hex 8348 3276342 165020 3449710 34a36e gs7-s-mz.103-2.4 ---------------- text data bss dec hex 8348 1433241 165008 1606597 1883c5 xx-j-mz.103-2.4 --------------- text data bss dec hex 8348 2558244 165020 2731612 29ae5c xx-d-mz.103-2.4 --------------- text data bss dec hex 8348 1871987 165008 2045343 1f359f xx-dr-mz.103-2.4 ---------------- text data bss dec hex 8348 2157342 165012 2330702 23904e xx-i-mz.103-2.4 --------------- text data bss dec hex 8348 1489102 165012 1662462 195dfe xx-in-mz.103-2.4 ---------------- text data bss dec hex 8348 1658471 165020 1831839 1bf39f xx-inr-mz.103-2.4 ----------------- text data bss dec hex 8348 1943891 165012 2117251 204e83 xx-ir-mz.103-2.4 ---------------- text data bss dec hex 8348 1774618 165020 1947986 1db952 xx-boot-r.103-2.4 ----------------- text data bss dec hex 2060124 53304 262652 2376080 244190 igs-c-l.103-2.4 --------------- text data bss dec hex 3558260 69728 182392 3810380 3a244c igs-j-l.103-2.4 --------------- text data bss dec hex 5291208 130664 266752 5688624 56cd30 igs-d-l.103-2.4 --------------- text data bss dec hex 3800404 73656 237796 4111856 3ebdf0 igs-dr-l.103-2.4 ---------------- text data bss dec hex 4415864 99268 251636 4766768 48bc30 igs-f-l.103-2.4 --------------- text data bss dec hex 2701860 70312 150568 2922740 2c98f4 igs-g-l.103-2.4 --------------- text data bss dec hex 2878260 60060 201336 3139656 2fe848 igs-i-l.103-2.4 --------------- text data bss dec hex 2951240 64868 215136 3231244 314e0c igs-in-l.103-2.4 ---------------- text data bss dec hex 3308208 67652 228024 3603884 36fdac igs-inr-l.103-2.4 ----------------- text data bss dec hex 3923672 93268 241864 4258804 40fbf4 igs-ir-l.103-2.4 ---------------- text data bss dec hex 3566700 90484 228976 3886160 3b4c50 igs-boot-r.103-2.4 ------------------ text data bss dec hex 1871856 50644 160384 2082884 1fc844 cs500-c-m.103-2.4 ----------------- text data bss dec hex 2755044 59604 154108 2968756 2d4cb4 c4500-j-m.103-2.4 ----------------- size: /reln/103tmp/bin/c4500-j-m.103-2.4 not an object file c4500-d-m.103-2.4 ----------------- size: /reln/103tmp/bin/c4500-d-m.103-2.4 not an object file c4500-dr-m.103-2.4 ------------------ size: /reln/103tmp/bin/c4500-dr-m.103-2.4 not an object file c4500-i-m.103-2.4 ----------------- size: /reln/103tmp/bin/c4500-i-m.103-2.4 not an object file c4500-in-m.103-2.4 ------------------ size: /reln/103tmp/bin/c4500-in-m.103-2.4 not an object file c4500-inr-m.103-2.4 ------------------- size: /reln/103tmp/bin/c4500-inr-m.103-2.4 not an object file c4500-ir-m.103-2.4 ------------------ size: /reln/103tmp/bin/c4500-ir-m.103-2.4 not an object file c4500-boot-m.103-2.4 -------------------- size: /reln/103tmp/bin/c4500-boot-m.103-2.4 not an object file From list-mgr@ISI.EDU Mon May 1 12:52:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 19:56:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 1 May 1995 19:52:18 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 1 May 1995 19:52:15 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id TAA03972; Mon, 1 May 1995 19:52:15 -0700 Date: Mon, 1 May 1995 19:52:15 -0700 From: Dino Farinacci Message-Id: <199505020252.TAA03972@stilton.cisco.com> To: mbone Subject: [rchiao@cisco.com: 10.2(5.5) images are now available] Here is the 10.2 release with the fix for the MBONE regression problem. Dino ------------------------------------------------------------------------ From: Ron Chiao |||||||| vvvvvvvv Subject: 10.2(5.5) images are now available ^^^^^^^^ |||||||| To: build-notify@cisco.com, nac1@cisco.com, pwillets@cisco.com, rchiao@cisco.com Date: Mon, 1 May 1995 19:17:01 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 8985 Files can be found at: ====================== /relx/102/bin/102-5.5 Images /relx/102/sun/102-5.5 Unstripped images /relx/102/sym/102-5.5 Symbol tables *** New ROM monitors for this release *** Please reference /release/romreq/Docs/ROMreq.ROMlist for the latest ROM Monitors. Microcode bundled in for 7000: =============================== sp178-3 ssp178-3 eip10-1 trip10-1 fip10-2 hip10-2 fsip10-7 mip10-4 aip174-2 cip176-1 Microcode bundled in for SRS: =============================== sp10-8 trip10-1 fip10-2 Image data sizes are as follows: ================================ -rwxrwx--- 1 nitin 5833871 Apr 25 13:44 c4500-bpx.102-5.5 -rwxrwx--- 1 nitin 4850831 Apr 25 13:46 c4500-d-m.102-5.5 -rwxrwx--- 1 nitin 4850831 Apr 25 13:49 c4500-dr-m.102-5.5 -rwxrwx--- 1 nitin 4129935 Apr 25 13:51 c4500-i-m.102-5.5 -rwxrwx--- 1 nitin 4326543 Apr 25 13:53 c4500-in-m.102-5.5 -rwxrwx--- 1 nitin 4392079 Apr 25 13:55 c4500-inr-m.102-5.5 -rwxrwx--- 1 nitin 4129935 Apr 25 13:57 c4500-ir-m.102-5.5 -rwxrwx--- 1 nitin 2425999 Apr 25 13:58 c4500-xboot.102-5.5 -rwxrwx--- 1 nitin 3131056 Apr 25 15:05 cs3-k.102-5.5 -rwxrwx--- 1 nitin 2468116 Apr 25 14:45 cs500-k.102-5.5 -rwxrwx--- 1 nitin 4133756 Apr 25 15:01 gs3-k.102-5.5 -rwxrwx--- 1 nitin 5327952 Apr 25 12:47 gs7-k.102-5.5 -rwxrwx--- 1 nitin 2658200 Apr 25 12:49 gs7-s-m.102-5.5 -rwxrwx--- 1 nitin 4475732 Apr 25 14:21 igs-bpx-l.102-5.5 -rwxrwx--- 1 nitin 3237676 Apr 25 14:18 igs-c-l.102-5.5 -rwxrwx--- 1 nitin 3702184 Apr 25 14:23 igs-d-l.102-5.5 -rwxrwx--- 1 nitin 3719416 Apr 25 14:25 igs-dr-l.102-5.5 -rwxrwx--- 1 nitin 2235128 Apr 25 14:15 igs-f-l.102-5.5 -rwxrwx--- 1 nitin 2564516 Apr 25 14:26 igs-g-l.102-5.5 -rwxrwx--- 1 nitin 3050416 Apr 25 14:28 igs-i-l.102-5.5 -rwxrwx--- 1 nitin 3234088 Apr 25 14:30 igs-in-l.102-5.5 -rwxrwx--- 1 nitin 3251324 Apr 25 14:32 igs-inr-l.102-5.5 -rwxrwx--- 1 nitin 3067648 Apr 25 14:34 igs-ir-l.102-5.5 -rwxrwx--- 1 nitin 4174296 Apr 25 14:13 igs-k-l.102-5.5 -rwxrwx--- 1 nitin 1705420 Apr 25 14:35 igs-rxboot.102-5.5 -rwxrwx--- 1 nitin 53 Apr 20 06:19 md5.c4500-bpx.102-5.4 -rwxrwx--- 1 nitin 53 Apr 20 06:20 md5.c4500-d-m.102-5.4 -rwxrwx--- 1 nitin 54 Apr 20 06:21 md5.c4500-dr-m.102-5.4 -rwxrwx--- 1 nitin 53 Apr 20 06:22 md5.c4500-i-m.102-5.4 -rwxrwx--- 1 nitin 54 Apr 20 06:22 md5.c4500-in-m.102-5.4 -rwxrwx--- 1 nitin 55 Apr 20 06:23 md5.c4500-inr-m.102-5.4 -rwxrwx--- 1 nitin 54 Apr 20 06:23 md5.c4500-ir-m.102-5.4 -rwxrwx--- 1 nitin 49 Apr 20 06:25 md5.cs3-k.102-5.4 -rwxrwx--- 1 nitin 51 Apr 20 06:24 md5.cs500-k.102-5.4 -rwxrwx--- 1 nitin 49 Apr 20 06:25 md5.gs3-k.102-5.4 -rwxrwx--- 1 nitin 49 Apr 20 06:26 md5.gs7-k.102-5.4 -rwxrwx--- 1 nitin 51 Apr 20 06:27 md5.igs-bpx-l.102-5.4 -rwxrwx--- 1 nitin 49 Apr 20 06:29 md5.igs-c-l.102-5.4 -rwxrwx--- 1 nitin 49 Apr 20 06:29 md5.igs-d-l.102-5.4 -rwxrwx--- 1 nitin 50 Apr 20 06:30 md5.igs-dr-l.102-5.4 -rwxrwx--- 1 nitin 49 Apr 20 06:30 md5.igs-f-l.102-5.4 -rwxrwx--- 1 nitin 49 Apr 20 06:31 md5.igs-g-l.102-5.4 -rwxrwx--- 1 nitin 49 Apr 20 06:31 md5.igs-i-l.102-5.4 -rwxrwx--- 1 nitin 50 Apr 20 06:32 md5.igs-in-l.102-5.4 -rwxrwx--- 1 nitin 51 Apr 20 06:32 md5.igs-inr-l.102-5.4 -rwxrwx--- 1 nitin 50 Apr 20 06:33 md5.igs-ir-l.102-5.4 -rwxrwx--- 1 nitin 50 Apr 20 06:34 md5.xx-bpx.102-5.4 -rwxrwx--- 1 nitin 50 Apr 20 06:34 md5.xx-d-m.102-5.4 -rwxrwx--- 1 nitin 51 Apr 20 06:35 md5.xx-dr-m.102-5.4 -rwxrwx--- 1 nitin 50 Apr 20 06:35 md5.xx-i-m.102-5.4 -rwxrwx--- 1 nitin 51 Apr 20 06:35 md5.xx-in-m.102-5.4 -rwxrwx--- 1 nitin 52 Apr 20 06:36 md5.xx-inr-m.102-5.4 -rwxrwx--- 1 nitin 51 Apr 20 06:36 md5.xx-ir-m.102-5.4 -rwxrwx--- 1 nitin 48 Apr 20 06:37 md5.xx-k.102-5.4 -rwxrwx--- 1 nitin 4388344 Apr 25 13:08 xx-bpx.102-5.5 -rwxrwx--- 1 nitin 3630312 Apr 25 13:09 xx-d-m.102-5.5 -rwxrwx--- 1 nitin 3646004 Apr 25 13:11 xx-dr-m.102-5.5 -rwxrwx--- 1 nitin 3038160 Apr 25 13:13 xx-i-m.102-5.5 -rwxrwx--- 1 nitin 3215048 Apr 25 13:15 xx-in-m.102-5.5 -rwxrwx--- 1 nitin 3230736 Apr 25 13:16 xx-inr-m.102-5.5 -rwxrwx--- 1 nitin 3053852 Apr 25 13:18 xx-ir-m.102-5.5 -rwxrwx--- 1 nitin 4147468 Apr 25 13:20 xx-k.102-5.5 -rwxrwx--- 1 nitin 1803240 Apr 25 13:21 xx-rxboot.102-5.5 gs3-k.102-5.5 ------------- text data bss dec hex 3983436 150288 295660 4429384 439648 cs3-k.102-5.5 ------------- text data bss dec hex 3016472 114552 211716 3342740 330194 igs-k-l.102-5.5 --------------- text data bss dec hex 4014884 159380 296064 4470328 443638 igs-f-l.102-5.5 --------------- text data bss dec hex 2142800 92296 168580 2403676 24ad5c igs-c-l.102-5.5 --------------- text data bss dec hex 3118816 118828 205280 3442924 3488ec igs-bpx-l.102-5.5 ----------------- text data bss dec hex 4300856 174844 297792 4773492 48d674 igs-d-l.102-5.5 --------------- text data bss dec hex 3557672 144480 262820 3964972 3c802c igs-dr-l.102-5.5 ---------------- text data bss dec hex 3574124 145260 262820 3982204 3cc37c igs-g-l.102-5.5 --------------- text data bss dec hex 2464808 99676 222656 2787140 2a8744 igs-i-l.102-5.5 --------------- text data bss dec hex 2925380 125004 243700 3294084 324384 igs-in-l.102-5.5 ---------------- text data bss dec hex 3100140 133916 253172 3487228 3535fc igs-inr-l.102-5.5 ----------------- text data bss dec hex 3116592 134700 253172 3504464 357950 igs-ir-l.102-5.5 ---------------- text data bss dec hex 2941828 125788 243700 3311316 3286d4 igs-rxboot.102-5.5 ------------------ text data bss dec hex 1642540 62848 150244 1855632 1c5090 xx-bpx.102-5.5 -------------- text data bss dec hex 4215408 172904 398944 4787256 490c38 xx-d-m.102-5.5 -------------- text data bss dec hex 3488132 142148 364144 3994424 3cf338 xx-dr-m.102-5.5 --------------- text data bss dec hex 3503040 142932 364132 4010104 3d3078 xx-i-m.102-5.5 -------------- text data bss dec hex 2913840 124288 344872 3383000 339ed8 xx-in-m.102-5.5 --------------- text data bss dec hex 3081816 133200 354496 3569512 367768 xx-inr-m.102-5.5 ---------------- text data bss dec hex 3096724 133980 354504 3585208 36b4b8 xx-ir-m.102-5.5 --------------- text data bss dec hex 2928748 125072 344876 3398696 33dc28 xx-k.102-5.5 ------------ text data bss dec hex 3984792 162644 397564 4545000 4559e8 xx-rxboot.102-5.5 ----------------- text data bss dec hex 1740796 62412 249448 2052656 1f5230 gs7-k.102-5.5 ------------- text data bss dec hex 5125920 202000 495068 5822988 58da0c gs7-s-m.102-5.5 --------------- text data bss dec hex 2525508 132660 232724 2890892 2c1c8c cs500-k.102-5.5 --------------- text data bss dec hex 2375992 92092 202608 2670692 28c064 From list-mgr@ISI.EDU Tue May 2 23:51:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 2 May 1995 12:54:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 2 May 1995 12:51:46 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 2 May 1995 12:51:35 -0700 Received: from delos (eckert@faui45r.informatik.uni-erlangen.de [131.188.34.54]) by immd4.informatik.uni-erlangen.de with SMTP id VAA18336 (8.6.12/7.4b-FAU); for ; Tue, 2 May 1995 21:51:24 +0200 From: Toerless Eckert Message-Id: <199505021951.VAA18336@faui40.informatik.uni-erlangen.de> Subject: FDDI/S looses multicast packets To: mbone Date: Tue, 2 May 1995 21:51:20 +0200 (MET DST) Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi When using the Sun FDDI/S 3.0 board with to do mbone multicasting, the board looses about 10%-20% of the received multicast packets, which isn't very good for the realtime applications used on mbone. This has been given bugid 1200698 at sun. It seems to be a hardware problem and they say to have boards without this hardware problem in about 2 month, and they'll exchange boards under guarantee/support. With current generation boards this problem can be avoided by using multicast addresses in the range of 1:0:5e:0:0:xx (xx is arbitrarily). No guarantees on correctness on the above, it's only what i've been told by sun after submitting my experiences with he fddi board. Just thought to let you know. I for once searched around very long before getting the idea that there might be a hardware problem associated with the bad vat sound quality that i experienced. -- Toerless From list-mgr@ISI.EDU Wed May 3 03:34:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 2 May 1995 15:35:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 2 May 1995 15:34:43 -0700 Received: from octavia (octavia.anu.edu.au) by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 2 May 1995 15:34:40 -0700 Received: by octavia (4.1/SMI-4.1) id AA15314; Wed, 3 May 95 08:34:34 EST Date: Wed, 3 May 95 08:34:34 EST From: markus@ISI.EDU (Markus Buchhorn) Message-Id: <9505022234.AA15314@octavia> To: mbone Subject: SS5 Audio Patch is out Patch 102125-02 (actually -anything) has finally appeared on sunsolve.sun.com, as of a few days ago (Apr 27th). From the readme: ---------------------------- Patch-ID# 102125-02 Keywords: audio looping hang audiocs cs4231 panic soundtool gaintool Synopsis: SunOS 5.4: Audio device driver jumbo patch Date: Apr/27/95 [...] Files included with this patch: /usr/kernel/drv/audiocs Problem Description: 1182380 sample count incorrectly set on cs4231 1187814 when accessing to the audio driver, the ss5 panic 1164836 vat does not work on sparcstation 5 1186277 Using soundtool on SS5 running 2.3. After 1.02 seconds a click is heard. 1187962 No audio output when running DOOM on SPARCStation 4 or SPARCstation 5.. 1183393 Can't Resume after Gaintool Pause on AudioTool file open (from 102125-01) 1153505 Looping record+play test hangs when played with Sundiag on 2.3 85mHZ sys tem 1173755 A close to the audio device hangs on aurora 1176131 SS5 audio sample counts are inaccurate [...] ------------------- Obviously this patch was pushed along by the DOOM problem... :-) I haven't installed it yet - give me another few minutes... Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] From list-mgr@ISI.EDU Tue May 2 09:42:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 2 May 1995 16:53:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 2 May 1995 16:53:03 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 2 May 1995 16:53:02 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id QAA09069; Tue, 2 May 1995 16:42:50 -0700 Date: Tue, 2 May 1995 16:42:50 -0700 From: Dino Farinacci Message-Id: <199505022342.QAA09069@stilton.cisco.com> To: Toerless.Eckert@informatik.uni-erlangen.de Cc: mbone In-Reply-To: Toerless Eckert's message of Tue, 2 May 1995 21:51:20 +0200 (MET DST) <199505021951.VAA18336@faui40.informatik.uni-erlangen.de> Subject: FDDI/S looses multicast packets >> With current generation boards this problem can be avoided by using >> multicast addresses in the range of 1:0:5e:0:0:xx (xx is arbitrarily). The only problem with those multicast addresses, is that they are single subnet only and routers shouldn't forward them. Dino From list-mgr@ISI.EDU Tue May 2 11:12:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 2 May 1995 18:13:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 2 May 1995 18:12:52 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 2 May 1995 18:12:51 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14419(6)>; Tue, 2 May 1995 18:12:45 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Tue, 2 May 1995 18:12:37 -0700 X-Mailer: exmh version 1.6 4/21/95 To: Toerless Eckert Cc: mbone Subject: Re: FDDI/S looses multicast packets In-Reply-To: Your message of "Tue, 02 May 95 12:51:20 PDT." <199505021951.VAA18336@faui40.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 2 May 1995 18:12:32 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May2.181237pdt.49859@crevenia.parc.xerox.com> In message <199505021951.VAA18336@faui40.informatik.uni-erlangen.de> you write: >With current generation boards this problem can be avoided by using >multicast addresses in the range of 1:0:5e:0:0:xx (xx is arbitrarily). Meaning IP addresses 224.0.0.xx (which is locally scoped by mrouted), 224.128.0.xx, 225.0.0.xx, 225.128.0.xx, etc. ? Bill From list-mgr@ISI.EDU Tue May 2 12:16:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 2 May 1995 19:17:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 2 May 1995 19:17:00 -0700 Received: from cincsac.arc.nasa.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 2 May 1995 19:16:59 -0700 Received: from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (8.6.11/1.5T) id TAA03499; Tue, 2 May 1995 19:16:27 -0700 Message-Id: <199505030216.TAA03499@cincsac.arc.nasa.gov> To: Toerless Eckert Cc: mbone Subject: Re: FDDI/S looses multicast packets In-Reply-To: Your message of "Tue, 02 May 95 21:51:20 +0200." <199505021951.VAA18336@faui40.informatik.uni-erlangen.de> Date: Tue, 02 May 95 19:16:27 -0700 From: "Milo S. Medin" (NASA Ames Research Center) The SUN FDDI/S board has a number of problems, including apparently a set of issues that cause spurious ring resets on occaision, at least that's what an article in network computing magazine found. We've pretty much replaced all our Sbus FDDI's with the Crescendo (nee Cisco) FDDI controllers, which have good multicast support under 4.1.X, and much better performance (I think the FDDI/S was the slowest of all boards tested), and also is cheaper (whereas the FDDI/S was also expensive). I'm not sure why anyone would buy one of these at this point in time. Thanks, Milo From list-mgr@ISI.EDU Wed May 3 20:08:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 00:36:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 00:36:07 -0700 Received: from comp.kbsc.re.kr (comp.kbsc.re.kr) by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 00:36:01 -0700 Received: by comp.kbsc.re.kr (4.1/KBSC-MX-1.0) id AA10462; Wed, 3 May 95 11:08:15 KST From: sjjeon@comp.kbsc.re.kr (Seong-Joon Jeon) Message-Id: <9505030208.AA10462@comp.kbsc.re.kr > To: mbone Date: Wed, 3 May 1995 11:08:15 +0900 (KST) X-Mailer: ELM [version 2.4 PL21-h3] Content-Type: text Content-Length: 36 unsubscribe sjjeon@comp.kbsc.re.kr From list-mgr@ISI.EDU Wed May 3 13:58:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 03:02:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 03:00:45 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 02:59:07 -0700 Received: from delos (eckert@faui45r.informatik.uni-erlangen.de [131.188.34.54]) by immd4.informatik.uni-erlangen.de with SMTP id LAA25906 (8.6.12/7.4b-FAU);; Wed, 3 May 1995 11:58:57 +0200 From: Toerless Eckert Message-Id: <199505030958.LAA25906@faui40.informatik.uni-erlangen.de> Subject: Re: FDDI/S looses multicast packets To: medin@nsipo.nasa.gov (Milo S. Medin) Date: Wed, 3 May 1995 11:58:55 +0200 (MET DST) Cc: Toerless.Eckert@informatik.uni-erlangen.de, mbone In-Reply-To: <199505030216.TAA03499@cincsac.arc.nasa.gov> from "Milo S. Medin" at May 2, 95 07:16:27 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Disclaimer: I guess this might not be the appropriate place to discuss this so go ahead and blame me for abusing this lists space > The SUN FDDI/S board has a number of problems, including apparently a > set of issues that cause spurious ring resets on occaision, at least that's > what an article in network computing magazine found. Hmm, any way to get a copy of that article ? I guess we don't have that magazine in our library. Do your complaints all relate to the FDDI/S 3.0 interface or to the older one too ? > We've pretty much replaced all our Sbus FDDI's with the Crescendo (nee Cisco) > FDDI controllers, which have good multicast support under 4.1.X, and much > better performance (I think the FDDI/S was the slowest of all boards tested), > and also is cheaper (whereas the FDDI/S was also expensive). I'm not sure > why anyone would buy one of these at this point in time. I guess that's what i'm going for too. From list-mgr@ISI.EDU Tue May 2 21:18:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 04:46:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 04:46:11 -0700 Received: from davinci.gmu.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 04:46:09 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id BAA21568; Wed, 3 May 1995 01:18:21 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199505030518.BAA21568@davinci.gmu.edu> Subject: Monitoring software for multicast traffic To: mbone Date: Wed, 3 May 1995 01:18:07 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 787 Please excuse this question if it is a bit naive. I am looking for software that will track the load demand on a network and produce a histogram (or numbers that will plug into Excel) for multicast traffic. The more different measurements that this software produces, the better. Does anyone know of such a beast? I really need it to be readily accessible (ie, FTP-able), free and work on a Sun (Solaris). Please email me at mbenson@gmu.edu Thanks, Michael P.S. If anyone also knows of a system load monitor that can produce the CPU and DISK load rates on a sun, please email me that as well. -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Wed May 3 14:19:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 05:22:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 05:21:35 -0700 Received: from tamdhu.dcs.st-andrews.ac.uk (tamdhu.dcs.st-and.ac.uk) by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 05:20:59 -0700 Received: from turret.dcs.st-and.ac.uk by tamdhu.dcs.st-andrews.ac.uk (4.1/SMI-4.1) id AA17353; Wed, 3 May 95 13:20:23 BST Message-Id: <9505031220.AA17353@tamdhu.dcs.st-andrews.ac.uk> To: mbenson@davinci.gmu.edu (Michael Benson) Cc: mbone Subject: Re: Monitoring software for multicast traffic In-Reply-To: Your message of "Wed, 03 May 1995 01:18:07 EDT." <199505030518.BAA21568@davinci.gmu.edu> Date: Wed, 03 May 1995 13:19:38 +0100 From: "Paul Harrington" It's your lucky day! Or maybe not, since I wrote the software that I am talking about here and it is not all that polished or fancy or good. For a description, see http://warp.dcs.st-and.ac.uk/warp/sw/teflon There are quite possibly much better ways of doing this but ... maybe you can use these as a basis? Load monitoring: I wrote a program that monitors a subnet and multicasts the results out. I am currently putting in the support for distilling it down to subnet-by-subnet and region-by-region reporting. At the moment, it does not cut down on any traffic. I should put in a sd announcement of it but at the moment I am just stealing address/port 224.14.5.69/1969 On multicast monitoring, I would suggest that -- as a first approximation -- you should use tcpdump to look for mcast traffic and/or you could use snoop the traffic by joining the groups (perhaps by using the routines in mcast.pl :-) ) and counting packets in a fancier way. The only way of finding out what groups your host is a member of is doing a netstat -nia but I guess that examination of the modified netstat source should give you the correct ioctl. pjjH From list-mgr@ISI.EDU Wed May 3 04:20:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 05:21:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 05:20:42 -0700 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 05:20:41 -0700 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14505; Wed, 3 May 95 08:20:36 EDT Date: Wed, 3 May 95 08:20:36 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9505031220.AA14505@itd.nrl.navy.mil> To: mbone Subject: Sun FDDI/S board We reached about the same conclusion as Milo about a year ago when we first started to have many systems with FDDI to the desktop. We buy the Network Peripherals (NP) FDDI cards for S-Bus which support multicasting and work well with both SunOS 4.1.x and Solaris 2.4. We originally bought NP because NP uses the NS chipset rather than the AMD chipset (the AMD chipset has historically been buggy), but we keep with NP because the price is right and the quality is high. The NP FDDI/Ethernet bridges are to be avoided because they reportedly don't do IP fragmentation as they should. By the way, Solaris 2.4 folks should grab the kernel jumbo patch that is included with the RSVP distribution on playground.sun.com even if they don't plan to use RSVP. That jumbo patch fixes a number of problems. We have noticably improved MBONE reception/transmission as a result of adding the kernel jumbo patch even without using RSVP. The SGI Indigo2's still have somewhat better audio quality than the Suns, but the SGIs are MUCH more expensive systems and the Suns are entirely adequate. Ran atkinson@itd.nrl.navy.mil From list-mgr@ISI.EDU Wed May 3 04:01:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 07:04:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 07:03:31 -0700 Received: from fnal.fnal.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 07:03:30 -0700 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HQ27A4UP1C00EUQC@FNAL.FNAL.GOV>; Wed, 03 May 1995 09:03:18 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA04966; Wed, 3 May 95 09:01:55 CDT Date: Wed, 03 May 1995 09:01:55 -0500 From: Matt Crawford Subject: Re: FDDI/S looses multicast packets In-Reply-To: Your message of Tue, 02 May 95 19:16:27 PDT. <199505030216.TAA03499@cincsac.arc.nasa.gov> Sender: crawdad@munin.fnal.gov To: "Milo S. Medin" (NASA Ames Research Center) Cc: Toerless Eckert , mbone Message-Id: <9505031401.AA04966@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > We've pretty much replaced all our Sbus FDDI's with the Crescendo (nee Cisco) Are you kidding me? We have four of those right now, and after Cisco finally (last week) solved a problem in which an SS5 with their board consumed 90% of the CPU just by *being connected* to a lightly-loaded ring, we still get a TTCP throughput 1/3 of ethernet rate! Plus, if we put this board into promiscuous mode, the machine completely locks up. We borrowed a Sun 3.0 FDDI board and it didn't hve these problems. Is that the one you tried, or did you try the older, extremely losing Sun product? _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From list-mgr@ISI.EDU Wed May 3 08:33:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 09:33:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 09:33:14 -0700 Received: from savage.proteon.com by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 09:33:13 -0700 Received: by savage.proteon.com (4.1/SMI-4.1) id AA01898; Wed, 3 May 95 12:33:10 EDT Date: Wed, 3 May 95 12:33:10 EDT From: dxg@proteon.com (Dariush Gholizadeh) Message-Id: <9505031633.AA01898@savage.proteon.com> To: mbone Subject: Info I need info on your vide m-bone technology --DAR From list-mgr@ISI.EDU Wed May 3 02:39:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 09:42:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 09:41:00 -0700 Received: from cincsac.arc.nasa.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 09:40:59 -0700 Received: from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (8.6.11/1.5T) id JAA03900; Wed, 3 May 1995 09:39:25 -0700 Message-Id: <199505031639.JAA03900@cincsac.arc.nasa.gov> To: Toerless Eckert Cc: mbone Subject: Re: FDDI/S looses multicast packets In-Reply-To: Your message of "Wed, 03 May 95 11:58:55 +0200." <199505030958.LAA25906@faui40.informatik.uni-erlangen.de> Date: Wed, 03 May 95 09:39:25 -0700 From: "Milo S. Medin" (NASA Ames Research Center) I'll have to go dig it up. I think it was about 9 months ago in Network Computing... Thanks, Milo From list-mgr@ISI.EDU Wed May 3 02:53:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 09:55:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 09:55:15 -0700 Received: from cincsac.arc.nasa.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 09:55:14 -0700 Received: from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (8.6.11/1.5T) id JAA03951; Wed, 3 May 1995 09:53:19 -0700 Message-Id: <199505031653.JAA03951@cincsac.arc.nasa.gov> To: Matt Crawford Cc: Toerless Eckert , mbone Subject: Re: FDDI/S looses multicast packets In-Reply-To: Your message of "Wed, 03 May 95 09:01:55 CDT." <9505031401.AA04966@munin.fnal.gov> Date: Wed, 03 May 95 09:53:19 -0700 From: "Milo S. Medin" (NASA Ames Research Center) We've had pretty good luck with the cisco controllers on 4.1.X. We had some of the 3.0 boards, but the cisco's work pretty well for us... Thanks, Milo From list-mgr@ISI.EDU Wed May 3 04:30:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 11:31:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 11:31:29 -0700 Received: from apex.ece.ucsb.edu (apex.ucsb.edu) by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 11:31:27 -0700 Received: from eta.ece.ucsb.edu by apex.ece.ucsb.edu (5.0/ECE.UCSB-v1.4R) id AA07332; Wed, 3 May 1995 11:31:17 +0800 Received: by eta.ece.ucsb.edu (4.1/ECE.UCSB-v1.2) id AA15233; Wed, 3 May 95 11:30:49 PDT Date: Wed, 3 May 95 11:30:49 PDT From: Deb@eta.ece.ucsb.edu Message-Id: <9505031830.AA15233@eta.ece.ucsb.edu> To: mbone Subject: FDDI cards . . . . Content-Length: 2617 Message forwarded for Jin Guojun : > > We've pretty much replaced all our Sbus FDDI's with the Crescendo (nee Cisco) > Are you kidding me? We have four of those right now, and after Cisco > finally (last week) solved a problem in which an SS5 with their board > consumed 90% of the CPU just by *being connected* to a lightly-loaded > ring, we still get a TTCP throughput 1/3 of ethernet rate! Plus, if > we put this board into promiscuous mode, the machine completely locks > up. > We borrowed a Sun 3.0 FDDI board and it didn't hve these problems. > Is that the one you tried, or did you try the older, extremely losing > Sun product? > _________________________________________________________ > Matt Crawford crawdad@fnal.gov Fermilab The problem is not on any cards made by a third party. The problem is in the device driver written by a third party. The SS5 has a very different bus (micro-bus ?) which only Sun knows about it. Therefore, when you place a normal SBus device driver on SS5, it won't work well. The maximum throught is 5 Mbps (1/2 of the ethernet speed). Do not be supprised. Since Sun knows what is going on, so they can write a prefect device driver for their cards, but this does not mean their card is better. To get around of this problem, (1) ask the third party to write a device driver for SS5 (I doubt any one wants to do it). (2) move to different boxs. SS10 or SS20; they are expensive; but high end PC is a good choice, and it is what we are doing now. A Pentinum-100 with exactly same configuration with SS5 costs $3500, which is much cheaper than SS5. 32 MB memory 1 GB hard drive 17" sony 17SE1 monitor + 1600 x 1280 frame buffer at 74 Hz refresh rate 2 floppy drives (SS5 does not have) SCSI-2 controller 2 serial ports and 1 parallel port The overall performance is similar to SS20 ( much better than SS5 ). The INTEGER OP is 5 times faster than SS20; the FLOATING OP is twice slower than SS20 (Sparc has a very special FPU, and it can compete with DEC/Alpha chips) the I/O is depended on the device driver; not very good right now. /-------------- Jin Guojun ------------ v ---- Internet: g_jin@lbl.gov ----\ | Imaging & Distributed Computing | Usenet: ucbvax!g_jin@lbl.gov | | Lawrence Berkeley Laboratory | Bitnet: -- | | 50B-2239, Berkeley, CA 94720 - jin%george.lbl.gov@Csa3.LBL.Gov | \--Ph#:(510) 486-7531 + Fax: 486-6363 --^--http://george.lbl.gov/ITG.html--/ From list-mgr@ISI.EDU Thu May 4 00:17:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 13:18:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 13:18:30 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 13:18:19 -0700 Received: from delos (eckert@faui45r.informatik.uni-erlangen.de [131.188.34.54]) by immd4.informatik.uni-erlangen.de with SMTP id WAA03843 (8.6.12/7.4b-FAU);; Wed, 3 May 1995 22:17:53 +0200 From: Toerless Eckert Message-Id: <199505032017.WAA03843@faui40.informatik.uni-erlangen.de> Subject: Re: FDDI cards . . . . To: Deb@eta.ece.ucsb.edu Date: Wed, 3 May 1995 22:17:51 +0200 (MET DST) Cc: mbone In-Reply-To: <9505031830.AA15233@eta.ece.ucsb.edu> from "Deb@eta.ece.ucsb.edu" at May 3, 95 11:30:49 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > The problem is not on any cards made by a third party. > The problem is in the device driver written by a third party. > The SS5 has a very different bus (micro-bus ?) which only Sun knows about it. *whow* Now this discussion really get's deep. Please make some real useful statements here. The I/O bus in the SS5 is still called SBus, last time i looked at it, it looked like SBus, all SBus devices will work in it, so i guess it's not "a very different bus (micro-bus ?)", but that there simply might be some problems with it. Can you name them ? From list-mgr@ISI.EDU Wed May 3 08:11:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 15:14:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 15:13:46 -0700 Received: from framsparc.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 15:13:43 -0700 Received: by framsparc.ocf.llnl.gov (4.1/SMI-4.0) id AA26383; Wed, 3 May 95 15:11:58 PDT From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian) Message-Id: <9505032211.AA26383@framsparc.ocf.llnl.gov> Subject: Re: FDDI cards . . . . To: Toerless.Eckert@informatik.uni-erlangen.de (Toerless Eckert) Date: Wed, 3 May 1995 15:11:57 -0700 (PDT) Cc: Deb@eta.ece.ucsb.edu, mbone In-Reply-To: <199505032017.WAA03843@faui40.informatik.uni-erlangen.de> from "Toerless Eckert" at May 3, 95 10:17:51 pm X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1098 >> The problem is not on any cards made by a third party. >> The problem is in the device driver written by a third party. >> The SS5 has a very different bus (micro-bus ?) which only Sun knows about it. > >*whow* Now this discussion really get's deep. > >Please make some real useful statements here. >The I/O bus in the SS5 is still called SBus, last time i looked at it, >it looked like SBus, all SBus devices will work in it, so i guess it's not >"a very different bus (micro-bus ?)", but that there simply might be >some problems with it. Can you name them ? I'm with Toerless on this - how about some real detail? I don't know what the system bus is on a SS5, but on an SS10, it is an MBus. It is true that there is slowness with the M2S chip which shuttles data between the MBus and SBus (i.e. between memory/cpu and I/O card) so that data transfer rates using PIO is limited to approximately 20 MBytes/sec (somewhat higher for SunOS 4.1.x than for Solaris 2.x). I don't know if DMAs are similarly constrained (does the data have to flow thru the M2S chip for a DMA?). But I digress... From list-mgr@ISI.EDU Wed May 3 08:16:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 15:17:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 15:17:05 -0700 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 15:17:02 -0700 Received: from icsib53.ICSI.Berkeley.EDU (lampart@icsib53.ICSI.Berkeley.EDU [128.32.201.106]) by icsia.ICSI.Berkeley.EDU (8.6.12/HUB+V8$Revision: 1.22 $) with ESMTP id PAA28770; Wed, 3 May 1995 15:16:54 -0700 From: lampart@ICSI.Berkeley.EDU (Bernd Lamparter) Received: (lampart@localhost) by icsib53.ICSI.Berkeley.EDU (8.6.12/1.8) id PAA13176; Wed, 3 May 1995 15:16:49 -0700 Date: Wed, 3 May 1995 15:16:49 -0700 Message-Id: <199505032216.PAA13176@icsib53.ICSI.Berkeley.EDU> To: Toerless Eckert Cc: mbone Subject: Re: Re: FDDI cards . . . . In-Reply-To: <199505032017.WAA03843@faui40.informatik.uni-erlangen.de> References: <9505031830.AA15233@eta.ece.ucsb.edu> <199505032017.WAA03843@faui40.informatik.uni-erlangen.de> Toerless Eckert writes: > > The problem is not on any cards made by a third party. > > The problem is in the device driver written by a third party. > > The SS5 has a very different bus (micro-bus ?) which only Sun knows about it. > > *whow* Now this discussion really get's deep. > > Please make some real useful statements here. > The I/O bus in the SS5 is still called SBus, last time i looked at it, > it looked like SBus, all SBus devices will work in it, so i guess it's not > "a very different bus (micro-bus ?)", but that there simply might be > some problems with it. Can you name them ? > We here at ICSI had also problems with on those machines when we attached ATM-adaptors. We found out, that the speed of the bus is slightly different (sorry, no exact frequencies handy). Bernd Lamparter --------------------------------------------------------------------------- Bernd Lamparter lamparter@icsi.berkeley.edu International Computer http://www.icsi.berkeley.edu/~lampart Science Institute 1947 Center St., Suite 600 phone (510)643-4274 ext. 192 Berkeley, CA 94704-1105 fax (510)643-7684 From list-mgr@ISI.EDU Wed May 3 09:33:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 16:31:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 3 May 1995 16:31:11 -0700 Received: from mosaic.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Wed, 3 May 1995 16:31:09 -0700 Received: from myri.com (citadel.myri.com) by mosaic.cs.caltech.edu (4.1/1.34.1) id AA28076; Wed, 3 May 95 16:28:11 PDT Received: from freja.myri.com by myri.com (4.1/1.34.1) id AA07629; Wed, 3 May 95 16:33:51 PDT Date: Wed, 3 May 95 16:33:51 PDT From: feldy@myri.com (Bob Felderman) Message-Id: <9505032333.AA07629@myri.com> To: Toerless.Eckert@informatik.uni-erlangen.de, booloo@framsparc.ocf.llnl.gov Subject: Re: FDDI cards . . . . Cc: Deb@eta.ece.ucsb.edu, mbone Some more details from experience. All of the machines in question have an SBus, that's the I/O bus for the machine. These machines all have an MBus that's the memory bus for the processor/memory/cache. Some machines have MBus slots in addition to the SBus slots (Sparc-20 etc), others do not. The Sbus is normally clocked at a multiple (1/3, 1/4 etc) of the CPU clock frequency. We have 85MHz CPU Sparc-5 machines with a 21.25 SBus clock rate and 75MHz CPU sparc-5 with 25MHz SBus clock rates. The MBus/SBus bridge is often the bottleneck in bandwidth and latency for SBus/memory transfers. The sun4m architecture also has a pesky IOMMU so that all DMA transfers must be to/from IOMMU-mapped memory. Unfortunately, network mbufs are not allocated from that space, so you have to copy or remap the pages before doing a DMA. This hurts performance. The SBus controller on the motherboard also determines SBus burst-size (as does the SBus/MBus bridge). On the old sparc-2 machines the controllers supported a 16 word burst (64 byte) and there was no IOMMU, so all kernel memory including mbufs was DMA-able space. We have a DMA master device on our board that can sustain 55MBytes/sec on a sparc-2 but only 30MBytes/sec (or so, I don't have the number handy) on a Sparc-20 since the Sparc-20 only supports a burst size of 8 words. That doesn't count the extra overhead of getting the data into or out of IOMMU space. It seems that Sun has spent all its time working on the processor/memory area, and has completely ignored the I/O part of their systems. The Sparc-20 will support the 64-bit wide SBus, but very few vendors seem to be building boards for such beast. Bob Felderman Myricom Inc. 325B N. Santa Anita Ave. Arcadia, CA 91006 (818) 821-5555 (818) 821-5316 fax feldy@myri.com http://www.myri.com From list-mgr@ISI.EDU Fri May 5 07:35:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 4 May 1995 06:36:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 4 May 1995 06:35:26 -0700 Received: from huie.hokudai.ac.jp (wsclark.huie.hokudai.ac.jp) by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 4 May 1995 06:35:23 -0700 Return-Path: mit@ieee.hokudai.ac.jp Received: from iees5.ieee.hokudai.ac.jp (iees5.ieee.hokudai.ac.jp [133.50.100.5]) by huie.hokudai.ac.jp (8.6.11/2.8Wb) with SMTP id WAA12116; Thu, 4 May 1995 22:35:19 +0900 Received: from iees1.ieee.hokudai.ac.jp by iees5.ieee.hokudai.ac.jp (4.1/6.4J.6-ieee-new) id AA01901; Thu, 4 May 95 22:35:18 JST Message-Id: <9505041335.AA24715@iees1.ieee.hokudai.ac.jp> To: mbone Cc: mit@huie.hokudai.ac.jp Subject: Help!. different subnet mask and mrouted Reply-To: mit@huie.hokudai.ac.jp X-Mailer: Mew beta version 0.89 on Emacs 19.28.2, Mule 2.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 04 May 1995 22:35:16 +0900 From: Kazufumi-MIT-Mitani Our network is basically class-B broad net. (133.50) (133.50.1 - 133.50.79) we attach subnets (133.50.xx, xx>=80) to this broad net and routing for subnet used by broad net uses proxyarp. subnet gateways use static routing. A | ======================================= class-B broad net (133.50.1-79) | | B(tunnel) C | | ============= =============== class-B subnet (133.50.xx,xx>=80) | | D E host A (conencted directory to broad net)'s ifconfig is le0: 133.50.aa.bb(aa<80) netmask 255.255.0.0 broadcast 133.50.255.255 host B's ifconfig is le1: 133.50.16.xx (xx is subnet) netmask 255.255.255.0 broadcast 133.50.255.255 le0: 133.50.xx.yy (xx is subnet) netmask 255.255.255.0 broadcast 133.50.xx.255 our mbone tunnel is host B. (ipmulti 3.3, mrouted 3.4) host A-E all have multicasted kernel. mrouted also runs on host C. host A-E can get multicast packets tunneled to host B. multicast packets generated by host B-E can be deliverd to host A-E and outshipped via tunnel. but multicast packets generated by host A only goes to host B and C. not deliverd to host D, E and outside world via tunnel. (because of different subnet mask) We want to deliver multicast pckets generated by host A to everyone so that user at host A can communicate via mbone. so, pelase tell me how to get over this situation. I test mrouted's config.c to set mask value to 255.255.0.0 and neglect same subnet check for le1. but it doesn't do well. any suggestion? --- Kazufumi Mitani Hokkaido Univ., Sapporo 060, Japan From list-mgr@ISI.EDU Thu May 4 19:53:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 4 May 1995 08:55:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 4 May 1995 08:55:12 -0700 Received: from bosun.wblab.lu.se by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 4 May 1995 08:54:11 -0700 Received: from bosun.wblab.lu.se (localhost [127.0.0.1]) by bosun.wblab.lu.se (8.6.11/8.6.11) with ESMTP id RAA04224; Thu, 4 May 1995 17:53:23 +0200 Message-Id: <199505041553.RAA04224@bosun.wblab.lu.se> X-Mailer: exmh version 1.6alpha 2/16/95 To: mit@huie.hokudai.ac.jp Cc: mbone, tg@bosun.wblab.lu.se Subject: Re: Help!. different subnet mask and mrouted In-Reply-To: Your message of "Thu, 04 May 1995 22:35:16 +0900." <9505041335.AA24715@iees1.ieee.hokudai.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 May 1995 17:53:22 +0200 From: Tomas Gradin >multicast packets generated by host B-E can be deliverd to host A-E >and outshipped via tunnel. > >but multicast packets generated by host A only goes to host B and C. >not deliverd to host D, E and outside world via tunnel. >(because of different subnet mask) > >We want to deliver multicast pckets generated by host A to everyone >so that user at host A can communicate via mbone. > >so, pelase tell me how to get over this situation. I would suggest changing the netmask to 255.255.255.0 on the broad net, and using appropriate routing tables (possibly controlled by routed) to send local IP directly. It seems that mrouted only uses netmask to determine how to send tunnelled traffic; perhaps it should use ordinary routing info for that instead? You could consider using netmask 255.255.255.0 only on the mbone hosts, and on those applying a broadcast address of 255.255.255.255 (see RFC 1122) to avoid strangeness. /tg From list-mgr@ISI.EDU Thu May 4 10:11:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 4 May 1995 11:14:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 4 May 1995 11:13:48 -0700 Received: from andy.dia.atd.net by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 4 May 1995 11:13:46 -0700 Received: (from crobson@localhost) by andy.dia.atd.net (8.6.9/8.6.9) id OAA00495; Thu, 4 May 1995 14:11:38 -0400 Date: Thu, 4 May 1995 14:11:38 -0400 (EDT) From: Chris Robson ATDNet Admin Subject: Problems Generating a MBONE session To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks I can not seem to generate a mbone session. I can receive just fine. I can create a session in the SD window. And I can generate a session on my local lan OK. But I cant seem to create a tunnel between two LANS and get the second LAN to see the session announcement. MROUTED.DDUMPs shows my local group entry but the remote lan (the lan on the otherside of the tunnel) does not show the group number. Even using a TTL of 16 wont allow the tunnel to pass the group announce to the remote lan. And all host on both lans have the 224. default route. ideas......chris From list-mgr@ISI.EDU Thu May 4 12:21:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 4 May 1995 19:26:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 4 May 1995 19:25:26 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 4 May 1995 19:25:25 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14429(2)>; Thu, 4 May 1995 19:24:14 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Thu, 4 May 1995 19:21:27 -0700 X-Mailer: exmh version 1.6 4/21/95 To: Chris Robson ATDNet Admin Cc: mbone Subject: Re: Problems Generating a MBONE session In-Reply-To: Your message of "Thu, 04 May 95 11:11:38 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 4 May 1995 19:21:22 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May4.192127pdt.49859@crevenia.parc.xerox.com> In message you write: >But I cant seem to create a tunnel between two LANS and >get the second LAN to see the session announcement. It's hard to say, since you didn't specify host names, but from remote inspection it looks like you are talking about matt.dia.atd.net and the un-named 134.207.64.18: 134.207.64.14 (matt.dia.atd.net) [version 3.3]: 134.207.65.14 -> 0.0.0.0 (local) [1/1/querier] 134.207.64.14 -> 0.0.0.0 (local) [1/1/disabled] 134.207.64.14 -> 134.207.64.18 (134.207.64.18) [1/1/tunnel] 134.207.64.14 -> 134.207.16.11 (copernicus.nrl.atd.net) [1/1/tunnel] 134.207.64.18 (134.207.64.18) [version 3.3]: 134.207.65.18 -> 0.0.0.0 (local) [1/1/querier] 134.207.64.18 -> 0.0.0.0 (local) [1/1/disabled] 134.207.64.18 -> 134.207.64.14 (matt.dia.atd.net) [1/1/tunnel] Now, according to the multicast routing tables, 134.207.65 has a 255.255.255.0 netmask. If 134.207.65.14 and 134.207.65.18 are on two different LAN's, that is breaking the idea of networks and netmasks. You need to use a different network number for each LAN for multicast routing to work properly. Bill From list-mgr@ISI.EDU Fri May 5 14:30:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 5 May 1995 05:27:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 5 May 1995 05:27:15 -0700 Received: from astor.urv.es by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 5 May 1995 05:27:07 -0700 Message-Id: <199505051227.AA08687@venera.isi.edu> Received: from jasp.urv.es by astor.urv.es with SMTP (1.37.109.4/16.2) id AA18716; Fri, 5 May 95 14:18:26 +0200 X-Sender: lat@astor.urv.es (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 May 1995 14:30:15 +0000 To: mbone From: lat@astor.urv.es (Luis Anaya) Subject: Running Ip/Multi on CISCO Routers Hi: I am in Mbone running mrouted 3.4 on a Sun Sparc Classic with Sun OS 4.1.4. All goes well :-) ... I have only one tunnel (Mbone <-> Sun in Madrid <-> Sun in Tarragona). I would like to do ip/multicast & routing on a CISCO AGS+ with 10.2. Is it posible?? Can anybody help me?? IMPORTANT: Please contact directly with me because the mbone list distribution via World -> Europe -> Spain is not quite good here in SPAIN. My e-mail below! From a Bandit Man ... Have Fun!!, Surfer ---------------------------------------------------------------- ! Luis Anaya ! ! ! ! Serveis Informatica ! ! Universitat Rovira i Virgili (URV) ! ! ! ! C/ Escortxador s/n Voice:(34) (77) 559781 ! ! 43003 Tarragona (Spain) ! !http://www.urv.es/ServInf/SI/L.Anaya.html Fax:(34) (77) 558022 ! !----------------------------------------------------------------! ! Internet: lat@si.urv.es ! ! Ampr/Net: curro@gatetset.eb3aod.ampr.org ! ! Ax25 : eb3aod@ea3rdt.eat.esp.eu ! ---------------------------------------------------------------- From list-mgr@ISI.EDU Fri May 5 09:10:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 5 May 1995 16:13:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 5 May 1995 16:13:38 -0700 Received: from isc.sjsu.edu (sparta.SJSU.EDU) by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 5 May 1995 16:13:31 -0700 Received: by isc.sjsu.edu (4.1/25-eef) id AA17399; Fri, 5 May 95 16:10:41 PDT Date: Fri, 5 May 95 16:10:41 PDT From: John Rudd Message-Id: <9505052310.AA17399@isc.sjsu.edu> To: mbone Subject: Trying to find an MBONE peer/connection We're trying to get MBONE set up here at SJSU, and we need a peer. Is there anyone in the San Jose area who can help us? John From list-mgr@ISI.EDU Fri May 5 09:41:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 5 May 1995 16:41:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 5 May 1995 16:41:29 -0700 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Fri, 5 May 1995 16:41:27 -0700 Posted-Date: Fri 5 May 95 16:41:15 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 5 May 95 16:41:16 PDT Date: Fri 5 May 95 16:41:15 PDT From: Stephen Casner Subject: Re: Trying to find an MBONE peer/connection To: kzin@isc.sjsu.edu, MBONE Message-Id: <799717275.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9505052310.AA17399@isc.sjsu.edu> Mail-System-Version: > We're trying to get MBONE set up here at SJSU, and we need a peer. > Is there anyone in the San Jose area who can help us? Geographical proximity is not very important; topological proximity is the key. So, follow your network connection "to the Internet" and see who is closest along that path. More specifically, contact the people who provide network service to your institution. -- Steve ------- From list-mgr@ISI.EDU Sat May 6 19:57:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 6 May 1995 20:58:03 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 6 May 1995 20:57:30 -0700 Received: from amber.ccs.neu.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 6 May 1995 20:57:29 -0700 Received: from bodum.ccs.neu.edu (bodum.ccs.neu.edu [129.10.114.198]) by amber.ccs.neu.edu (8.6.10/8.6.4) with SMTP id XAA02440; Sat, 6 May 1995 23:57:23 -0400 Date: Sat, 6 May 1995 23:57:23 -0400 Message-Id: <199505070357.XAA02440@amber.ccs.neu.edu> X-Sender: ivan@ccs.neu.edu X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone, rem-conf@es.net From: ivan@ccs.neu.edu (Ivan Judson) Subject: SDPv2 Version Question Cc: ivan@ccs.neu.edu Hello, I've been playing around with SDP (v1 and v2), writing some stuff here and there, and I've come upon a question: How does one tell the difference between a version 1 and a version 2 packet? The reason I ask is that it appears that without some indication, the application will be subtracting some offset for the NTP time, but without knowing the version of the incoming packet, it will not know how much to subtract... Well, ideas are welcome. --Ivan Ivan R. Judson "This is my mind; welcome to hell." Math/Computer Science ivan@ccs.neu.edu Argonne National Lab judson@mcs.anl.gov From list-mgr@ISI.EDU Sat May 6 14:33:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 6 May 1995 21:34:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 6 May 1995 21:33:44 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 6 May 1995 21:33:44 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA05925; Sat, 6 May 95 21:33:41 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9505070433.AA05925@taurus.cs.nps.navy.mil> Subject: Interesting MBone problem diagnosis To: mbone (Multicast Backbone mail list) Date: Sat, 6 May 1995 21:33:41 -0700 (PDT) Cc: rem-conf@es.net, hudson@usw.nps.navy.mil (Stefan Hudson), tlemswil@nps.navy.mil (Tracey L Emswiler), marco@lex.me.nps.navy.mil (Dave Marco), dfnorman@nps.navy.mil (Dave Norman), mjnewman@merak.cc.nps.navy.mil (Mike Newman), cochran@stl.nps.navy.mil (Milena Cochran) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1894 Last week we had a troublesome problem during our MBone multicasts of the Hamming lecture series. Our transmission experienced 50% losses at the transmitting workstation! This was surprising to us because there were no other significant processes running on the transmitting SGI Indy (hamming.me.nps.navy.mil). A variety of experiments and network tests gave conflicting results. Finally Mike McCann got us a copy of 'etherview' running locally. Etherview is a public-domain network visualizer program with a graphical display. By filtering out TCP and UDP traffic we discovered that the school's mainframe (vm1.cc.nps.navy.mil, 131.120.50.50, VAX) was sending a constant stream of ICMP packets to our transmitting workstation. This only occurred for streams occurring within NPS with ttl > 16. Thus the 50% loss at the source. Dropping the tunnel that tickled the mainframe removed the problem. Recommendation: have a graphical tool like Etherview handy for any serious multicasting. The diagnosis capabilities are essential. Other tools like tcpdump also work if you take the time to learn the syntax. Note you will need root permission to run these tools, so some preparation that includes your system administrator is also necessary. If anyone knows good pages pointing to etherview, tcpdump etc. please post them in reply to this message. Thanks are also due to Mike Macedonia, Stefan Hudson, Milena Cochran, Dave Marco and Tracey Emswiler. Tracey will be posting a rebroadcast schedule for last week's garbled multicasts. Details on the Hamming lecture series are at ftp://taurus.cs.nps.navy.mil/pub/mosaic/hamming.announce all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv.html From list-mgr@ISI.EDU Sat May 6 15:03:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 6 May 1995 22:04:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 6 May 1995 22:03:56 -0700 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Sat, 6 May 1995 22:03:43 -0700 Posted-Date: Sat 6 May 95 22:03:30 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Sat, 6 May 95 22:03:31 PDT Date: Sat 6 May 95 22:03:30 PDT From: Stephen Casner Subject: Re: Interesting MBone problem diagnosis To: brutzman@cs.nps.navy.mil, MBONE Cc: rem-conf@es.net, hudson@usw.nps.navy.mil, tlemswil@nps.navy.mil, marco@lex.me.nps.navy.mil, dfnorman@nps.navy.mil, mjnewman@merak.cc.nps.navy.mil, cochran@stl.nps.navy.mil Message-Id: <799823010.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9505070433.AA05925@taurus.cs.nps.navy.mil> Mail-System-Version: Don, I've been waging a low-level battle against sources of illegal ICMP messages in response to multicast traffic for some time. I have a monitor for them running continuously on my machine, but of course I only see ICMPs for groups to which someone on my local net is transmitting (but vat always transmits control packets even if one only listens). When I observe these, I try to find an email address from one of the vat participant lists for someone on the offending subnet, and then I send a message about the source of ICMPs. My ICMP monitor is called monicmp. It was built from the monipm program (Tcl script) written by Van Jacobson and Steve McCanne to monitor multicast traffic levels. Both programs run bpf_wish underneath the Tcl script, and bpf_wish depends on installing the updated version of BPF with a bugfix. Anyone interested in these tools and willing to deal with those issues may get: ftp://ftp.ee.lbl.gov/monipm/monipm.tar.Z ftp://ftp.ee.lbl.gov/monipm/bpf.tar.Z ftp://ftp.isi.edu/mbone/monicmp -- Steve ------- From list-mgr@ISI.EDU Sun May 7 13:00:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 7 May 1995 04:01:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 7 May 1995 04:00:48 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 7 May 1995 04:00:46 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Sun, 7 May 1995 04:00:44 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 7 May 1995 12:00:31 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: ivan@ccs.neu.edu (Ivan Judson) Cc: mbone, rem-conf@es.net Subject: Re: SDPv2 Version Question In-Reply-To: Your message of "Sat, 06 May 95 23:57:23 EDT." <199505070357.XAA02440@amber.ccs.neu.edu> Date: Sun, 07 May 95 12:00:23 +0100 Message-Id: <650.799844423@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk (this should really be on confctrl@isi.edu) > I've been playing around with SDP (v1 and v2), writing some stuff >here and there, and I've come upon a question: Firstly, I wouldn't recommend implementing from the v2 draft right now. There's a new draft in preparation and quite a lot of things have changed. I hope to release it in the next week for discussion on the confctrl list. >How does one tell the difference between a version 1 and a version 2 packet? > >The reason I ask is that it appears that without some indication, the >application will be subtracting some offset for the NTP time, but without >knowing the version of the incoming packet, it will not know how much to >subtract... In the new v2 draft, I finally got convinced into adding a version number. The only real reason for leaving it out was attempting to minimise the number of fields, and the counter arguments are much stronger. I've been testing my v2 client on a different multicast address (I didn't want to run the risk of breaking v1 clients out there!). No decision has been made yet whether to stick to a new address for v2 (as v1 clients won't parse v2 messages anyway). We can always run a gateway to re-announce v1 messages on the v2 address in the v2 format if we do. Mark From list-mgr@ISI.EDU Sun May 7 11:33:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 7 May 1995 12:38:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 7 May 1995 12:37:44 -0700 Received: from fastball.UniMaster.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 7 May 1995 12:37:40 -0700 Received: (from cherkus@localhost) by fastball.unimaster.com (8.6.7/8.6.9) id PAA05894 for mbone@isi.edu; Sun, 7 May 1995 15:33:43 -0400 From: Dave Cherkus Message-Id: <199505071933.PAA05894@fastball.unimaster.com> Subject: vat core dumping on dec alpha? To: mbone Date: Sun, 7 May 1995 15:33:43 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1043 Hi, I'm using vat to generate audio on the dec alpha. It crashes with a core dump. Unfortunately, dbx doesnt't really tell me much: (dbx) t > 0 __bcopy(0x1400a7800, 0x1e, 0x14007faa0, 0x10, 0x8) ["../../../../../../src/usr/ccs/lib/libc/alpha/bcopy.s":54, 0x12012cd0c] 1 Encode__9PCMFormatXPCUcRii(this = DBX Fault: Segmentation fault The crash seems to happen a second or two after a peak in the audio being applied to the j300 encoder. So, my questions are: - is this a known problem? - are any of the encoding methods more robust than others? - in general, which encoding method is the most popular? Any replies appreciated. We're going to do the DECUS broadcast tomorrow and want to have the most reliable broadcast we can achieve. -- Dave Cherkus ----- UniMaster, Inc. ----- Contract Software Development Specialties: UNIX TCP/IP X OSF/1 AlphaAXP AIX RS/6000 Performance ISDN Email: cherkus@UniMaster.COM Tel: (603) 888-8308 Fax: (603) 888-8308 if (cpu.type == PENTIUM && cpu.step < 8) { panic("Intel Inside!"); } From list-mgr@ISI.EDU Mon May 8 20:07:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 7 May 1995 19:08:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 7 May 1995 19:07:35 -0700 Received: from huie.hokudai.ac.jp (wsclark.huie.hokudai.ac.jp) by venera.isi.edu (5.65c/5.61+local-21) id ; Sun, 7 May 1995 19:07:32 -0700 Return-Path: mit@ieee.hokudai.ac.jp Received: from iees5.ieee.hokudai.ac.jp (iees5.ieee.hokudai.ac.jp [133.50.100.5]) by huie.hokudai.ac.jp (8.6.11/2.8Wb) with SMTP id LAA04974; Mon, 8 May 1995 11:07:15 +0900 Received: from iees1.ieee.hokudai.ac.jp by iees5.ieee.hokudai.ac.jp (4.1/6.4J.6-ieee-new) id AA17936; Mon, 8 May 95 11:07:14 JST Message-Id: <9505080207.AA07991@iees1.ieee.hokudai.ac.jp> To: tg@bosun.wblab.lu.se Cc: mbone Cc: mit@huie.hokudai.ac.jp Subject: Re: Help!. different subnet mask and mrouted Reply-To: mit@huie.hokudai.ac.jp In-Reply-To: Your message of "Thu, 04 May 1995 17:53:22 +0200" References: <199505041553.RAA04224@bosun.wblab.lu.se> X-Mailer: Mew beta version 0.89 on Emacs 19.28.2, Mule 2.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 08 May 1995 11:07:13 +0900 From: Kazufumi-MIT-Mitani From: Tomas Gradin Subject: Re: Help!. different subnet mask and mrouted Date: Thu, 04 May 1995 17:53:22 +0200 tg> I would suggest changing the netmask to 255.255.255.0 on the broad net, and tg> using appropriate routing tables (possibly controlled by routed) to send tg> local IP directly. It seems that mrouted only uses netmask to determine tg> how to send tunnelled traffic; perhaps it should use ordinary routing info tg> for that instead? tg> tg> You could consider using netmask 255.255.255.0 only on the mbone hosts, and tg> on those applying a broadcast address of 255.255.255.255 (see RFC 1122) to tg> avoid strangeness. thanx for you suggestion. we tried it. our outgoing gateway is also connected to broad net (type A) but it use address 133.50.16.xx (like gateway to subnet) we change one host (type A) 133.50.aa.bb (aa!=16) to netmask 0xffffff00 broadcast 133.50.255.255, and set static routing via route command. (not 255.255.255.255, but does it matters?) this machine can talk to all 133.50 networks (includes subnets), but it can't speak to outside. because we can't set default route to 133.50.16.xx (network unreachable). then, we bring up test MC session on this host, but Multicast packet doesn't reach to subnets or outside via tunnel. i think if we assing a address of 133.50.16.yy to this host, it may do well, but we can't assing such address to all MC hosts connected to broad net. any more suggestion ?? --- K. Mitani From list-mgr@ISI.EDU Mon May 8 05:06:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 06:11:03 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 06:10:31 -0700 Received: from fastball.UniMaster.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 8 May 1995 06:10:27 -0700 Received: (from cherkus@localhost) by fastball.unimaster.com (8.6.7/8.6.9) id JAA06549; Mon, 8 May 1995 09:06:31 -0400 From: Dave Cherkus Message-Id: <199505081306.JAA06549@fastball.unimaster.com> Subject: DECUS: sd announcement wrong To: mbone Date: Mon, 8 May 1995 09:06:30 -0400 (EDT) Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 539 Sorry if this is duplicate/triplicate but it's time critical.. The 'sd' ad for this morning's DECUS seminar may or may not have been correct. We are using vic/h261 for video. If you are not getting video, check the 'sd' ad and adjust if necessary. -- Dave Cherkus ----- UniMaster, Inc. ----- Contract Software Development Specialties: UNIX TCP/IP X OSF/1 AlphaAXP AIX RS/6000 Performance ISDN Email: cherkus@UniMaster.COM Tel: (603) 888-8308 Fax: (603) 888-8308 if (cpu.type == PENTIUM && cpu.step < 8) { panic("Intel Inside!"); } From list-mgr@ISI.EDU Mon May 8 04:30:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 06:09:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 06:03:57 -0700 Received: from dec486.dc95.show.decus.org by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 8 May 1995 06:03:56 -0700 Received: by dec486.dc95.show.decus.org; (5.65/1.1.8.2/08May95-0615AM) id AA01383; Mon, 8 May 1995 08:30:32 -0400 Date: Mon, 8 May 1995 08:30:32 -0400 From: Mbone Message-Id: <9505081230.AA01383@dec486.dc95.show.decus.org> To: mbone, rem-conf@es.net Subject: DECUS: incorrect sd ad It seems that the 'sd' ad did not correctly indicate that the video is being transmitted with vic/h261. It is still running so please try to access the session with vic/h261. Thanks. Dave/Mbone From list-mgr@ISI.EDU Mon May 8 02:44:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 09:45:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 09:44:47 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 8 May 1995 09:44:45 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14431(3)>; Mon, 8 May 1995 09:44:34 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Mon, 8 May 1995 09:44:28 -0700 X-Mailer: exmh version 1.6 4/21/95 To: Mbone Cc: mbone, rem-conf@es.net Subject: Re: DECUS: incorrect sd ad In-Reply-To: Your message of "Mon, 08 May 95 05:30:32 PDT." <9505081230.AA01383@dec486.dc95.show.decus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 8 May 1995 09:44:20 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May8.094428pdt.49859@crevenia.parc.xerox.com> In message <9505081230.AA01383@dec486.dc95.show.decus.org> you write: >It seems that the 'sd' ad did not correctly indicate that the video >is being transmitted with vic/h261. It is still running so please >try to access the session with vic/h261. You got lucky; there was a 50% chance when allocating the session that vic in nv mode wouldn't be compatible with vic in vic mode. If you are going to be using vic in its RTPv2 mode, then it's very important to make sure to specify "fmt: vic" in the sd announcement, or you may cause massive confusion. DECUS got lucky. Bill From list-mgr@ISI.EDU Mon May 8 03:32:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 10:32:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 10:32:24 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 8 May 1995 10:32:22 -0700 Received: from grus.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA24726; Mon, 8 May 95 10:32:05 PDT Date: Mon, 8 May 1995 10:32:03 -0700 (PDT) From: Michael Macedonia To: communications architecture subgroup Cc: rem-conf , mbone net , idmr group , 53 Mailing List <53listserv@seas.gwu.edu> Subject: 95-05-25 Symposium on Dynamic IP/ATM Multicasting for DIS Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > Event: SYMPOSIUM ON DYNAMIC IP/ATM MULTICASTING > FOR DISTRIBUTED INTERACTIVE SIMULATION > Loc: Washington, DC (Naval Research Laboratory) > Date: May 25, 1995 > > POC: Ms. Anna Hanbury (For Registration) > Phone: 202-767-2804 > E-Mail: ahanbury@itd.nrl.navy.mil > > POC: Ray Cole (For Technical Information) > Phone: 202-767-2901 > E-Mail: cole@itd.nrl.navy.mil > > POC: Duncan Miller (For Technical Information) > Phone: 617-981-7252 > E-Mail: dmiller@ll.mit.edu > -------------------------------------- > > May 25, 1995 > Naval Research Laboratory > Washington, DC > > The U.S. Department of Defense continues to increase its emphasis on > large-scale, distributed simulation. Recent policy (DOD Directive 5000.59) > calls for the establishment of a master plan for unifying DoD modeling and > simualtion efforts. Building on the evolving Distributed Interactive > Simulation Standards (IEEE 1278), simulation networks incorporating up to > 100,000 dynamic entities are being developed. Because of the scope of this > effort, simulation networks are expected to be based on dynamic > multicasting techniques utilizing a combination of robust Internet Protocol > (IP) and high speed Asynchronous Transfer Mode (ATM) technologies. > > The multicasting requirements for these large-scale simulations are > different from those of much of the network-layer software currently being > developed. At least 10,000 multicast groups may be needed, and hundreds of > multicast group changes per second may need to be propagated across the > network. Group join and leave latencies on the order of one second may be > required. > > This symposium provides an opportunity for the architects of the simulation > networks to meet with IP and ATM network software developers to discuss > these plans and requirements. Technical representatives from interested > computer hardware and software organizations, developers of network > switches and routers, and network software research organizations are urged > to attend. > > The meeting will be unclassified; however, all attendees must provide the > necessary information (full name, social security number, organization, and > notation indicating U. S. citizen or Green Card) in advance so that badges > will be ready upon arrival. > > *************************************************************** > **** Deadline for registration: Monday, May 22, 1995 **** > *************************************************************** > > For reservations, contact > > Ms. Anna Hanbury 202-767-2804 > > For technical information, contact > > Ray Cole 202-767-2901 > Duncan Miller 617-981-7252 > ----------------------------------- From list-mgr@ISI.EDU Mon May 8 12:15:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 13:18:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 13:17:45 -0700 Received: from nlm.nih.gov (lhc.nlm.nih.gov) by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 8 May 1995 13:17:44 -0700 Received: from billings.csb (billings.nlm.nih.gov) by nlm.nih.gov (4.1/SMI-4.0) id AA07258; Mon, 8 May 95 16:17:25 EDT Received: by billings.csb (5.x/SMI-SVR4) id AA01999; Mon, 8 May 1995 16:15:12 -0400 Date: Mon, 8 May 1995 16:15:12 -0400 From: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Message-Id: <9505082015.AA01999@billings.csb> To: mbone@dec486.dc95.show.org, mbone, rem-conf@es.net Subject: Peculiar way of setting up DECUS MBONE sessions... Dear Colleague, The manner in which the DECUS MBONE sessions have been presented via sd is most peculiar in light of current MBONE conventions. Was this tested in advance? Many people use an extension to the .sd.tcl file that automatically starts up a WWW client when a URL appears in the sd announcement. Your announcement, with <> surrounding the URL, confuses .sd.tcl, and the Web client fails to grab the intended document (the final > gets passed in as part of the URL). Furthermore, it's not at all clear why you need 8 sd announcements where one would have done just fine. No comments about the vic snafu, as that has already been commented upon in the rem-conf and mbone mailing lists. A little more advance testing and preparation would have paid off handsomely here... Cheerio, Rick Rodgers From list-mgr@ISI.EDU Mon May 8 08:33:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 15:42:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 15:39:13 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 8 May 1995 15:39:10 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14405(6)>; Mon, 8 May 1995 15:34:12 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Mon, 8 May 1995 15:34:02 -0700 X-Mailer: exmh version 1.6 4/21/95 To: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Cc: mbone, rem-conf@es.net, fenner@parc.xerox.com Subject: Re: Peculiar way of setting up DECUS MBONE sessions... In-Reply-To: Your message of "Mon, 08 May 95 13:15:12 PDT." <9505082015.AA01999@billings.csb> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 8 May 1995 15:33:50 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May8.153402pdt.49859@crevenia.parc.xerox.com> In message <9505082015.AA01999@billings.csb> you write: >Many people use an extension to the >.sd.tcl file that automatically starts up a WWW client when a URL >appears in the sd announcement. Your announcement, with <> >surrounding the URL, confuses .sd.tcl, and the Web client fails to grab the >intended document (the final > gets passed in as part of the URL). You appear to have an old version, missing the command set url [string trim $url <>.] It's amazing how quickly a proof-of-concept becomes something that everyone expects to work =) (Note that http://www.cmf.nrl.navy.mil/sd/ gets the angle brackets right =) Bill From list-mgr@ISI.EDU Mon May 8 15:00:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 16:03:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 16:02:54 -0700 Received: from nlm.nih.gov (lhc.nlm.nih.gov) by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 8 May 1995 16:02:51 -0700 Received: from billings.csb (billings.nlm.nih.gov) by nlm.nih.gov (4.1/SMI-4.0) id AA15999; Mon, 8 May 95 19:02:47 EDT Received: by billings.csb (5.x/SMI-SVR4) id AA02300; Mon, 8 May 1995 19:00:36 -0400 Date: Mon, 8 May 1995 19:00:36 -0400 From: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Message-Id: <9505082300.AA02300@billings.csb> To: rodgers@nlm.nih.gov, fenner@parc.xerox.com Subject: Re: Peculiar way of setting up DECUS MBONE sessions... Cc: mbone, rem-conf@es.net X-Sun-Charset: US-ASCII Bill, Just tried the .sd.tcl mod. as mentioned in my last note -- and I find that when I try to select the audio session for Bill Hancock (DECUS) sd still fails to pass the correct URL to Mosaic, including the rightmost " after the URL. I guess one needs to add " to the list of characters to trim, but this character may require some special quoting (my tcl is rusty so I'd have to pull down my copy of Ousterhout). Cheerio, Rick > From fenner@parc.xerox.com Mon May 8 18:48 EDT 1995 > X-Mailer: exmh version 1.6 4/21/95 > To: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) > Cc: mbone@isi.edu, rem-conf@es.net, fenner@parc.xerox.com > Subject: Re: Peculiar way of setting up DECUS MBONE sessions... > Mime-Version: 1.0 > Date: Mon, 8 May 1995 15:33:50 PDT > Sender: Bill Fenner > From: Bill Fenner > > In message <9505082015.AA01999@billings.csb> you write: > >Many people use an extension to the > >.sd.tcl file that automatically starts up a WWW client when a URL > >appears in the sd announcement. Your announcement, with <> > >surrounding the URL, confuses .sd.tcl, and the Web client fails to grab the > >intended document (the final > gets passed in as part of the URL). > > You appear to have an old version, missing the command > > set url [string trim $url <>.] > > It's amazing how quickly a proof-of-concept becomes something that everyone > expects to work =) > > (Note that http://www.cmf.nrl.navy.mil/sd/ gets the angle brackets right =) > > Bill > > From list-mgr@ISI.EDU Mon May 8 21:30:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 19:01:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 18:59:19 -0700 Received: from relay.xlink.net by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 8 May 1995 18:59:15 -0700 Received: from odb.rhein-main.de by relay.xlink.net id <57337-0@relay.xlink.net>; Tue, 9 May 1995 03:58:53 +0000 Received: from buchonia by odb.rhein-main.de with uucp (Smail3.1.28.1 #5) id m0s8eZP-0007SVC; Tue, 9 May 95 03:58 MET DST Received: from nig by buchonia.rhoen.de with uucp (Smail3.1.28.1 #5) id m0s8cFA-000EkuC; Tue, 9 May 95 01:29 MET DST Received: by nig.rhoen.de (Smail3.1.28.1 #6) id m0s8aOD-000DmTC; Mon, 8 May 95 21:30 GMT Message-Id: From: nig@nig.rhoen.de (Frank Mueller) Subject: vat for Linux ? To: mbone Date: Mon, 8 May 1995 21:30:50 +0000 (GMT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 333 Hello, is there any chance to see vat on linux ? or wb or sd ?? Thanks and Bye Frank -- Frank Mueller http://www.hrz.uni-giessen.de/~l018/nig.html E-Mail: (nig@nig.rhoen.de) ! Please under 100 KB ! IN-kompetent e.V. -* CONNECTING PEOPLE -* Verein zur Foerderung der privaten Datenkommunikation Rhoen/Vogelsberg From list-mgr@ISI.EDU Mon May 8 15:21:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 22:22:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 8 May 1995 22:21:36 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Mon, 8 May 1995 22:21:35 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14493(5)>; Mon, 8 May 1995 22:21:26 PDT Received: by crevenia.parc.xerox.com id <49859>; Mon, 8 May 1995 22:21:16 -0700 From: Bill Fenner To: mbone Subject: Announcing the 3.5 release of SunOS kernel mods Message-Id: <95May8.222116pdt.49859@crevenia.parc.xerox.com> Date: Mon, 8 May 1995 22:21:08 PDT Announcing the 3.5 release of the IP multicasting kernel modifications for Suns, and the IP multicast routing daemon. The SunOS 4.1.x kernel modifications and program binaries are available from: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/ipmulti3.5-sunos41x.tar.Z The version 3.5 mrouted (and other program) sources are available from: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted.3.5.tar.Z There are ongoing efforts to make 3.5 available for Solaris 2.4, IRIX, BSD4.4 derivatives, Ultrix, DEC OSF/1, and HP/UX. Announcements will be made by the appropriate people. I will attempt to keep the kernel patches for all os's available on ftp.parc.xerox.com in /pub/net-research/ipmulti/ . You are encouraged to upgrade to 3.5 for several reasons: o 3.5 accepts and propogates default routes, which is necessary to support heirarchical routing. We expect to start doing heirarchical routing soon, so please upgrade now, or you will lose MBONE connectivity when heirarchical routing is deployed! o Tunnel encapsulation code now caches routes for ip_output, making tunnels less of a burden on a multicast router. o The priority dropping code now uses UDP port ranges for its priority scheme, allowing anyone to take advantage of rate limiting by setting up the session properly. o Many bugfixes in the multicast routing code, as well as the client kernel code. See the CHANGES file for a complete list. o The upgrade from 3.3 is painless, as diff's from 3.3 to 3.5 are provided. Please let me know if you have any questions about or problems with the release. (Would anyone who regularly mirrors parcftp and would be willing to be listed as a site to get the multicast code please contact me? Thanks.) Bill fenner@parc.xerox.com From list-mgr@ISI.EDU Tue May 9 03:24:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 03:25:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 03:24:25 -0700 Received: from ns.riken.go.jp by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 9 May 1995 03:24:22 -0700 Received: from RIKAX1.riken.go.jp by ns.riken.go.jp (8.6.8.1/TISN-1.3M/R2) id TAA00200; Tue, 9 May 1995 19:24:19 +0900 Received: by rikax1.riken.go.jp (MX V4.1 AXP) id 2; Tue, 09 May 1995 19:23:35 JST Date: Tue, 09 May 1995 19:23:34 JST From: "Takashi Ichihara " To: mbone Cc: ichihara@rikax1.riken.go.jp Message-Id: <009901CA.D79FFE38.2@rikax1.riken.go.jp> Subject: mrouted 3.5 for OSF/1 ? Hello Did anyone succeed to install mrouted 3.5 to OSF/1 ? If so, where can I find the kit. Thanks a lot. Takashi Ichihara From list-mgr@ISI.EDU Tue May 9 08:16:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 09:24:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 09:20:25 -0700 Received: from fastball.UniMaster.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 9 May 1995 09:20:21 -0700 Received: (from cherkus@localhost) by fastball.unimaster.com (8.6.7/8.6.9) id MAA07621; Tue, 9 May 1995 12:16:01 -0400 From: Dave Cherkus Message-Id: <199505091616.MAA07621@fastball.unimaster.com> Subject: Re: Peculiar way of setting up DECUS MBONE sessions... To: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Date: Tue, 9 May 1995 12:16:00 -0400 (EDT) Cc: mbone@dec486.dc95.show.org, mbone, rem-conf@es.net In-Reply-To: <9505082015.AA01999@billings.csb> from "R. P. C. Rodgers, M.D." at May 8, 95 04:15:12 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2221 R. P. C. Rodgers, M.D. writes: |> |> Dear Colleague, |> |> The manner in which the DECUS MBONE sessions have been presented |> via sd is most peculiar in light of current MBONE conventions. |> Was this tested in advance? Many people use an extension to the |> .sd.tcl file that automatically starts up a WWW client when a URL |> appears in the sd announcement. Your announcement, with <> |> surrounding the URL, confuses .sd.tcl, and the Web client fails to grab the |> intended document (the final > gets passed in as part of the URL). Thanks for the feedback. I do not seem to have that version of .sd.tcl. What is its location? I was made aware of the deviation from the standard URL format, but I was afraid to change it because of a different problem I discovered in sd (at least the DEC alpha version): if you edit the entry it seems to 'forget' the video format value. You can go back and change it back later, but changing the value doesn't seem to cause the announcement to be rebroadcast. I've been told that propogation of the format field is critical. |> Furthermore, it's not at all clear why you need 8 sd announcements |> where one would have done just fine. No comments about the vic snafu, |> as that has already been commented upon in the rem-conf and mbone mailing |> lists. A little more advance testing and preparation would have paid |> off handsomely here... Our testing showed that you needed seperate sessions for audio and video because machines that only were capable of one of these medias failed to bring up sessions advertised with both types. This was unexpected, but it seemed wiser to create too many sessions than not enough. As for one announce per speaker, the decision was more based on the diverse nature of the sessions. I could remove all the announcements and recreate one that addresses all these points, but I'm concerned that disappearing sessions will cause confusion. -- Dave Cherkus ----- UniMaster, Inc. ----- Contract Software Development Specialties: UNIX TCP/IP X OSF/1 AlphaAXP AIX RS/6000 Performance ISDN Email: cherkus@UniMaster.COM Tel: (603) 888-8308 Fax: (603) 888-8308 if (cpu.type == PENTIUM && cpu.step < 8) { panic("Intel Inside!"); } From list-mgr@ISI.EDU Tue May 9 06:13:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 10:11:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 10:10:56 -0700 Received: from cadlips.ece.utexas.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 9 May 1995 10:10:54 -0700 Received: by cadlips.ece.utexas.edu (931110.SGI/930416.SGI.AUTO) for mbone@isi.edu id AA01549; Tue, 9 May 95 12:13:51 -0500 From: cchuter@cadlips.ece.utexas.edu (Chris Chuter) Message-Id: <9505091713.AA01549@cadlips.ece.utexas.edu> Subject: Connecting to mbone To: mbone Date: Tue, 9 May 1995 12:13:44 -0600 (CDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1267 Hello, I've set up my machine with mrouted, etc. and am ready to go, except I'm not sure how I am to get my 'network provider' to connect to the mbone feed. I'm not to sure what is meant by 'network provider' - If it's the person who supplies IP numbers in our building, should I get him to send mail to mbone-na-request@isi.edu for information (I don't think he knows anything about mbone). Should I tag along with a close by mbone machine? Sorry to bother you with such simple questions (yes, i've read the faq;), but I don't have any network gurus over here to ask. thanks --------------------------------------------------------------------------- Chris Chuter (Stereogram at right -=>) ][ |QwErMa+%#;dX| |QwErMa+%#;dX| ][ Research Assistant + Sysadmin ][ |QwE======;dX| |Qw======#;dX| ][ For LIPS - The Laboratory for ][ |QwE|Ma+%#;dX| |Qw|rMa+%#;dX| ][ Intelligent Processes and Systems ][ |QwE|Ma+=====| |Qw|rM=====dX| ][ (512) 471-5350 ][ |QwE====|=;dX| |Qw===|==#;dX| ][ University of Texas at Austin - ENS 22 ][ |QwErMa+|#;dX| |QwErM|+%#;dX| ][ cchuter@cadlips.ece.utexas.edu ][ |QwErMa+=====| |QwErM=====dX| ][ http://www-lips.ece.utexas.edu/~cchuter ][ |QwErMa+%#;dX| |QwErMa+%#;dX| ][ From list-mgr@ISI.EDU Tue May 9 03:22:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 10:20:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 10:19:47 -0700 Received: from gatekeeper.ltis.loral.com by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 9 May 1995 10:19:42 -0700 Received: (from uucp@localhost) by gatekeeper.ltis.loral.com (8.6.9/8.6.9) id KAA23998 for ; Tue, 9 May 1995 10:20:12 -0700 Received: from loral.ltis.loral.com(158.185.41.22) by gatekeeper via smap (V1.3mjr) id sma023996; Tue May 9 10:20:01 1995 Received: from tigger.ltis.loral.com (tigger.ltis.loral.com [128.1.5.7]) by loral.ltis.loral.com (8.6.9/8.6.9) with ESMTP id KAA04960 for ; Tue, 9 May 1995 10:19:37 -0700 Received: (from chris@localhost) by tigger.ltis.loral.com (8.6.9/8.6.9) id KAA03189; Tue, 9 May 1995 10:22:23 -0700 Date: Tue, 9 May 1995 10:22:20 -0700 (PDT) From: Chris Almond To: mbone Subject: subscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe chris@ltis.loral.com From list-mgr@ISI.EDU Tue May 9 03:25:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 10:27:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 10:27:25 -0700 Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 9 May 1995 10:27:24 -0700 From: bmanning@ISI.EDU Posted-Date: Tue, 9 May 1995 10:25:49 -0700 (PDT) Message-Id: <199505091725.AA01485@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 9 May 1995 10:25:49 -0700 Subject: Re: Connecting to mbone To: cchuter@cadlips.ece.utexas.edu (Chris Chuter) Date: Tue, 9 May 1995 10:25:49 -0700 (PDT) Cc: mbone In-Reply-To: <9505091713.AA01549@cadlips.ece.utexas.edu> from "Chris Chuter" at May 9, 95 12:13:44 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 38 Check with Jeff Hayward. -- --bill From list-mgr@ISI.EDU Tue May 9 10:14:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 11:48:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 11:47:58 -0700 Received: from dec486.dc95.show.decus.org by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 9 May 1995 11:47:57 -0700 Received: by dec486.dc95.show.decus.org; (5.65/1.1.8.2/08May95-0615AM) id AA03831; Tue, 9 May 1995 14:14:31 -0400 From: Mbone Message-Id: <9505091814.AA03831@dec486.dc95.show.decus.org> Subject: DECUS sessions To: mbone, rem-conf@es.net Date: Tue, 9 May 1995 14:14:31 -0400 (EDT) Content-Type: text Content-Length: 1561 I'd like to go through the feedback that we are getting on the sessions so far. The next few sessions should be exciting (we have the inventors of the World Wide Web, Mosaic and Linux speaking) and we'd really like to do the best possible job. But first, we'd like to ask remote participants to please send in questions during the session, via e-mail and or irc. The local participants would really enjoy the sense of being connected to world-wide participants via the Internet. The feedback we've gotten is that the audio is fine. As for video we've heard three different classes of comments: - I was going to tune in, but then I realized I needed 'vic' and I didn't have enough time to find/install/configure it - I saw the video and it suffered from losses - I saw the video and it was fine The first two are problematic. The use of 'nv' could help (since some but not all of the loss is due to 'vic' CPU consumption). I think some options are: - Change the format of the existing to 'vic' - Send two streams of video, one with 'vic/h261', another 'nv' Since we have been blessed with fast Alphas and a T1, sending two streams is not a problem. Once it gets to our service provider, mrouters would distribute the packets to listeners based on what stream they were trying to receive. This, and our use of 128k bandwidth limits could limit the bandwidth consumed. So, I would be interested in any guidance the subscribers can provide on the viability of these options, and any additional input that you may have. Dave+Marc/Mbone. From list-mgr@ISI.EDU Tue May 9 05:43:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 12:43:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 12:42:55 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 9 May 1995 12:42:54 -0700 Received: by rx7.ee.lbl.gov (8.6.11/1.43r) id MAA02916; Tue, 9 May 1995 12:43:16 -0700 Message-Id: <199505091943.MAA02916@rx7.ee.lbl.gov> To: nig@nig.rhoen.de (Frank Mueller) Cc: mbone Subject: Re: vat for Linux ? In-Reply-To: Your message of Mon, 08 May 95 21:30:50 A. Date: Tue, 09 May 95 12:43:15 PDT From: Van Jacobson > Hello, is there any chance to see vat on linux ? or wb or sd ? Yes. Three months ago we ordered a machine to run Linux so we could produce Linux versions of the tools. It showed up today. Now we just have to get it up & configured then get everything to compile (putting in ifdefs for all the gratuitous changes to includes, syscalls & file locations that each variant of unix feels morally oblicated to make). With luck that will only take a week or two. As soon as they're ready Linux binaries will be added to the set on ftp.ee.lbl.gov and we'll announce that fact on the mbone & rem-conf lists. - Van From list-mgr@ISI.EDU Tue May 9 11:52:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 12:53:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 12:52:21 -0700 Received: from NS.METROLINK.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 9 May 1995 12:52:20 -0700 Received: from ankh.metrolink.com by ns.metrolink.com with SMTP id AA20325 (5.67b/IDA-1.5 for ); Tue, 9 May 1995 15:52:16 -0400 Received: by ankh.metrolink.com id AA05212 (5.67b/IDA-1.5 for mbone@venera.isi.edu); Tue, 9 May 1995 15:52:13 -0400 From: "Garry M. Paxinos" Message-Id: <199505091952.AA05212@ankh.metrolink.com> Subject: Camera's To: mbone Date: Tue, 9 May 1995 15:52:12 -0400 (EDT) Reply-To: pax@metrolink.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: 594 Hi, We're in a bind and I was hoping someone could point me in the right direction. We need three monitor top style color video cameras by thursday. Where do people get their cameras from (when they don't get them with the workstation?) Thanks, Pax. Metro Link Incorporated. 4711 N. Powerline Rd. Fort Lauderdale Fl, 33309 Voice: +1.305.938.0283x414 Fax: +1.305.938.1982 Email: pax@metrolink.com URL: http://www.flsig.org/people/garryp.html "The real voyage of discovery consists not in seeking new landscapes but in having new eyes." -Proust From list-mgr@ISI.EDU Wed May 10 00:16:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 13:18:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 13:17:44 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 9 May 1995 13:17:10 -0700 Received: from delos (eckert@faui45r.informatik.uni-erlangen.de [131.188.34.54]) by immd4.informatik.uni-erlangen.de with SMTP id WAA06199 (8.6.12/7.4b-FAU);; Tue, 9 May 1995 22:16:48 +0200 From: Toerless Eckert Message-Id: <199505092016.WAA06199@faui40.informatik.uni-erlangen.de> Subject: Re: vat for Linux ? To: van@ee.lbl.gov (Van Jacobson) Date: Tue, 9 May 1995 22:16:43 +0200 (MET DST) Cc: nig@nig.rhoen.de, mbone In-Reply-To: <199505091943.MAA02916@rx7.ee.lbl.gov> from "Van Jacobson" at May 9, 95 12:43:15 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Yes. Three months ago we ordered a machine to run Linux so we > could produce Linux versions of the tools. It showed up today. > Now we just have to get it up & configured then get everything > to compile (putting in ifdefs for all the gratuitous changes to > includes, syscalls & file locations that each variant of unix _each_variant_of_linux_ ? > feels morally oblicated to make). With luck that will only take > a week or two. As soon as they're ready Linux binaries will be You're talking years and chances are good you never catch up. > added to the set on ftp.ee.lbl.gov and we'll announce that fact > on the mbone & rem-conf lists. Greetings fom syssiphus From list-mgr@ISI.EDU Tue May 9 06:17:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 13:17:49 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 13:17:26 -0700 Received: from ece.arizona.edu (ece1.ece.arizona.edu) by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 9 May 1995 13:17:25 -0700 Received: from wynken.ece.arizona.edu.ece.arizona.edu by ece.arizona.edu (5.0/SMI-SVR4) id AA23803; Tue, 9 May 1995 13:17:24 -0700 Date: Tue, 9 May 1995 13:17:24 -0700 From: gmoon@ece.arizona.edu (Gwi Moon) Message-Id: <9505092017.AA23803@ece.arizona.edu> To: mbone Subject: unsubscribe Content-Length: 37 Unsubscribe moongw@ece.arizona.edu From list-mgr@ISI.EDU Wed May 10 01:05:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 14:07:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 14:07:25 -0700 Received: from runix.runit.sintef.no by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 9 May 1995 14:06:22 -0700 Received: from runit.sintef.no by runix.runit.sintef.no id <01396-0@runix.runit.sintef.no>; Tue, 9 May 1995 23:05:47 +0200 Date: Tue, 9 May 1995 23:05:44 +0200 (MET DST) From: Steinar Haug To: Bill Fenner Cc: mbone Subject: Re: Announcing the 3.5 release of SunOS kernel mods In-Reply-To: <95May8.222116pdt.49859@crevenia.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Steinar.Haug@runit.sintef.no > Announcing the 3.5 release of the IP multicasting kernel modifications for > Suns, and the IP multicast routing daemon. > > The SunOS 4.1.x kernel modifications and program binaries are available > from: > > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/ipmulti3.5-sunos41x.tar.Z This is very good news, especially seeing that SunOS 4.1.4 is also supported. I have only one question: Do the if_le.o binaries in the 3.5 distribution include any of the following patches: 101954-06 SunOS 4.1.3_U1: le patch fixing multiple ethernet I/F hang problems 102430-01 SunOS 4.1.4: le patch that fixes sun4m ethernet hang problems Some of us really depend on these patches, and it would be wonderful if we could run the 3.5 IP multicast release *with* these patches. Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug@runit.sintef.no From list-mgr@ISI.EDU Tue May 9 07:34:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 14:35:27 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 14:35:00 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 9 May 1995 14:34:59 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14410(6)>; Tue, 9 May 1995 14:34:50 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Tue, 9 May 1995 14:34:32 -0700 To: Steinar Haug Cc: Bill Fenner , mbone Subject: Re: Announcing the 3.5 release of SunOS kernel mods In-Reply-To: Your message of "Tue, 09 May 95 14:05:44 PDT." Date: Tue, 9 May 1995 14:34:16 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May9.143432pdt.49859@crevenia.parc.xerox.com> In message you write: >Do the if_le.o binaries in the 3.5 distribution include any of the >following patches: No, not yet. I have asked about the possiblity of getting the source to those patches so that we can include them in the distribution. Anyone else have any patch requests? The "icmp spoofing" patches are the only ones that were included. Bill From list-mgr@ISI.EDU Tue May 9 07:53:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 14:57:00 -0700 Received: from isc.sjsu.edu (sparta.SJSU.EDU) by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 9 May 1995 14:56:37 -0700 Received: by isc.sjsu.edu (4.1/25-eef) id AA23225; Tue, 9 May 95 14:53:44 PDT Date: Tue, 9 May 95 14:53:44 PDT From: John Rudd Message-Id: <9505092153.AA23225@isc.sjsu.edu> To: mbone-na Subject: Need help finding a temporary MBONE peer Our provider wont have MBONE up in time for us, and we have two events this month we'd like to broadcast. ONe is this thursday. Is there any way anyone out there can help us by giving us a peer/tunnel feed until our provider can set one up? We're San Jose State University, in San Jose, CA. topologically, we're off of BarNET and CSUNet. John From list-mgr@ISI.EDU Tue May 9 08:58:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 15:59:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 15:59:01 -0700 Received: from california.sandia.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 15:58:56 -0700 Received: (from dgomes@localhost) by california.sandia.gov (8.6.11/1.15) id PAA06298; Tue, 9 May 1995 15:58:48 -0700 From: dgomes@california.sandia.gov (Diane Gomes) Message-Id: <199505092258.PAA06298@california.sandia.gov> Subject: mbone recording tools To: mbone Date: Tue, 9 May 1995 15:58:47 -0700 (PDT) Cc: dgomes@sandia.gov X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 290 I am interested in recording two of the talks broadcasting from DECUS. Do the tools exist to record a mbone session? If so... where are they? Diane Gomes Phone: 510-294-1479 Sandia National Laboratory email: dgomes@ca.sandia.gov P.O. Box 969 MS 9012 Livermore, CA 94551-0969 From list-mgr@ISI.EDU Tue May 9 09:22:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 16:23:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 16:23:32 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 16:23:30 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14663(6)>; Tue, 9 May 1995 16:23:11 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Tue, 9 May 1995 16:23:02 -0700 X-Mailer: exmh version 1.6 4/21/95 To: mbone Cc: fenner@parc.xerox.com Subject: Re: Announcing the 3.5 release of SunOS kernel mods In-Reply-To: Your message of "Mon, 08 May 95 22:21:08 PDT." <95May8.222116pdt.49859@crevenia.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 9 May 1995 16:22:50 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May9.162302pdt.49859@crevenia.parc.xerox.com> The ipmulti3.5-sunos41x.tar file had incorrectly built .o.bpf files, which actually didn't have BPF in them. The file ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/bpf-fixes-3.5.tar.gz has properly built .o.bpf files, and the ipmulti3.5-sunos41x.tar file has been updated as well. Sorry for the inconvenience, but we all knew that *something* had to go wrong with the release =) Bill From list-mgr@ISI.EDU Tue May 9 10:28:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 17:29:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 17:29:08 -0700 Received: from baker.nwnet.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 17:29:06 -0700 Received: by baker.nwnet.net (5.65/UW-NDC Revision: 2.29 ) id AA02628; Tue, 9 May 95 17:28:50 -0700 Date: Tue, 9 May 1995 17:28:49 -0700 (PDT) From: David Comay To: Diane Gomes Cc: mbone, dgomes@sandia.gov Subject: Re: mbone recording tools In-Reply-To: <199505092258.PAA06298@california.sandia.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 9 May 1995, Diane Gomes wrote: > > I am interested in recording two of the talks > broadcasting from DECUS. Do the tools exist to > record a mbone session? If so... where are they? > check for information on tools to record vat, nv and wb sessions plus a media on demand server. dsc From list-mgr@ISI.EDU Tue May 9 14:30:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 21:37:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 21:34:11 -0700 Received: from elroy.jpl.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 21:34:09 -0700 Received: from isolar.tujunga.ca.us by elroy.jpl.nasa.gov (4.1/SMI-4.1+DXR) id AA15586; Tue, 9 May 95 21:34:09 PDT Received: by isolar.Tujunga.CA.US (4.1/SATAN-6.6.6) id AA07284; Tue, 9 May 95 21:30:47 PDT Date: Tue, 9 May 95 21:30:47 PDT From: earle@isolar.Tujunga.CA.US (Greg Earle) Message-Id: <9505100430.AA07284@isolar.Tujunga.CA.US> To: mbone Subject: Cisco (nee Crescendo) Multicast support in 3.2 release for SunOS? I'm in the process of converting our MBONE router from an old Sun-4/380 to a spanking new SPARCserver-20/71 running SunOS 4.1.4. In doing so, we're switching from a hoary old Sun VMEbus FDDI board to a Crescendo (now Cisco) SBus CDDI card in the new system. We've got many other SunOS 4.1.3 systems with these cards running the previous release of the software for them - 3.1. Somehow or other Dave Hayes was able to find a Multicast-aware version of the fddi.load.sun4{c,m}.o driver files for 3.1, so that's what we're using in the other systems. Running "nm" on the driver shows that the Multicast-aware 3.1 version adds the symbols "ether_ipmulticast_max" and "ether_ipmulticast_min"; another routine has gotten larger as well. Cisco has in the interim released version 3.2 of the software. Looking at the release notes for it, I see this cryptic contradictory passage: Other release information : ... 10) The Cisco FDDI network interface driver v3.2 and up provides full support for IP multicasting as specified in RFC 1054 (Host Extensions for IP multicasting). It is designed to work in conjunction with extensions to the SunOS kernel and applications available from Stanford University. These multicast extensions are available for anonymous ftp from the "vtmp-ip" directory on host gregorio.stanford.EDU in the compressed file "ipmulticast.tar.Z". It is however neccesary for anyone wanting to use Multicast that they obtain the IP Multicast version of the Cisco driver. For more information, contact your local Cisco sales representative. Ignoring the fact that their Multicast info is dreadfully out of date, there's this inconsistency: on the one hand they say they support it ("The ... driver v3.2 and up provides full support for IP multicasting") and then they say that you need a special "IP Multicast version" of the driver that supports it ("anyone wanting to use Multicast [must] obtain the IP Multicast version of the Cisco driver"). The newer fddi.load.sun4{m,c}.o that comes with this release does not contain any references to either "ether_ipmulticast_max" or "..._min", although it now contains unresolved references to the kernel's "addmultiaddr" and "delmultiaddr" routines that weren't in the 3.1 drivers. Does anyone know the story here? Does this thing work or do I have to "obtain the IP Multicast version of the Cisco driver"? I'm probably going to try and run with the old known-to-have-Multicast 3.1 version for now (if it works with the new 3.5 release, that is), but I just wondered if anyone else had already gone through this process ... Thanks, - Greg From list-mgr@ISI.EDU Tue May 9 16:41:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 23:42:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 23:41:24 -0700 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 9 May 1995 23:41:19 -0700 Posted-Date: Tue 9 May 95 23:41:06 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 9 May 95 23:41:07 PDT Date: Tue 9 May 95 23:41:06 PDT From: Stephen Casner Subject: Re: DECUS sessions To: MBONE@dec486.dc95.show.decus.org, MBONE, rem-conf@es.net Message-Id: <800088066.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9505091814.AA03831@dec486.dc95.show.decus.org> Mail-System-Version: Sending two video streams would be technically feasible so long as there are no other concurrent sessions. For example, from the recent IETF meetings, two channels of audio+video have been transmitted. However, if another session is also sending audio+video, it would be best for you to limit your transmissions to 1 stream. Or, transmit two but with the data rate of each cut back to 64Kb/s. > Once it gets to our service provider, > mrouters would distribute the packets to listeners based on what > stream they were trying to receive. That's the theory, but because there are many mrouters in the MBone that are still running the non-pruning (2.x) release, traffic goes many places where it is not wanted/needed. We hope that with the 3.5 release of the multicast software, vendor ports will be done soon and all the nodes will be upgraded. -- Steve ------- From list-mgr@ISI.EDU Wed May 10 00:09:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 00:09:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 00:09:03 -0700 Received: from ns.riken.go.jp by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 00:09:00 -0700 Received: from RIKAX1.riken.go.jp by ns.riken.go.jp (8.6.8.1/TISN-1.3M/R2) id QAA00848; Wed, 10 May 1995 16:08:59 +0900 Received: by rikax1.riken.go.jp (MX V4.1 AXP) id 19; Wed, 10 May 1995 16:08:14 JST Date: Wed, 10 May 1995 16:08:13 JST From: "Takashi Ichihara " To: mbone Cc: ichihara@rikax1.riken.go.jp Message-Id: <00990278.B7B7AC70.19@rikax1.riken.go.jp> Subject: [Q] Latest version of mrouted for DEC OSF/1 ? Hi folks We have several SUN OS 4.1.3 and DEC OSF/1 (V2.0, V3.0) on which mrouted process are running. On SUN OS 4.1.3, I have already replaced the mrouted to V3.5. On DEC OSF/1, we are still using mrouted V 2.2 (special patched version for DEC OSF/1). Does anyone know the newer (patched) version (later than V2.2) of mrouted which can run on DEC OSF/1 ? Thanks for the information. Takashi Ichihara (Ichihara@rikvax.riken.go.jp) From list-mgr@ISI.EDU Tue May 9 20:35:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 03:36:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 03:35:13 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 03:35:11 -0700 Received: by rx7.ee.lbl.gov (8.6.11/1.43r) id DAA03877; Wed, 10 May 1995 03:35:42 -0700 Message-Id: <199505101035.DAA03877@rx7.ee.lbl.gov> To: mbone Subject: Russian host video.radio-msu.net sending 500kb/s video at ttl 255 Date: Wed, 10 May 95 03:35:41 PDT From: Van Jacobson The host video.radio-msu.net (193.124.134.100) in Moscow is sending nv video to 224.15.15.15/4444 at ttl 255. This is a bad idea. Mail doesn't seem to be configured properly on this machine so I don't know how to ask them to stop. Perhaps whoever supplies their tunnel could explain mbone etiquette to them. Thanks. - Van From list-mgr@ISI.EDU Wed May 10 02:53:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 03:56:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 03:55:34 -0700 Received: from andy.dia.atd.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 03:55:32 -0700 Received: (from crobson@localhost) by andy.dia.atd.net (8.6.9/8.6.9) id GAA00600; Wed, 10 May 1995 06:53:19 -0400 Date: Wed, 10 May 1995 06:53:19 -0400 (EDT) From: Chris Robson ATDNet Admin Subject: Re: vat for Linux ? To: Van Jacobson Cc: Frank Mueller , mbone In-Reply-To: <199505091943.MAA02916@rx7.ee.lbl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone know if Linux has been patched to do multicast yet? If so which release (slackware?) ...chris On Tue, 9 May 1995, Van Jacobson wrote: > > Hello, is there any chance to see vat on linux ? or wb or sd ? > > Yes. Three months ago we ordered a machine to run Linux so we > could produce Linux versions of the tools. It showed up today. > Now we just have to get it up & configured then get everything > to compile (putting in ifdefs for all the gratuitous changes to > includes, syscalls & file locations that each variant of unix > feels morally oblicated to make). With luck that will only take > a week or two. As soon as they're ready Linux binaries will be > added to the set on ftp.ee.lbl.gov and we'll announce that fact > on the mbone & rem-conf lists. > > - Van > From list-mgr@ISI.EDU Wed May 10 11:18:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 04:20:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 04:19:14 -0700 Received: from satty.npi.msu.su by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 04:18:50 -0700 Received: (from dima@localhost) by satty.npi.msu.su (8.6.11/8.6.9) id LAA00289; Wed, 10 May 1995 11:18:16 GMT Date: Wed, 10 May 1995 11:18:15 +0000 () From: Dmitry Khrustalev X-Sender: dima@satty.npi.msu.su To: Van Jacobson Cc: mbone Subject: Re: Russian host video.radio-msu.net sending 500kb/s video at ttl 255 In-Reply-To: <199505101035.DAA03877@rx7.ee.lbl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 10 May 1995, Van Jacobson wrote: > The host video.radio-msu.net (193.124.134.100) in Moscow is sending > nv video to 224.15.15.15/4444 at ttl 255. This is a bad idea. Mail > doesn't seem to be configured properly on this machine so I don't > know how to ask them to stop. Perhaps whoever supplies their tunnel > could explain mbone etiquette to them. Thanks. > Annihilated. -Dima. > > - Van > From list-mgr@ISI.EDU Thu May 11 07:32:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 04:34:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 04:33:13 -0700 Received: from jello.qabc.uq.oz.au by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 04:33:10 -0700 Received: (from jason@localhost) by jello.qabc.uq.oz.au (8.6.10/8.6.6) id VAA12691 for mbone@ISI.EDU; Wed, 10 May 1995 21:32:06 +1000 From: jason andrade Message-Id: <199505101132.VAA12691@jello.qabc.uq.oz.au> Subject: Re: vat for Linux ? To: mbone Date: Wed, 10 May 1995 21:32:06 +1000 (EST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 538 > > Does anyone know if Linux has been patched to do multicast yet? > If so which release (slackware?) > > ...chris I believe linux has had multicast in its kernel (officially) since the 1.2 release (the kernel is >= 1.2.7 now). I have heard of / seen linux vat/nv binaries, but not had a chance to get them or use them (yet). I _haven't_ been able to find a linux mrouted though. Try poking around on nic.funet.fi. I haven't seen vat/nv/vic binaries rebuilt for netbsd-1.0 yet either i think. (0.9 release stuff still there?) -jason From list-mgr@ISI.EDU Thu May 11 05:49:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 04:50:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 04:49:39 -0700 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 04:49:36 -0700 Received: from alpha503.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id UAA23785; Wed, 10 May 1995 20:49:33 +0900 Return-Path: Received: from localhost by alpha503.aist-nara.ac.jp (5.67+1.6W[kuis-17]/2.8Wb/NAIST-1.3[is]) id AA18328; Wed, 10 May 95 20:49:31 GMT+0900 Message-Id: <9505101149.AA18328@alpha503.aist-nara.ac.jp> To: jason andrade Cc: mbone Reply-To: oka@is.aist-nara.ac.jp Subject: Re: vat for Linux ? In-Reply-To: Your message of Wed, 10 May 1995 21:32:06 +1000. <199505101132.VAA12691@jello.qabc.uq.oz.au> Mime-Version: 1.0 Content-Type: text/plain;charset="ISO-2022-JP" Date: Wed, 10 May 1995 20:49:30 +0900 From: Koji OKAMURA > I believe linux has had multicast in its kernel (officially) since > the 1.2 release (the kernel is >= 1.2.7 now). I have heard of / seen > linux vat/nv binaries, but not had a chance to get them or use them > (yet). I _haven't_ been able to find a linux mrouted though. Try I have compiled nv and vic on linux. ftp://ftp.jain.ad.jp/pub/linux/ -- oka From list-mgr@ISI.EDU Wed May 10 07:56:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 08:58:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 08:58:07 -0700 Received: from aotearoa (aotearoa.sura.net) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 08:58:04 -0700 Received: from localhost.sura.net by aotearoa with SMTP (8.6.12/($Id: sendmail.cf,v 1.17 1991/02/11 14:07:23 jmalcolm Exp $)) id LAA09553; Wed, 10 May 1995 11:56:58 -0400 Message-Id: <199505101556.LAA09553@aotearoa> To: Bill Fenner Cc: mbone Subject: Re: Announcing the 3.5 release of SunOS kernel mods In-Reply-To: Your message of "Tue, 09 May 1995 16:22:50 PDT." <95May9.162302pdt.49859@crevenia.parc.xerox.com> Date: Wed, 10 May 1995 11:56:58 -0400 From: Erik Sherk > The ipmulti3.5-sunos41x.tar file had incorrectly built .o.bpf files, which > actually didn't have BPF in them. The file > > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/bpf-fixes-3.5.tar.gz > > has properly built .o.bpf files, and the ipmulti3.5-sunos41x.tar file has been > updated as well. Sorry for the inconvenience, but we all knew that > *something* had to go wrong with the release =) > > Bill > Bill, Are the Sun Sparc 5 audio patches included/documented in this release? Erik From list-mgr@ISI.EDU Wed May 10 08:42:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 09:44:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 09:43:50 -0700 Received: from home.merit.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 09:43:49 -0700 Received: from localhost (ljb@localhost) by home.merit.edu (8.6.12/merit-2.0) with SMTP id MAA08672; Wed, 10 May 1995 12:42:48 -0400 Message-Id: <199505101642.MAA08672@home.merit.edu> To: Bill Fenner Cc: Steinar Haug , mbone Subject: Re: Announcing the 3.5 release of SunOS kernel mods In-Reply-To: Your message of "Tue, 09 May 1995 14:34:16 PDT." <95May9.143432pdt.49859@crevenia.parc.xerox.com> Date: Wed, 10 May 1995 12:42:47 -0400 From: "Larry J. Blunk" > In message you write: > >Do the if_le.o binaries in the 3.5 distribution include any of the > >following patches: > > No, not yet. I have asked about the possiblity of getting the source to > those patches so that we can include them in the distribution. > > Anyone else have any patch requests? The "icmp spoofing" patches are > the only ones that were included. > > Bill 102010-01 SunOS 4.1.3_U1: system freezes using loopback interface. has a modified tcp_input.o 101790-01 SunOS 4.1.3_U1: TCP socket and reset problems has a modified ip_output.o -Larry Blunk Merit Network, Inc. From list-mgr@ISI.EDU Wed May 10 10:47:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 11:47:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 11:47:12 -0700 Received: from turing.mathworks.com by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 11:47:11 -0700 Received: from zippy (mbone-internal.mathworks.com [144.212.200.6]) by turing.mathworks.com (8.6.11/8.6-dp) with ESMTP id OAA11451 for ; Wed, 10 May 1995 14:47:10 -0400 Received: from localhost id OAA23473; Wed, 10 May 1995 14:47:09 -0400 Date: Wed, 10 May 1995 14:47:09 -0400 (EDT) From: Dave Pascoe X-Sender: pascoe@zippy To: mbone Subject: nv_record to record vic/H.261? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is nv_record supposed to be able to record vic format video? I can't seem to get it to record anything but nv video. Looking for a quick direct response......I'll summarize for the list if there's enough interest. Thanks.... --- Dave Pascoe Amateur Radio: KM3T E-Mail: pascoe@mathworks.com WWW: http://www.mathworks.com PGP key fingerprint = FB D2 E2 0C 62 CB 05 98 32 59 6F E4 2C D2 AF EE From list-mgr@ISI.EDU Wed May 10 17:05:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 13:09:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 13:00:48 -0700 Received: from relay.xlink.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 13:00:47 -0700 Received: from odb.rhein-main.de by relay.xlink.net id <27950-0@relay.xlink.net>; Wed, 10 May 1995 22:00:40 +0000 Received: from buchonia by odb.rhein-main.de with uucp (Smail3.1.28.1 #5) id m0s9Hvn-0007RrC; Wed, 10 May 95 22:00 MET DST Received: from nig by buchonia.rhoen.de with uucp (Smail3.1.28.1 #5) id m0s9EmA-000EmHC; Wed, 10 May 95 18:38 MET DST Received: by nig.rhoen.de (Smail3.1.28.1 #6) id m0s9FCg-000DiFC; Wed, 10 May 95 17:05 GMT Message-Id: From: nig@nig.rhoen.de (Frank Mueller) Subject: vat + linux To: mbone Date: Wed, 10 May 1995 17:05:39 +0000 (GMT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 751 > I believe linux has had multicast in its kernel (officially) since > the 1.2 release (the kernel is >= 1.2.7 now). I have heard of / seen > linux vat/nv binaries, but not had a chance to get them or use them > (yet). nv3.3b and ivs3.4 works fine. I've already included support for the ScreenMachine II framegrabber for both. So far no sucess with vic. You can find a binary nv with SMII support on: http://www.hrz.uni-giessen.de/~l018/nig.html ivs with SMII support should be soon there.. Bye Frank -- Frank Mueller http://www.hrz.uni-giessen.de/~l018/nig.html E-Mail: (nig@nig.rhoen.de) ! Please under 100 KB ! IN-kompetent e.V. -* CONNECTING PEOPLE -* Verein zur Foerderung der privaten Datenkommunikation Rhoen/Vogelsberg From list-mgr@ISI.EDU Wed May 10 11:19:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 14:20:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 14:20:32 -0700 Received: from dfw.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 14:20:31 -0700 Received: by dfw.net (4.1/SMI-4.1) id AA24749; Wed, 10 May 95 16:19:49 CDT Date: Wed, 10 May 1995 16:19:48 -0500 (CDT) From: Aleph One Cc: mbone Subject: Re: vat + linux In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I belive the original poster meant when we would see DVMRP on linux and have mrouted ported. I know of several people that have expresed interest in this (including myself) but we all either lack kernel hacking skills, or time. BTW, since we are on this topicI always wondered why is part of DVMRP in ther kernel and part in mrouted? Why not simply have mrouted do all the DVMRP stuff just like routed does all RIP processing? > > I believe linux has had multicast in its kernel (officially) since > > the 1.2 release (the kernel is >= 1.2.7 now). I have heard of / seen > > linux vat/nv binaries, but not had a chance to get them or use them > > (yet). > From list-mgr@ISI.EDU Wed May 10 13:43:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 16:26:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 16:25:33 -0700 Received: from turing.mathworks.com by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 16:25:31 -0700 Received: from zippy (mbone-internal.mathworks.com [144.212.200.6]) by turing.mathworks.com (8.6.11/8.6-dp) with ESMTP id RAA22723 for ; Wed, 10 May 1995 17:43:15 -0400 Received: from localhost id RAA25326; Wed, 10 May 1995 17:43:14 -0400 Date: Wed, 10 May 1995 17:43:13 -0400 (EDT) From: Dave Pascoe X-Sender: pascoe@zippy To: mbone Subject: Do u have Linux/DECUS video recorded? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII If so, I'd be interested in ftp'ing the files.....I have all the audio but couldn't get the RTP v2 recording stuff going in time to get the video portion of Linus Torvald's talk. Please e-mail..... Thanks, Dave Pascoe pascoe@mathworks.com From list-mgr@ISI.EDU Wed May 10 10:11:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 17:13:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 17:12:43 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 17:12:41 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14765(1)>; Wed, 10 May 1995 17:12:14 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Wed, 10 May 1995 17:11:51 -0700 X-Mailer: exmh version 1.6 4/21/95 To: Aleph One Cc: mbone Subject: Re: vat + linux In-Reply-To: Your message of "Wed, 10 May 95 14:19:48 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 May 1995 17:11:44 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May10.171151pdt.49859@crevenia.parc.xerox.com> In message you write: >BTW, since we are on this topicI always wondered why is part of >DVMRP in ther kernel and part in mrouted? Why not simply have mrouted >do all the DVMRP stuff just like routed does all RIP processing? Indeed, in the 3.x multicast releases, mrouted does all the DVMRP-related stuff, and the kernel simply has a routing-protocol independent multicast route cache. Bill From list-mgr@ISI.EDU Wed May 10 12:43:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 19:46:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 19:45:11 -0700 Received: from decu13.Triumf.CA by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 10 May 1995 19:45:08 -0700 Received: by decu13.triumf.ca (5.65/DEC-Ultrix/4.3) id AA04578; Wed, 10 May 1995 19:44:03 -0700 Date: Wed, 10 May 1995 19:43:49 -0700 (PDT) From: Andrew Daviel To: mbone Subject: Linux mbone/multicast FAQ Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm trying to maintain a FAQ for Linux stuff. Please mail me if something's missing, or incorrect. http://andrew.triumf.ca/pub/linux/multicast-FAQ Andrew Daviel email: advax@triumf.ca TRIUMF voice: 604-222-7376 4004 Wesbrook Mall fax: 604-222-7307 Vancouver BC http://andrew.triumf.ca/~andrew Canada V6T 2A3 49D14.7N 123D13.6W From list-mgr@ISI.EDU Fri May 12 00:11:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 01:09:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 01:09:23 -0700 Received: from sunstation2.tsinghua.edu.cn ([166.111.8.10]) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 01:09:11 -0700 Received: from csnet4.tsinghua.edu.cn ([166.111.166.17]) by sunstation2.tsinghua.edu.cn (4.1/SMI-4.1) id AA10614; Thu, 11 May 95 16:08:37 CDT Received: by csnet4.tsinghua.edu.cn (5.0/SMI-SVR4) id AA02783; Thu, 11 May 1995 16:11:11 --800 Date: Thu, 11 May 1995 16:11:11 --800 From: wsg@csnet4.tsinghua.edu.cn (Wu Shangguang) Message-Id: <9505110711.AA02783@csnet4.tsinghua.edu.cn> To: mbone Subject: VAT source code? Want to know DVI ADPCM! X-Sun-Charset: US-ASCII Content-Length: 194 Hi, I'd like to know Intel/DVI ADPCM audio coding algorithm, who know about it? Or you may tell me where to get VAT source code, while VAT support DVI ADPCM coding algorithm. Thanks Andy Wu From list-mgr@ISI.EDU Thu May 11 12:32:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 01:34:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 01:33:21 -0700 Received: from jerry.inria.fr by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 01:33:15 -0700 Received: by jerry.inria.fr (8.6.12/8.6.12) id KAA15037; Thu, 11 May 1995 10:32:34 +0200 Message-Id: <199505110832.KAA15037@jerry.inria.fr> To: wsg@csnet4.tsinghua.edu.cn (Wu Shangguang) Cc: mbone Subject: Re: VAT source code? Want to know DVI ADPCM! In-Reply-To: Your message of Thu, 11 May 1995 16:11:11. <9505110711.AA02783@csnet4.tsinghua.edu.cn> Reply-To: Thierry.Turletti@sophia.inria.fr Date: Thu, 11 May 1995 10:32:33 +0200 From: Thierry Turletti >I'd like to know Intel/DVI ADPCM audio coding algorithm, who know >about it? > >Or you may tell me where to get VAT source code, while VAT support >DVI ADPCM coding algorithm. VAT source code is not available. The Intel/DVI ADPCM codec is also implemented in IVS and NEVOT and you cand find source of both on the public domain. http://www.inria.fr/rodeo/ivs.html http://www.fokus.gmd.de:80/step/employees/hgs/nevot/nevot.html Regards, Thierry Turletti From list-mgr@ISI.EDU Thu May 11 14:21:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 03:22:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 03:21:32 -0700 Received: from charon.cwi.nl by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 03:21:25 -0700 Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP id ; Thu, 11 May 1995 12:21:23 +0200 Received: by schelvis.cwi.nl with SMTP id ; Thu, 11 May 1995 12:21:23 +0200 Message-Id: <9505111021.AA21330=jack@schelvis.cwi.nl> To: wsg@csnet4.tsinghua.edu.cn (Wu Shangguang) Cc: mbone Subject: Re: VAT source code? Want to know DVI ADPCM! In-Reply-To: Message by wsg@csnet4.tsinghua.edu.cn (Wu Shangguang) , Thu, 11 May 1995 16:11:11 --800 , <9505110711.AA02783@csnet4.tsinghua.edu.cn> Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam Phone: +31 20 5924098(work), +31 20 5924199 (fax), +31 20 6160335(home) X-Last-Band-Seen: Painting over Picasso, Bob Color, etc (Bevrijdingsdag) X-Mini-Review: Sound was lousy, bands were great. Date: Thu, 11 May 1995 12:21:22 +0200 From: Jack Jansen Recently, wsg@csnet4.tsinghua.edu.cn (Wu Shangguang) said: > Hi, > > I'd like to know Intel/DVI ADPCM audio coding algorithm, who know > about it? You can find code in ftp://ftp.cwi.nl/pub/audio/adpcm.shar. About the design of the algorithm: I have been unable to find any information on it (i.e. how they designed the delta-tables, etc). On the other hand: the algorithm works, so why worry:-) -- Jack Jansen | If I can't dance I don't want to be part of Jack.Jansen@cwi.nl | your revolution -- Emma Goldman uunet!cwi.nl!jack G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl From list-mgr@ISI.EDU Thu May 11 05:44:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 06:45:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 06:44:47 -0700 Received: from nrcnet0.nrc.ca by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 06:44:45 -0700 Received: from alpha.ps.iit.nrc.ca by nrcnet0.nrc.ca with SMTP id AA15044 (5.67b/IDA-1.5 for ); Thu, 11 May 1995 09:44:43 -0400 Received: by alpha.ps.iit.nrc.ca; (5.65/1.1.8.2/26Apr95-1200PM) id AA23994; Thu, 11 May 1995 09:44:49 -0400 Date: Thu, 11 May 1995 09:44:49 -0400 From: Rao Palacharla Message-Id: <9505111344.AA23994@alpha.ps.iit.nrc.ca> To: mbone Subject: questions on mrouted(SGI)/parallax/J300 mbone tools I have a few questions regarding mrouted and MBONE tools. 1. I was trying to create a tunnel between two workstations (SGI Indy and DEC Alpha) which are on the same subnet. The two workstations are connected thru a Cisco 7000 router. SGI is running Irix 5.2 and is not able to run the mrouted which comes bundled with the system. The mrouted exits complaining that it cannot create a tunnel between workstations on the same subnet. Is there any fix for it? I beleive there is filtering being done at the Cisco which doesnt allow multicast packets. Any suggestions/comments are welcome. 2. Is there any support for Parallax boards in the MBONE video tools (nv, vic)? If so, where can I ftp them? 3. On the DEC Alpha, when will the MBONE tools be supported with the DEC Multimedia Services Drivers for J300 (which are available from Digital)? thanx a lot (in advance) bye rao e-mail: rao@alpha.ps.iit.nrc.ca From list-mgr@ISI.EDU Thu May 11 12:37:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 06:51:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 06:50:31 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 06:50:29 -0700 Received: from faui45.informatik.uni-erlangen.de by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 11 May 1995 06:45:50 -0700 Received: from faui40.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA25774 (5.65c-7/7.3w-FAU); Thu, 11 May 1995 10:44:22 +0200 Received: from delos (eckert@faui45r.informatik.uni-erlangen.de [131.188.34.54]) by immd4.informatik.uni-erlangen.de with SMTP id KAA24264 (8.6.12/7.4b-FAU); for ; Thu, 11 May 1995 10:37:36 +0200 From: Toerless Eckert Message-Id: <199505110837.KAA24264@faui40.informatik.uni-erlangen.de> Subject: IP multicast for HP-UX 9.03 ? To: mbone Date: Thu, 11 May 1995 10:37:32 +0200 (MET DST) Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Could someone point me to a person or ftp location that could provide me with the required patches/upgrades to run multicast applications on HP-UX 9.03 ? Thanks -- Toerless Eckert Universitaet Erlangen Nuernberg Lehrstuhl fuer Betriebsysteme Martensstrasse 1 D-91058 Erlangen, Germany Tel.: +49 9131 85 7278 FAX: +49 9131 85 8732 / +49 9131 39388 Toerless.Eckert@Informatik.Uni-Erlangen.DE /C=De/A=D400/P=Uni-Erlangen/OU=Informatik/S=Eckert/G=Toerless/ From list-mgr@ISI.EDU Thu May 11 07:11:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 08:11:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 08:11:39 -0700 Received: from home.merit.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 08:11:38 -0700 Received: from localhost (ljb@localhost) by home.merit.edu (8.6.12/merit-2.0) with SMTP id LAA12228; Thu, 11 May 1995 11:11:14 -0400 Message-Id: <199505111511.LAA12228@home.merit.edu> To: Bill Fenner Cc: Steinar Haug , mbone Subject: Re: Announcing the 3.5 release of SunOS kernel mods In-Reply-To: Your message of "Wed, 10 May 1995 12:42:47 EDT." <199505101642.MAA08672@home.merit.edu> Date: Thu, 11 May 1995 11:11:08 -0400 From: "Larry J. Blunk" > > > In message you write: > > >Do the if_le.o binaries in the 3.5 distribution include any of the > > >following patches: > > > > No, not yet. I have asked about the possiblity of getting the source to > > those patches so that we can include them in the distribution. > > > > Anyone else have any patch requests? The "icmp spoofing" patches are > > the only ones that were included. > > > > Bill > > 102010-01 SunOS 4.1.3_U1: system freezes using loopback interface. > has a modified tcp_input.o > > 101790-01 SunOS 4.1.3_U1: TCP socket and reset problems > has a modified ip_output.o > Oh and I forgot about the following patch. Has this been integrated? We've been bitten by this bug before. 101438-01 SunOS 4.1.3_U1: applications bind to same port if IP address supplied -replaces in_pcb.o Larry Blunk Merit Network, Inc. From list-mgr@ISI.EDU Thu May 11 01:59:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 09:01:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 08:59:29 -0700 Received: from glare.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 08:59:27 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA29244; Thu, 11 May 1995 08:59:24 -0700 Message-Id: <199505111559.IAA29244@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Rao Palacharla Cc: mbone Subject: Re: questions on mrouted(SGI)/parallax/J300 mbone tools In-Reply-To: Your message of "Thu, 11 May 1995 09:44:49 EDT." <9505111344.AA23994@alpha.ps.iit.nrc.ca> Date: Thu, 11 May 1995 08:59:23 -0700 From: "John M. Zwiebel" Rao: You said: > 1. I was trying to create a tunnel between two workstations (SGI Indy > and DEC Alpha) which are on the same subnet. The two workstations are > connected thru a Cisco 7000 router. SGI is running Irix 5.2 and is not > able to run the mrouted which comes bundled with the system. The mrouted exits > complaining that it cannot create a tunnel between workstations on the > same subnet. Is there any fix for it? I beleive there is filtering > being done at the Cisco which doesnt allow multicast packets. Any > suggestions/comments are welcome. If the two workstations are on the same subnet, what do you mean when you say there is there a router between them? Is it bridging only? If they are on the same subnet you don't want a tunnel between the workstations. The traffic should be forwarded natively. ie not encapsulated in a tunnel packet. The router will not forward the multicast packets unless you turn on ip multicast routing. (PIM not DVRMP so you have to consider the interactions between the two protocols.) The router will forward DVMRP tunnel packets unless someone has specifically set up an access list to filter these packets. Forwarding DVMRP tunnel packets has nothing to do with multicast routing. It is a unicast routing decision only from the routers perspective. You can set up a DVMRP tunnel to the router depending on what you are trying to do. z From list-mgr@ISI.EDU Thu May 11 02:41:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 09:54:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 09:54:38 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 09:54:37 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14844(2)>; Thu, 11 May 1995 09:41:16 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Thu, 11 May 1995 09:41:04 -0700 To: "Larry J. Blunk" Cc: Bill Fenner , Steinar Haug , mbone Subject: Re: Announcing the 3.5 release of SunOS kernel mods In-Reply-To: Your message of "Thu, 11 May 95 08:11:08 PDT." <199505111511.LAA12228@home.merit.edu> Date: Thu, 11 May 1995 09:41:01 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May11.094104pdt.49859@crevenia.parc.xerox.com> In message <199505111511.LAA12228@home.merit.edu> you write: > Oh and I forgot about the following patch. Has this been integrated? >We've been bitten by this bug before. > >101438-01 SunOS 4.1.3_U1: applications bind to same port if IP address supplie > d A fix for this is included; not the Sun patch, but a fix written by Richard Black and posted to the MBONE mailing list. Bill From list-mgr@ISI.EDU Thu May 11 03:35:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 10:36:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 10:36:06 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 10:36:03 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14572(4)>; Thu, 11 May 1995 10:35:50 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Thu, 11 May 1995 10:35:42 -0700 To: Rao Palacharla Cc: mbone, fenner@parc.xerox.com Subject: Re: questions on mrouted(SGI)/parallax/J300 mbone tools In-Reply-To: Your message of "Thu, 11 May 95 06:44:49 PDT." <9505111344.AA23994@alpha.ps.iit.nrc.ca> Date: Thu, 11 May 1995 10:35:41 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May11.103542pdt.49859@crevenia.parc.xerox.com> In message <9505111344.AA23994@alpha.ps.iit.nrc.ca> you write: >1. I was trying to create a tunnel between two workstations (SGI Indy >and DEC Alpha) which are on the same subnet. The two workstations are >connected thru a Cisco 7000 router. These two statements contradict each other. If they are on the same subnet, why is there a router in the middle? The multicast code can't handle strange physical layer tricks that are not reflected in the IP layer. A subnet has to be a subnet. Bill From list-mgr@ISI.EDU Thu May 11 03:40:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 10:42:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 10:41:38 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 10:41:37 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14743(5)>; Thu, 11 May 1995 10:40:59 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Thu, 11 May 1995 10:40:44 -0700 To: mit@huie.hokudai.ac.jp Cc: tg@bosun.wblab.lu.se, mbone Subject: Re: Help!. different subnet mask and mrouted In-Reply-To: Your message of "Sun, 07 May 95 19:07:13 PDT." <9505080207.AA07991@iees1.ieee.hokudai.ac.jp> Date: Thu, 11 May 1995 10:40:28 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May11.104044pdt.49859@crevenia.parc.xerox.com> In message <9505080207.AA07991@iees1.ieee.hokudai.ac.jp> you write: >any more suggestion ?? Install multicast release 3.5 on all of your mrouters, and add commands like phyint le0 netmask 255.255.255.0 to your /etc/mrouted.conf files. If there is more than one IP subnet on a physical wire, you might also want phyint le0 netmask 255.255.255.0 altnet 133.50.X.0 altnet 133.50.Y.0 Bill From list-mgr@ISI.EDU Thu May 11 10:07:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 11:10:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 11:09:18 -0700 Received: from vax.darpa.mil (darpa.mil) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 11:09:16 -0700 Received: from next146.darpa.mil (next146.darpa.mil) by vax.darpa.mil (5.65c/5.61+local-5) id ; Thu, 11 May 1995 14:08:25 -0400 Received: by next146.darpa.mil (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA09306; Thu, 11 May 95 14:07:03 EDT Date: Thu, 11 May 1995 14:07:01 -0400 (EDT) From: bmiller@csto.snap.org Subject: Re: questions on mrouted(SGI)/parallax/J300 mbone tools To: Bill Fenner Cc: Rao Palacharla , mbone, fenner@parc.xerox.com Message-Id: <950511140701.8789AABmK.bmiller@next146> In-Reply-To: <95May11.103542pdt.49859@crevenia.parc.xerox.com> Mime-Version: 1.0 (Generated by Eloquent) Content-Type: text/plain; charset=US-ASCII X-Mailer: Eloquent[2.01]; Eloquent is a Trademark of Take 3 |>>1. I was trying to create a tunnel between two workstations (SGI Indy |>>and DEC Alpha) which are on the same subnet. The two workstations are |>>connected thru a Cisco 7000 router. |> |>These two statements contradict each other. If they are on the same |>subnet, why is there a router in the middle? |> |>The multicast code can't handle strange physical layer tricks that are not |>reflected in the IP layer. A subnet has to be a subnet. They could be bridged (sometimes you have to make do with whatever equipment you have at hand :) ). I wouldn't think that would kill off multicast traffic tho - I've run similar setups (using standard bridges, not a router acting like one), and not had any problem with the multicast traffic getting to both network segments. brian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The System Administrator formerly known as Brian Miller bmiller@csto.snap.org brian@cfar.umd.edu Killing people is not the solution, but it's a damn fine way to make sure they stop bothering you until you find a better way to deal with them. From list-mgr@ISI.EDU Thu May 11 06:25:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 13:26:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 13:25:54 -0700 Received: from hp.com by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 13:25:52 -0700 Received: from hpindlm.cup.hp.com by hp.com with ESMTP (1.37.109.15/15.5+ECS 3.3) id AA067523948; Thu, 11 May 1995 13:25:50 -0700 Received: by hpindlm.cup.hp.com (1.37.109.16/15.5+IOS 3.20+cup+OMrelay) id AA016253923; Thu, 11 May 1995 13:25:23 -0700 From: Ming Ming Chen Message-Id: <199505112025.AA016253923@hpindlm.cup.hp.com> Subject: Re: Announcing the 3.5 release of SunOS kernel mods To: fenner@parc.xerox.com (Bill Fenner) Date: Thu, 11 May 95 13:25:23 PDT Cc: ljb@merit.edu, Steinar.Haug@runit.sintef.no, mbone In-Reply-To: <95May11.094104pdt.49859@crevenia.parc.xerox.com>; from "Bill Fenner" at May 11, 95 9:41 am Mailer: Elm [revision: 70.85] Do you have any plan for PIM? Thanks Ming From list-mgr@ISI.EDU Thu May 11 06:49:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 13:50:49 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 13:50:17 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 13:50:16 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14758(6)>; Thu, 11 May 1995 13:49:34 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Thu, 11 May 1995 13:49:17 -0700 To: Ming Ming Chen Cc: fenner@parc.xerox.com (Bill Fenner), ljb@merit.edu, Steinar.Haug@runit.sintef.no, mbone Subject: Re: Announcing the 3.5 release of SunOS kernel mods In-Reply-To: Your message of "Thu, 11 May 95 13:25:23 PDT." <199505112025.AA016253923@hpindlm.cup.hp.com> Date: Thu, 11 May 1995 13:49:14 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May11.134917pdt.49859@crevenia.parc.xerox.com> In message <199505112025.AA016253923@hpindlm.cup.hp.com> you write: >Do you have any plan for PIM? The forthcoming "gated" release that supports dense-mode PIM should run on top of the 3.5 multicast kernel. Bill From list-mgr@ISI.EDU Thu May 11 02:32:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 15:33:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 15:33:22 -0700 Received: from mpg.phys.Hawaii.Edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 15:33:20 -0700 Received: by mpg.phys.hawaii.edu (4.1/SMI-4.1) id AA25905; Thu, 11 May 95 12:32:22 HST Date: Thu, 11 May 1995 12:32:21 -1000 (HST) From: Antonio Querubin To: mbone Subject: mbone apps for SGI? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Anybody know where I can find mrouted and mbone applications (source or binaries) for SGI boxes? Antonio Querubin tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org From list-mgr@ISI.EDU Fri May 12 12:05:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 23:09:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 23:06:34 -0700 Received: from lohi.dat.tele.fi by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 11 May 1995 23:06:19 -0700 Message-Id: <199505120606.AA12064@venera.isi.edu> Received: from lohi.dat.tele.fi by lohi.dat.tele.fi id <00926-0@lohi.dat.tele.fi>; Fri, 12 May 1995 09:05:48 +0300 To: nig@nig.rhoen.de Cc: mbone In-Reply-To: Subject: Re: vat + linux Date: Fri, 12 May 1995 09:05:48 +0300 From: Juha Heinanen Sender: Juha.Heinanen@lohi.dat.tele.fi nv3.3b and ivs3.4 works fine. I've already included support for the ScreenMachine II framegrabber for both. people are telling me that screen machine ii is a very expensive board and is being replaced by movie machine ii from the same vendor. do you plan to support also the latter? -- juha From list-mgr@ISI.EDU Fri May 12 13:38:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 12 May 1995 04:38:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 12 May 1995 04:34:09 -0700 Received: from cd1.lrz-muenchen.de by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 12 May 1995 04:33:56 -0700 Received: from sunmanager.lrz-muenchen.de by cd1.lrz-muenchen.de; Fri, 12 May 95 11:38:31 +0200 Received: by sunmanager.lrz-muenchen.de (4.1/SMI-4.1) id AA00566; Fri, 12 May 95 11:38:30 +0200 From: Thomas.Bonk@lrz-muenchen.de (Thomas Bonk) Message-Id: <9505120938.AA00566@sunmanager.lrz-muenchen.de> Subject: MBONE in South America? To: mbone Date: Fri, 12 May 1995 11:38:30 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 945 Hello I want to establish a conference connection (audio and video if possible) between Munich and Lima/Peru via MBONE. So I have some questions on this topic: 1. Does there exist an MBONE-Connection to South America especially to Lima/Peru? (I guess: no) 2. Is there anybody who can tell me what links to Lima exist especially their band width? Does it make sense to install an mrouted in Lima? 3. Has anybody experience with mbone-connections to sites far away from the "Information Highways"? Any replies appreciated. -- ============================================================================= Thomas Bonk Leibniz Rechenzentrum, Barer Str. 21, D-80333 Muenchen, Germany, Tel: ++49-89-2105-8839, Fax ++49-89-2809460 EMAIL: Thomas.Bonk@lrz-muenchen.de URL: http://www.lrz-muenchen.de/Persons/thomas_bonk_ge.html IRC: Jamesb ============================================================================= From list-mgr@ISI.EDU Fri May 12 17:36:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 12 May 1995 08:38:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 12 May 1995 08:37:58 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 12 May 1995 08:37:57 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 12 May 1995 08:37:09 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 12 May 1995 16:36:11 +0100 To: mbone Subject: anycast made e.z. Date: Fri, 12 May 95 16:36:05 +0100 Message-Id: <2893.800292965@cs.ucl.ac.uk> From: Jon Crowcroft /* from a fast hack program by Harald.T.Alvestrand@uninett.no G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no http://domen.uninett.no/~hta/ +47 73 59 70 94 an even faster hack program by J.Crowcroft@cs.ucl.ac.uk http://www.cs.ucl.ac.uk/staff/jon/ ANYCAST made easy */ /* Multicast an UDP packet to a sequence of TTLs and return the name of the first ones to reply */ #include #include #include #include #include #include #include #include #include #include #include struct protoent *udp; struct servent *serv; int s; struct timeb starttime; static int sendpkt(char *hostaddr) { char *buffer = "well hello there, you warm and cuddly thing, you\n"; int err, count; struct sockaddr_in to; struct utsname name; to.sin_family = AF_INET; to.sin_port = htons(serv->s_port); to.sin_addr.s_addr = inet_addr(hostaddr); err = sendto(s, buffer, strlen(buffer), 0, &to, sizeof(to)); return err; } int get_response() { int err; char buffer[80]; struct sockaddr_in port, from; int fromlen; bzero(&from, sizeof(from)); fromlen = sizeof(from); err = recvfrom(s, buffer, sizeof(buffer), 0, &from, &fromlen); if (err == -1) { perror("recvfrom"); return 1; /* Die */ } else { struct timeb timebuff; int i; char ascbuf[80]; float diff; for (i=0;i < err; i++) { if (!isprint(buffer[i])) buffer[i] = '?'; } buffer[err] = 0; ftime(&timebuff); diff = timebuff.time + timebuff.millitm/1000.0 - starttime.time - starttime.millitm/1000.0; printf("%5.2f:%s\n", diff, buffer); printf("%s\n", inet_ntoa(from.sin_addr)); fflush(stdout); } } int main(int argc, char *argv[]) { unsigned char ttl, i; int stat; int pktsout = 0; struct timeval to; int sel; fd_set fds; if (argc < 3) { fprintf(stderr, "Usage: %s host...\n", argv[0]); exit(1); } ftime(&starttime); udp = getprotobyname("udp"); if (!udp) { perror("getprotobyname"); exit(1); } serv = getservbyname("echo", "udp"); if (!serv) { perror("getservbyname"); exit(1); } s = socket(PF_INET, SOCK_DGRAM, udp->p_proto); if (s == -1) { perror("socket"); exit(1); } for (ttl=1; ttl; Fri, 12 May 1995 12:52:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 12 May 1995 12:49:19 -0700 Received: from dfw.net by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 12 May 1995 12:49:17 -0700 Received: by dfw.net (4.1/SMI-4.1) id AA07974; Fri, 12 May 95 14:48:29 CDT Date: Fri, 12 May 1995 14:48:29 -0500 (CDT) From: Aleph One To: Bill Fenner Cc: mbone Subject: Re: vat + linux In-Reply-To: <95May10.171151pdt.49859@crevenia.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is there any document other than the sources code that describes the kernel part of mrouted? Or any doc that describe the kernel entry point for mrouted that way I can start reading from there... Reading the the thing without any idea of where the entrie points are is a mess. Its over 2200 lines alone for the kernel part. a1 On Wed, 10 May 1995, Bill Fenner wrote: > In message you write: > >BTW, since we are on this topicI always wondered why is part of > >DVMRP in ther kernel and part in mrouted? Why not simply have mrouted > >do all the DVMRP stuff just like routed does all RIP processing? > > Indeed, in the 3.x multicast releases, mrouted does all the DVMRP-related > stuff, and the kernel simply has a routing-protocol independent multicast > route cache. > > Bill > From list-mgr@ISI.EDU Sat May 13 17:44:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 13 May 1995 19:42:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 13 May 1995 19:42:00 -0700 Received: from bifrost.novalink.com by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 13 May 1995 19:41:59 -0700 Received: by bifrost.novalink.com id <2417-4>; Sat, 13 May 1995 22:33:07 -0700 From: jradoff@novalink.com (Jon Radoff) X-Mailer: NovaMail 3.63e To: mbone Subject: MBONE connectivity? Date: Sat, 13 May 95 22:44:50 EST Message-Id: Organization: NovaLink Interactive Networks (800-274-2814) We are very interested in participating in MBONE because we feel it ties into the Internet research and development we are doing at our company. Unfortunately, our Internet provider (NEARnet) is no longer offering MBONE connections. Could you help direct me to an alternative location that might be "close" on the net? We connect via a T1 and should be capable of handling the bandwidth. Sincerely, Jon Radoff jradoff@novalink.com From list-mgr@ISI.EDU Sun May 14 14:46:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 13 May 1995 21:47:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 13 May 1995 21:47:20 -0700 Received: from vx23.cc.monash.edu.au by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 13 May 1995 21:47:19 -0700 Received: from "port 1327"@basil.eng.monash.edu.au by vaxc.cc.monash.edu.au (PMDF V4.3-12 #8933) id <01HQHWICLL9S9VVRMN@vaxc.cc.monash.edu.au>; Sun, 14 May 1995 14:47:14 +1000 Received: from BASIL/SpoolDir by basil.eng.monash.edu.au (Mercury 1.20) ; 14 May 95 14:47:21 -1000 Received: from SpoolDir by BASIL (Mercury 1.20); 14 May 95 14:47:01 -1000 Date: Sun, 14 May 1995 14:46:52 GMT+1100 From: JOHN PSALLIDAS Subject: Win NV/SD/VAT query. To: mbone Message-Id: <7DC01F526D@basil.eng.monash.edu.au> X-Mailer: Pegasus Mail v3.22 Content-Transfer-Encoding: 7BIT Priority: normal Hello out there. I believe that some time ago there was mention of versions of NV, SD and VAT running under MS Windows (not quite sure what Windows version though ???). If they do exist, could someone, who has the info and time, respond with pointers to ftp sites ? Thanks in advance. :) --------------------------------------------------- John Psallidas Postgraduate student. Monash Uni., Melbourne, Australia. E-mail : yannis@basil.eng.monash.edu.au Phone : (03) 9055350 /-\_/-\ / \ \_/---\*_/ \/ From list-mgr@ISI.EDU Sun May 14 03:05:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 14 May 1995 10:06:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 14 May 1995 10:06:21 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 14 May 1995 10:06:20 -0700 Received: from grus.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA24448; Sun, 14 May 95 10:05:05 PDT Date: Sun, 14 May 1995 10:05:01 -0700 (PDT) From: Michael Macedonia Subject: Symposium on IP/ATM Multicasting for Distributed Interactive Simulation Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: SYMPOSIUM ON DYNAMIC IP/ATM MULTICASTING FOR DISTRIBUTED INTERACTIVE SIMULATION May 25, 1995 Naval Research Laboratory Washington, DC The U.S. Department of Defense continues to increase its emphasis on large-scale, distributed simulation. Recent policy (DOD Directive 5000.59) calls for the establishment of a master plan for unifying DoD modeling and simualtion efforts. Building on the evolving Distributed Interactive Simulation Standards (IEEE 1278), simulation networks incorporating up to 100,000 dynamic entities are being developed. Because of the scope of this effort, simulation networks are expected to be based on dynamic multicasting techniques utilizing a combination of robust Internet Protocol (IP) and high speed Asynchronous Transfer Mode (ATM) technologies. The multicasting requirements for these large-scale simulations are different from those of much of the network-layer software currently being developed. At least 10,000 multicast groups may be needed, and hundreds of multicast group changes per second may need to be propagated across the network. Group join and leave latencies on the order of one second may be required. This symposium provides an opportunity for the architects of the simulation networks to meet with IP and ATM network software developers to discuss these plans and requirements. Technical representatives from interested computer hardware and software organizations, developers of network switches and routers, and network software research organizations are urged to attend. The meeting will be unclassified; however, all attendees must provide the necessary information (full name, social security number, organization, and notation indicating U. S. citizen or Green Card) in advance so that badges will be ready upon arrival. *************************************************************** **** Deadline for registration: Monday, May 22, 1995 **** *************************************************************** For reservations, contact Ms. Anna Hanbury 202-767-2804 For technical information, contact Ray Cole 202-767-2901 Duncan Miller 617-981-7252 -- ====================== Steve Batsell nrl batsell@itd.nrl.navy.mil ======================= -- Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From list-mgr@ISI.EDU Wed May 10 08:15:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 14 May 1995 12:08:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 14 May 1995 12:08:14 -0700 Received: from gatekeeper.ltis.loral.com by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 14 May 1995 12:08:08 -0700 Received: (from uucp@localhost) by gatekeeper.ltis.loral.com (8.6.9/8.6.9) id PAA29677; Wed, 10 May 1995 15:14:06 -0700 Received: from loral.ltis.loral.com(158.185.41.22) by gatekeeper via smap (V1.3mjr) id sma029671; Wed May 10 15:13:06 1995 Received: from tigger.ltis.loral.com (tigger.ltis.loral.com [128.1.5.7]) by loral.ltis.loral.com (8.6.9/8.6.9) with ESMTP id PAA08597; Wed, 10 May 1995 15:12:47 -0700 Received: (from chris@localhost) by tigger.ltis.loral.com (8.6.9/8.6.9) id PAA00928; Wed, 10 May 1995 15:15:28 -0700 Date: Wed, 10 May 1995 15:15:28 -0700 (PDT) From: Chris Almond To: BIG-LAN@LISTSERV.SYR.EDU, mbone Subject: Replacing mrouted server w/switch Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: MBONE multicast packets, mrouted or switch? ---------------------------------------------------- Greetings: In the following message I am proposing the use of an ethernet 'layer 3 type' switch (with certain packet filtering rules) to perform the same task as that traditionally accomplished by a workstation running mrouted. Any comments on feasibility, applicability, desireability, and whatever else that comes to mind are welcome. # # # # # It seems to me that the current way most end nodes receive mbone multicast traffic is via a dedicated multi-homed host (eg. sun workstation) that is running mrouted. And this back door distribution method is due to the fact that a lot of routers in use today cannot run multicast protocols (DVMRP & MOSPF). I know of one network that distributes mbone traffic in a topology similar to this: +-----------+ | Multicast |<======== Multicast Tunnel======> | Router | | (Proteon) | +-----------+ | ------------------------------------------ DMZ Ethernet | | +----------+ +----------+ | Router | | mrouted | Multi-homed Sun +----------+ +----------+ | | | | | | (routed IP) | | | ( subnets ) +---+ | | | | | |---|HUB|----| | | | | +---+ | | | | | | | | +---+ | | | |-------|HUB|-------| | | +---+ | | | | +---+ | |-----------|HUB|----------| +---+ ||| \|||/ \ / End Nodes Observed drawbacks to using a dedicated workstation for running mrouted backdoor into end node LANs: - This path opens potential security holes. - Doing this consumes the resources of a dedicated workstation. - mrouted installation, new code release installation, kernel patches, etc. add to the net admin work load, especially for machines without kernel support already in place. - $$ for a decent multiple NIC mrouted server. - OS dependency ==> Why not use a ethernet switch in place ==> of a dedicated mrouted server? Some ethernet switch vendors are including layer 3 'router like' functionality in what is essentially a MAC layer multiport bridging device. Specifically, protocol filtering and broadcast packet filtering capabilities. So, it seems like with the right combination of filters, a switch could functionally replace the mrouted server. What would an ethernet switch need to do? At the very least, I think the following: (definitely open for comment...) 1) Be able to differentiate on the fly between unicast, multicast, and broadcast packet types. Implement a forward/ filter logic based on this info. 2) For those packets ID'd as multicast, determine if they are IP. 3) For multicast, _IP_only_ packets, function as a distribution hub forwarding all multicast IP received on an interface to the other interfaces, and filtering all other types of packets received at any of the interfaces. Is there some reasons for not doing this or roadblocks that I don't see. I have analyzed in more detail the impact of replacing the mrouted server in the diagram with a switch that has the capabilities described above. I'll share this off line with those who are curious. How interesting is this proposition? ...Chris Almond From list-mgr@ISI.EDU Mon May 15 11:20:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 02:29:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 02:27:08 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 02:27:06 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Mon, 15 May 1995 02:24:57 -0700 Message-Id: <199505150924.AA13062@quark.isi.edu> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 15 May 1995 10:20:24 +0100 To: rem-conf@es.net Cc: mbone, mbone-eu@sics.se, mice-nsc-admin@cs.ucl.ac.uk Subject: The Hamming multicast "Learning to Learn" Date: Mon, 15 May 95 10:20:21 +0100 From: Roy Bennett The MICE National Support Centre, England will re-multicast the course which is currently being multicast by the Naval Postgraduate School, Monterey, California. Retransmission will be of NTSC video recordings provided by the Naval Postgraduate School and will be at ttl 63 for Europe only. Later we intend to archive the course for "video-on-demand" access. The first session will be multicast at 09:00 UTC, next Tuesday, May 16. The remaining sessions will be transmitted on successive Thursdays and Tuesdays at the same time. It is hoped that this time will make for better quality reception in Europe. Details of the schedule and reference to the material provided by Tracey Emswiler and Don Brutzman of the Naval Postgraduate School may be found in http://www.cs.ucl.ac.uk/mice/seminars/ The schedule has been recorded in the MBone Session Global Agenda and currently has only one conflicting multicast. If anyone has a problem with the suggested schedule, please contact me and we will resolve it. An entry will be made in sd. Video will be transmitted using vic with the IVS option. Best wishes Roy ------------------------------------------------------------------------ Roy Bennett Email: rbennett@cs.ucl.ac.uk Computer Science University College London Phone: +44 171 380 7934 Gower Street, LONDON WC1E 6BT Fax: +44 171 387 1397 ------------------------------------------------------------------------ MICE Multimedia Integrated Conferencing Support Centre, England mice-nsc-england@cs.ucl.ac.uk http://www.cs.ucl.ac.uk/mice/mice-nsc/ ------------------------------------------------------------------------ From list-mgr@ISI.EDU Sun May 14 20:02:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 03:04:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 03:02:27 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 03:02:26 -0700 Received: by rx7.ee.lbl.gov (8.6.11/1.43r) id DAA09119; Mon, 15 May 1995 03:02:58 -0700 Message-Id: <199505151002.DAA09119@rx7.ee.lbl.gov> To: mbone Subject: Israel JENC trashing mbone with 500kb/s nv video Date: Mon, 15 May 95 03:02:58 PDT From: Van Jacobson The JENC6 conference has been sending 500kb/s of ttl 127 nv video for the past 3 hours. I tried to send the following to the JENC people in Tel Aviv to ask them to reduce their rate but mail on their machines is so mis-configured that they're impossible to reach. Perhaps someone who's attending the meeting or someone with a working email address for the people running the mbone feed could get them to lower their rate. Thanks. - Van ----------------------------- Host unix2.jenc6.ac.il (128.139.32.89) is sending ttl 127 video at 500kb/s to the JENC6 session (224.2.170.171/52190). This is an unreasonably high rate. The mbone usage guidelines say that video should be limited to at most 128kb/s at this ttl. Could you please reduce your rate? Thanks. - Van Jacobson ps- It would help if the JENC sd announcement contained an email address for who to contact in case of problems. From list-mgr@ISI.EDU Mon May 15 14:52:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 03:54:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 03:53:52 -0700 Received: from eagle.rvs.uni-hannover.de by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 03:53:42 -0700 Received: from oahu.rvs.uni-hannover.de by eagle.rvs.uni-hannover.de with smtp (Smail3.1.28.1 #6) id m0sAxlT-0000pwC; Mon, 15 May 95 12:52 DFT Received: by oahu.rvs.uni-hannover.de (Smail3.1.28.1 #8) id m0sAxlS-0003xEC; Mon, 15 May 95 12:52 MET DST Date: Mon, 15 May 1995 12:52:42 +0200 (MET DST) From: Michael Fromme X-Sender: fromme@oahu To: mbone Subject: IP Multicast for HP-UX 9.05 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I tried to set up multicast support on a HP 715 and failed. The only kernel patches (the libraries etc.) I found were for HP-UX 9.01 (hp-ipmulti.tar from John Lumley and Aled Edwards). These patches don't seem to work with 9.05, either by booting the distributed kernel nor by rebuilding it... Has anyone successfully added multicast support to HP-UX 9.05? Are there any new patches around on the net? Does/should HP-UX 10 incorporate IP multicast? Michael --- Michael Fromme Lehrgebiet Rechnernetze und Verteilte Systeme fromme@rvs.uni-hannover.de Universit"at Hannover, Germany Tel: +49 0511 / 762 3977 std/disclaimer: Die ge"au\3erten Meinungen sind meine eigenen! My opinions are my own. From list-mgr@ISI.EDU Tue May 16 09:42:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 06:43:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 06:43:20 -0700 Received: from vitruvius.arbld.unimelb.EDU.AU by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 06:43:15 -0700 Received: (darrenr@localhost) by vitruvius.arbld.unimelb.EDU.AU (8.6.12/8.6.4) id XAA10440 for mbone@isi.edu; Mon, 15 May 1995 23:42:58 +1000 From: Darren Reed Message-Id: <199505151342.XAA10440@vitruvius.arbld.unimelb.EDU.AU> Subject: Problems with 3.5... To: mbone Date: Mon, 15 May 1995 23:42:57 +1000 (EST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 673 I've just upgraded two kernels/mrouted to 3.5...or tried. The first problem was with 4.1.3_U1 on a SS2 - (using the .bpf stuff) ifconfig caused a kernel panic (bad data trap) when it started up - this is the SunOS ifconfig not quite sure what the problem was, but I rebuilt the kernel and now when it starts up I get a message about auto-revarp problems. currently, bpf isn't in and its working (ok ?)..I'll try some more. the other problem was with 4.1.4 on a SS5-85. Using the RSVP stuff, when it rebooted, I got: le1: TINT but owned by LANCE I copied over the 3.3 if_le.o for 4.1.3_U1, recompiled and the message has disappeased. any ideas ? cheers, darren From list-mgr@ISI.EDU Mon May 15 08:50:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 09:51:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 09:51:10 -0700 Received: from enfm.utcc.utoronto.ca by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 09:51:09 -0700 Received: from localhost by enfm.utcc.utoronto.ca with SMTP id <606888>; Mon, 15 May 1995 12:51:00 -0400 To: mbone Subject: MBONE and Proteon DVMRP Organization: UT Network & Operations Services, External Network Fac. Mgmt. Phone: +1 416 978 3328 Date: Mon, 15 May 1995 12:50:43 -0400 From: "Eric M. Carroll" Message-Id: <95May15.125100edt.606888@enfm.utcc.utoronto.ca> Folks, We have a proteon router here performing as an MBONE tunnel exploder for Canada. It appears to be in an infinite crash state. We do not understand why. The router is a DNX350 with 8 MB memory. Am I running out of memory? I seem to be unable to get a crash dump at this time. When the watchdog timer fires, it seems to not crash dump as I expect. Here is the configuration: Portable I80386 C Gateway mbone.on.canet.ca S/N 622 V15.1[P3] Boot ROM Version 2.0 Watchdog timer enabled Auto-boot switch enabled Console baud rate: 19200 Num Name Protocol 0 IP DOD-IP 3 ARP Address Resolution 9 DVM Distance Vector Multicast Routing Protocol 11 SNMP Simple Network Management Protocol 2 Networks: Net Interface MAC/Data-Link Hardware State 0 Eth/0 Ethernet/IEEE 802.3 Ethernet/802.3 Up 1 Eth/1 Ethernet/IEEE 802.3 Ethernet/802.3 Disabled IP>size Routing table size: 3000 Table entries used: 1205 Reassembly buffer size: 12000 Largest reassembled pkt: 0 Largest EGP update sent: 0 Size of routing cache: 64 # cache entries in use: 4 +mem Total Reserve Never Perm Temp Prev Alloc Alloc Alloc Alloc Heap memory 832668 26464 156420 305916 368372 1960 Buffer memory 524288 12288 12584 511640 Number of global buffers: Total = 232, Free = 232, Fair = 45, Low = 46 Global buff size: Data = 1500, Hdr = 58, Wrap = 62, Trail = 4, Total = 1624 Internet protocol user configuration IP config>lis all Interface addresses IP addresses for each interface: intf 0 192.68.54.104 255.255.255.0 Network broadcast, fill 1 intf 1 IP disabled on this interface Routing route to 0.0.0.0,0.0.0.0 via 192.68.54.1, cost 1 Protocols BOOTP forwarding: disabled Directed broadcasts: enabled ARP Subnet routing: disabled RFC925 routing: disabled OSPF: disabled Per-packet-multipath: disabled RIP: disabled EGP: disabled Open SPF-Based Routing Protocol configuration console OSPF Config>lis all --Global configuration-- OSPF Protocol: Disabled External comparison: Type 2 AS boundary capability: Disabled Multicast forwarding: Disabled --Area configuration-- Area ID AuType Stub? Default-cost Import-summaries? 0.0.0.0 0=None No N/A N/A Distance Vector Multicast Routing Protocol config console DVMRP Config>lis all DVMRP on tunnel 192.68.54.104 192.26.210.1 1 64 tunnel 192.68.54.104 131.202.15.2 1 64 tunnel 192.68.54.104 137.82.5.133 1 64 tunnel 192.68.54.104 35.42.1.150 1 64 phyint 192.68.54.104 1 1 DVMRP Config> Here is the t 2 console crash message: MSPF.014: Can't fwd 128.139.32.89 -> 224.2.170.171, rsn: Unreachable source MSPF.014: Can't fwd 204.62.246.73 -> 224.2.143.24, rsn: Unreachable source MSPF.014: Can't fwd 144.212.200.6 -> 224.2.0.1, rsn: Unreachable source MSPF.014: Can't fwd 204.62.246.76 -> 224.2.245.77, rsn: Unreachable source MSPF.014: Can't fwd 128.139.32.89 -> 224.2.170.171, rsn: Unreachable source MSPF.014: Can't fwd 204.62.246.75 -> 224.2.252.231, rsn: Unreachable source MSPF.014: Can't fwd 204.62.246.73 -> 224.2.143.24, rsn: Unreachable source MSPF.014: Can't fwd 198.35.12.50 -> 224.2.253.119, rsn: Unreachable source IP.051: rs ovfl, port 4 frm 35.42.1.150 IP.051: rs ovfl, port 4 frm 35.42.1.150 Panic: GW: leading buffer guard word corrupted panic+27; BPT rce MSPF.014: Can't fwd 128.139.32.89 -> 224.2.170.171, rsn: Unreachable source MSPF.014: Can't fwd 204.62.246.73 -> 224.2.143.24, rsn: Unreachable source MSPF.014: Can't fwd 144.212.200.6 -> 224.2.0.1, rsn: Unreachable source MSPF.014: Can't fwd 204.62.246.76 -> 224.2.245.77, rsn: Unreachable source MSPF.014: Can't fwd 128.139.32.89 -> 224.2.170.171, rsn: Unreachable source MSPF.014: Can't fwd 204.62.246.75 -> 224.2.252.231, rsn: Unreachable source MSPF.014: Can't fwd 204.62.246.73 -> 224.2.143.24, rsn: Unreachable source MSPF.014: Can't fwd 198.35.12.50 -> 224.2.253.119, rsn: Unreachable source IP.051: rs ovfl, port 4 frm 35.42.1.150 IP.051: rs ovfl, port 4 frm 35.42.1.150 Panic: GW: leading buffer guard word corrupted panic+27; BPT rce MSPF.014: Can't fwd 128.139.32.89 -> 224.2.170.171, rsn: Unreachable source MSPF.014: Can't fwd 204.62.246.73 -> 224.2.143.24, rsn: Unreachable source MSPF.014: Can't fwd 144.212.200.6 -> 224.2.0.1, rsn: Unreachable source MSPF.014: Can't fwd 204.62.246.76 -> 224.2.245.77, rsn: Unreachable source MSPF.014: Can't fwd 128.139.32.89 -> 224.2.170.171, rsn: Unreachable source MSPF.014: Can't fwd 204.62.246.75 -> 224.2.252.231, rsn: Unreachable source MSPF.014: Can't fwd 204.62.246.73 -> 224.2.143.24, rsn: Unreachable source MSPF.014: Can't fwd 198.35.12.50 -> 224.2.253.119, rsn: Unreachable source IP.051: rs ovfl, port 4 frm 35.42.1.150 IP.051: rs ovfl, port 4 frm 35.42.1.150 Panic: GW: leading buffer guard word corrupted panic+27; BPT ddtgetc+20; NMI - Watchdog Timer Fired Eric Carroll University of Toronto Network & Operations Services External Networking Facilities Management From list-mgr@ISI.EDU Mon May 15 03:17:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 10:19:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 10:17:47 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 10:17:46 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14513(1)>; Mon, 15 May 1995 10:17:26 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Mon, 15 May 1995 10:17:19 -0700 X-Mailer: exmh version 1.6 4/21/95 To: Chris Almond Cc: BIG-LAN@listserv.syr.edu, mbone, fenner@parc.xerox.com Subject: Re: Replacing mrouted server w/switch In-Reply-To: Your message of "Wed, 10 May 95 15:15:28 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 May 1995 10:17:13 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May15.101719pdt.49859@crevenia.parc.xerox.com> In message you w rite: >==> Why not use a ethernet switch in place >==> of a dedicated mrouted server? If an ethernet switch acting as a multicast forwarder does not run some kind of host group membership protocol (IGMP, for example), then it will have to forward all multicasts onto all networks. This may not be a problem for high-bandwidth environments. In addition, I suspect most networks would have some redundancy built in; in this case the switches would have to build loop-free data distribution trees. The "parallel multicast router" (i.e. sun running mrouted) is meant to disappear, as more router vendors are starting to support multicast. Bill From list-mgr@ISI.EDU Mon May 15 22:19:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 11:24:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 11:19:14 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 11:19:10 -0700 Received: from delos (eckert@faui45r.informatik.uni-erlangen.de [131.188.34.54]) by immd4.informatik.uni-erlangen.de with SMTP id UAA01597 (8.6.12/7.4b-FAU);; Mon, 15 May 1995 20:19:03 +0200 From: Toerless Eckert Message-Id: <199505151819.UAA01597@faui40.informatik.uni-erlangen.de> Subject: Re: Replacing mrouted server w/switch To: fenner@parc.xerox.com (Bill Fenner) Date: Mon, 15 May 1995 20:19:00 +0200 (MET DST) Cc: chris@ltis.loral.com, BIG-LAN@listserv.syr.edu, mbone, fenner@parc.xerox.com In-Reply-To: <95May15.101719pdt.49859@crevenia.parc.xerox.com> from "Bill Fenner" at May 15, 95 10:17:13 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > If an ethernet switch acting as a multicast forwarder does not run some kind > of host group membership protocol (IGMP, for example), then it will have to > forward all multicasts onto all networks. This may not be a problem for > high-bandwidth environments. In addition, I suspect most networks would have > some redundancy built in; in this case the switches would have to build > loop-free data distribution trees. Cisco switches are supposed to support IGMP but i think you still need a loop free setup because i havn't seen any reference to a multicast routing protocol on them. Guess they're good for connecting leaf networks to a single backbone segment. From list-mgr@ISI.EDU Mon May 15 04:38:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 11:40:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 11:39:03 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 11:39:00 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14567(5)>; Mon, 15 May 1995 11:38:47 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Mon, 15 May 1995 11:38:29 -0700 X-Mailer: exmh version 1.6 4/21/95 To: Toerless Eckert Cc: fenner@parc.xerox.com (Bill Fenner), chris@ltis.loral.com, BIG-LAN@listserv.syr.edu, mbone Subject: Re: Replacing mrouted server w/switch In-Reply-To: Your message of "Mon, 15 May 95 11:19:00 PDT." <199505151819.UAA01597@faui40.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 May 1995 11:38:07 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May15.113829pdt.49859@crevenia.parc.xerox.com> In message <199505151819.UAA01597@faui40.informatik.uni-erlangen.de> you write: >Cisco switches are supposed to support IGMP but i think you still need >a loop free setup because i havn't seen any reference to a multicast >routing protocol on them. I know of a Cisco switch that does IGMP "snooping", i.e. if it hears an IGMP report then it will forward traffic on that interface. I don't know if it filters reports to prevent suppression (I assume it does), but that means that a router behind it will not hear any reports. >Guess they're good for connecting leaf networks >to a single backbone segment. Seems that way. Bill From list-mgr@ISI.EDU Mon May 15 10:47:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 11:49:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 11:47:18 -0700 Received: from home.merit.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 11:47:17 -0700 Received: from localhost (ljb@localhost) by home.merit.edu (8.6.12/merit-2.0) with SMTP id OAA05555; Mon, 15 May 1995 14:47:15 -0400 Message-Id: <199505151847.OAA05555@home.merit.edu> To: "Eric M. Carroll" Cc: mbone Subject: Re: MBONE and Proteon DVMRP In-Reply-To: Your message of "Mon, 15 May 1995 12:50:43 EDT." <95May15.125100edt.606888@enfm.utcc.utoronto.ca> Date: Mon, 15 May 1995 14:47:14 -0400 From: "Larry J. Blunk" Hmm, we just upgraded our mrouter (mbone/homeric.merit.edu) to ipmulti-3.5. Perhaps this is causing problems on the Proteon? -Larry Blunk Merit > Folks, > > We have a proteon router here performing as an MBONE tunnel exploder > for Canada. It appears to be in an infinite crash state. We do not > understand why. The router is a DNX350 with 8 MB memory. Am I running > out of memory? I seem to be unable to get a crash dump at this time. > When the watchdog timer fires, it seems to not crash dump as I expect. > > Here is the configuration: > > Portable I80386 C Gateway mbone.on.canet.ca S/N 622 > V15.1[P3] > Boot ROM Version 2.0 > Watchdog timer enabled > Auto-boot switch enabled > Console baud rate: 19200 > > Num Name Protocol > 0 IP DOD-IP > 3 ARP Address Resolution > 9 DVM Distance Vector Multicast Routing Protocol > 11 SNMP Simple Network Management Protocol > > 2 Networks: > Net Interface MAC/Data-Link Hardware State > 0 Eth/0 Ethernet/IEEE 802.3 Ethernet/802.3 Up > 1 Eth/1 Ethernet/IEEE 802.3 Ethernet/802.3 Disabled > > > IP>size > > Routing table size: 3000 > Table entries used: 1205 > Reassembly buffer size: 12000 > Largest reassembled pkt: 0 > Largest EGP update sent: 0 > Size of routing cache: 64 > # cache entries in use: 4 > > > +mem > Total Reserve Never Perm Temp Prev > Alloc Alloc Alloc Alloc > Heap memory 832668 26464 156420 305916 368372 1960 > Buffer memory 524288 12288 12584 511640 > > Number of global buffers: Total = 232, Free = 232, Fair = 45, Low = 46 > Global buff size: Data = 1500, Hdr = 58, Wrap = 62, Trail = 4, Total = 1624 > > Internet protocol user configuration > IP config>lis all > Interface addresses > IP addresses for each interface: > intf 0 192.68.54.104 255.255.255.0 Network broadcast, fill 1 > > intf 1 IP disabled on this interface > > Routing > > route to 0.0.0.0,0.0.0.0 via 192.68.54.1, cost 1 > > Protocols > BOOTP forwarding: disabled > Directed broadcasts: enabled > ARP Subnet routing: disabled > RFC925 routing: disabled > OSPF: disabled > Per-packet-multipath: disabled > RIP: disabled > EGP: disabled > > Open SPF-Based Routing Protocol configuration console > OSPF Config>lis all > > --Global configuration-- > OSPF Protocol: Disabled > External comparison: Type 2 > AS boundary capability: Disabled > Multicast forwarding: Disabled > > --Area configuration-- > Area ID AuType Stub? Default-cost Import-summaries? > 0.0.0.0 0=None No N/A N/A > > Distance Vector Multicast Routing Protocol config console > DVMRP Config>lis all > > DVMRP on > tunnel 192.68.54.104 192.26.210.1 1 64 > tunnel 192.68.54.104 131.202.15.2 1 64 > tunnel 192.68.54.104 137.82.5.133 1 64 > tunnel 192.68.54.104 35.42.1.150 1 64 > phyint 192.68.54.104 1 1 > DVMRP Config> > > Here is the t 2 console crash message: > > MSPF.014: Can't fwd 128.139.32.89 -> 224.2.170.171, rsn: Unreachable source > MSPF.014: Can't fwd 204.62.246.73 -> 224.2.143.24, rsn: Unreachable source > MSPF.014: Can't fwd 144.212.200.6 -> 224.2.0.1, rsn: Unreachable source > MSPF.014: Can't fwd 204.62.246.76 -> 224.2.245.77, rsn: Unreachable source > MSPF.014: Can't fwd 128.139.32.89 -> 224.2.170.171, rsn: Unreachable source > MSPF.014: Can't fwd 204.62.246.75 -> 224.2.252.231, rsn: Unreachable source > MSPF.014: Can't fwd 204.62.246.73 -> 224.2.143.24, rsn: Unreachable source > MSPF.014: Can't fwd 198.35.12.50 -> 224.2.253.119, rsn: Unreachable source > IP.051: rs ovfl, port 4 frm 35.42.1.150 > IP.051: rs ovfl, port 4 frm 35.42.1.150 > > Panic: GW: leading buffer guard word corrupted > > panic+27; BPT rce > MSPF.014: Can't fwd 128.139.32.89 -> 224.2.170.171, rsn: Unreachable source > MSPF.014: Can't fwd 204.62.246.73 -> 224.2.143.24, rsn: Unreachable source > MSPF.014: Can't fwd 144.212.200.6 -> 224.2.0.1, rsn: Unreachable source > MSPF.014: Can't fwd 204.62.246.76 -> 224.2.245.77, rsn: Unreachable source > MSPF.014: Can't fwd 128.139.32.89 -> 224.2.170.171, rsn: Unreachable source > MSPF.014: Can't fwd 204.62.246.75 -> 224.2.252.231, rsn: Unreachable source > MSPF.014: Can't fwd 204.62.246.73 -> 224.2.143.24, rsn: Unreachable source > MSPF.014: Can't fwd 198.35.12.50 -> 224.2.253.119, rsn: Unreachable source > IP.051: rs ovfl, port 4 frm 35.42.1.150 > IP.051: rs ovfl, port 4 frm 35.42.1.150 > > Panic: GW: leading buffer guard word corrupted > > panic+27; BPT rce > MSPF.014: Can't fwd 128.139.32.89 -> 224.2.170.171, rsn: Unreachable source > MSPF.014: Can't fwd 204.62.246.73 -> 224.2.143.24, rsn: Unreachable source > MSPF.014: Can't fwd 144.212.200.6 -> 224.2.0.1, rsn: Unreachable source > MSPF.014: Can't fwd 204.62.246.76 -> 224.2.245.77, rsn: Unreachable source > MSPF.014: Can't fwd 128.139.32.89 -> 224.2.170.171, rsn: Unreachable source > MSPF.014: Can't fwd 204.62.246.75 -> 224.2.252.231, rsn: Unreachable source > MSPF.014: Can't fwd 204.62.246.73 -> 224.2.143.24, rsn: Unreachable source > MSPF.014: Can't fwd 198.35.12.50 -> 224.2.253.119, rsn: Unreachable source > IP.051: rs ovfl, port 4 frm 35.42.1.150 > IP.051: rs ovfl, port 4 frm 35.42.1.150 > > Panic: GW: leading buffer guard word corrupted > > panic+27; BPT > ddtgetc+20; NMI - Watchdog Timer Fired > > Eric Carroll University of Toronto Network & Operations Services > External Networking Facilities Management From list-mgr@ISI.EDU Mon May 15 05:08:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 12:09:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 12:08:57 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 12:08:56 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id MAA12889; Mon, 15 May 1995 12:08:55 -0700 Date: Mon, 15 May 1995 12:08:55 -0700 From: Dino Farinacci Message-Id: <199505151908.MAA12889@stilton.cisco.com> To: fenner@parc.xerox.com Cc: Toerless.Eckert@informatik.uni-erlangen.de, fenner@parc.xerox.com, chris@ltis.loral.com, BIG-LAN@listserv.syr.edu, mbone In-Reply-To: Bill Fenner's message of Mon, 15 May 1995 11:38:07 PDT <95May15.113829pdt.49859@crevenia.parc.xerox.com> Subject: Replacing mrouted server w/switch >> I know of a Cisco switch that does IGMP "snooping", i.e. if it hears an IGMP >> report then it will forward traffic on that interface. I don't know if it >> filters reports to prevent suppression (I assume it does), but that means that >> a router behind it will not hear any reports. It does not filter Reports. It forwards them so routers can get them as well as other hosts so they can do suppression. Dino From list-mgr@ISI.EDU Mon May 15 11:31:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 12:32:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 12:31:53 -0700 Received: from enfm.utcc.utoronto.ca by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 12:31:53 -0700 Received: from localhost by enfm.utcc.utoronto.ca with SMTP id <606852>; Mon, 15 May 1995 15:31:48 -0400 To: mbone Subject: serious embarrassment In-Reply-To: ljb's message of "Mon, 15 May 1995 14:47:14 -0400". <199505151847.OAA05555@home.merit.edu> Date: Mon, 15 May 1995 15:31:23 -0400 From: "Eric M. Carroll" Message-Id: <95May15.153148edt.606852@enfm.utcc.utoronto.ca> I apologize about the mail regarding the Proteon sent to this list. I intended it to go to Proteon customer support, not this list (I guess I sent the mail for this list to Proteon!). Too many interrupts... Now, if anyone has any experience with Proteon's DVMRP code, and has seen this problem, a note to me would be appreciated... Eric Carroll University of Toronto Network & Operations Services External Networking Facilities Management From list-mgr@ISI.EDU Mon May 15 09:58:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 13:00:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 13:00:23 -0700 Received: from fnal.fnal.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 13:00:22 -0700 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HQJB8OENKW00L5M1@FNAL.FNAL.GOV>; Mon, 15 May 1995 15:00:07 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA10051; Mon, 15 May 95 14:58:39 CDT Date: Mon, 15 May 1995 14:58:39 -0500 From: Matt Crawford Subject: Re: Replacing mrouted server w/switch In-Reply-To: Your message of Mon, 15 May 95 11:38:07 PDT. <95May15.113829pdt.49859@crevenia.parc.xerox.com> Sender: crawdad@munin.fnal.gov To: Bill Fenner Cc: Toerless Eckert , chris@ltis.loral.com, mbone Message-Id: <9505151958.AA10051@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > I know of a Cisco switch that does IGMP "snooping", i.e. if it hears an IGMP > report then it will forward traffic on that interface. I don't know if it > filters reports to prevent suppression (I assume it does), but that means > that a router behind it will not hear any reports. We're using this now, and the way it works seems to be this: Any switch port that sees an IGMP membership query is marked as a "router port" and the query is flooded. Membership reports are snooped and forwarded only to router ports. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From list-mgr@ISI.EDU Mon May 15 06:01:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 13:01:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 13:01:32 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 15 May 1995 13:01:31 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14462(4)>; Mon, 15 May 1995 13:01:23 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Mon, 15 May 1995 13:01:11 -0700 X-Mailer: exmh version 1.6 4/21/95 To: Dino Farinacci Cc: fenner@parc.xerox.com, Toerless.Eckert@informatik.uni-erlangen.de, chris@ltis.loral.com, BIG-LAN@listserv.syr.edu, mbone Subject: Re: Replacing mrouted server w/switch In-Reply-To: Your message of "Mon, 15 May 95 12:08:55 PDT." <199505151908.MAA12889@stilton.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 May 1995 13:01:10 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May15.130111pdt.49859@crevenia.parc.xerox.com> In message <199505151908.MAA12889@stilton.cisco.com> you write: > [The IGMP-snooping switch] does not filter Reports. > It forwards them so routers can get them > as well as other hosts so they can do suppression. I don't understand how IGMP snooping can work in the face of suppression. I was under the impression that you wouldn't forward multicast traffic down a port unless you had heard a report for that group on that port. If a host's report gets suppressed, then how does the switch know that it is a member? Bill From list-mgr@ISI.EDU Tue May 16 07:45:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 16 May 1995 08:54:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 16 May 1995 08:52:27 -0700 Received: from Princeton.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 16 May 1995 08:52:26 -0700 Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.116/princeton) id AA09870; Tue, 16 May 95 11:45:45 -0400 Received: from deepthought.Princeton.EDU by ponyexpress.princeton.edu (8.6.12/1.7/newPE) id LAA22399; Tue, 16 May 1995 11:45:43 -0400 Received: by deepthought.Princeton.EDU (4.1/Phoenix_Cluster_Client) id AA13187; Tue, 16 May 95 11:45:41 EDT Message-Id: <9505161545.AA13187@deepthought.Princeton.EDU> X-Mailer: exmh version 1.6delta 4/7/95 To: Arlie Davis Cc: Yu Uny Cao , mbone, tengi@Princeton.EDU Subject: Microsoft 32 bit IP stack (was Re: WinNV/Vat/SD and TrumpetTCP) In-Reply-To: Your message of "Mon, 01 May 1995 09:27:05 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 May 1995 11:45:40 EDT From: "Christopher J. Tengi" I checked the Microsoft FTP site and found the following: ftp://ftp.microsoft.com/SoftLib/MSLFILES/WFWT32.EXE This is what I found in ftp://ftp.microsoft.com/SoftLib/INDEX.TXT when I searched for TCP: 11/30/94 S14856 WFWT32.EXE TCP/IP-32 v. 3.11a for Windows for Workgroups 5/2/94 S14749 WFWTCP.EXE MS TCP/IP Protocol for WFWG 3.11 I hope this helps.... /Chris > It means that your TCP/IP stack does not support the multicast > extensions. I had, but lost, the mcast extensions for the Microsoft > 32-bit stack (any pointers, anyone?). I'm told that mcast works > correctly with Microsoft's stack + extensions, and that FTP Software's > mcast kernel works, also. > From list-mgr@ISI.EDU Tue May 16 03:22:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 16 May 1995 10:08:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 16 May 1995 10:08:34 -0700 Received: from haven.uniserve.com by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 16 May 1995 10:08:32 -0700 Received: from pm4-26.tvs.net ([198.53.215.148]) by haven.uniserve.com with SMTP id <151>; Tue, 16 May 1995 10:22:57 -0700 X-Sender: dallas@haven.uniserve.com X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: dallas@haven.uniserve.com (Dallas Dukel) Subject: help Message-Id: <95May16.102257-0700_pdt.151+2132@haven.uniserve.com> Date: Tue, 16 May 1995 10:22:44 -0700 Could someone please tell me the address to unsubscribe to this list, I have seemed to missplaced it somewhere. Thankyou From list-mgr@ISI.EDU Wed May 17 14:15:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 17 May 1995 03:27:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 17 May 1995 03:22:35 -0700 Received: from sanson.dit.upm.es (sanson-gw.dit.upm.es) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 17 May 1995 03:22:16 -0700 Received: from greco.dit.upm.es (greco-gw.dit.upm.es [138.4.2.4]) by sanson.dit.upm.es (8.6.10/2.25) with ESMTP id MAA12130; Wed, 17 May 1995 12:15:44 +0200 Received: (david@localhost) by greco.dit.upm.es (8.6.10/2.25) id MAA00883; Wed, 17 May 1995 12:15:43 +0200 Date: Wed, 17 May 1995 12:15:43 +0200 From: David Fernandez Cambronero Message-Id: <199505171015.MAA00883@greco.dit.upm.es> To: arlie@thepoint.net, tengi@Princeton.EDU Subject: Re: Microsoft 32 bit IP stack (was Re: WinNV/Vat/SD and TrumpetTCP) Cc: mbone, yu@Flamingo.CS.UCLA.EDU You can find the necessary information to use mcast extensions with MS-TCP/IP-32 on: ftp://ftp.microsoft.com/bussys/winsock/ms-ext As far as I know there is two known problems with this mcast extensions: - It does not send periodic IGMP packets to maintain the subscription to a multicast group. So, routers time out and give up sending mcast datagrams to clients. This problem has been solved in a recent new beta version (you can find it on ftp://ftp.microsoft.com/bussys/Clients/WFW/WOLVBETA.EXE) - When you send a mcast datagram to a mcast group you are bound to, you *always* receive a copy of it. As far as I know, there's no way to avoid it. Other multicast implementations let you configure this point by means of a socket option or a general configuration parameter (for example PC/TCP has a configuration parameter in PCTCP.INI). This option should be included, as stated in RFC1112: 6. SENDING MULTICAST IP DATAGRAMS 6.1. Extensions to the IP Service Interface ...... Third (level 2 implementations only), for the case in which the host is itself a member of a group to which a datagram is being sent, the service interface should provide a way for the upper-layer protocol to inhibit local delivery of the datagram; by default, a copy of the datagram is looped back. This is a performance optimization for upper-layer protocols that restrict the membership of a group to one process per host (such as a routing protocol), or that handle loopback of group communication at a higher layer (such as a multicast transport protocol). Hope this helps, ------------------------------------------------------------------ David Fernandez tel: +34 1 5495700, +34 1 5495762 Associate Professor x.469 Dpto. Ing. Telematica E.T.S.I. Telecomunicacion e-mail: david@dit.upm.es Ciudad Universitaria fax: +34 1 5432077 E-28040 MADRID tlx: 47430 ETSIT E SPAIN ------------------------------------------------------------------ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 May 1995 11:45:40 EDT From: "Christopher J. Tengi" Status: RO I checked the Microsoft FTP site and found the following: ftp://ftp.microsoft.com/SoftLib/MSLFILES/WFWT32.EXE This is what I found in ftp://ftp.microsoft.com/SoftLib/INDEX.TXT when I searched for TCP: 11/30/94 S14856 WFWT32.EXE TCP/IP-32 v. 3.11a for Windows for Workgroups 5/2/94 S14749 WFWTCP.EXE MS TCP/IP Protocol for WFWG 3.11 I hope this helps.... /Chris > It means that your TCP/IP stack does not support the multicast > extensions. I had, but lost, the mcast extensions for the Microsoft > 32-bit stack (any pointers, anyone?). I'm told that mcast works > correctly with Microsoft's stack + extensions, and that FTP Software's > mcast kernel works, also. > From list-mgr@ISI.EDU Wed May 17 15:20:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 17 May 1995 22:21:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 17 May 1995 22:20:47 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 17 May 1995 22:20:47 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA19220; Wed, 17 May 95 22:20:40 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9505180520.AA19220@taurus.cs.nps.navy.mil> Subject: Re: Interesting MBone problem diagnosis To: CASNER (Stephen Casner) Date: Wed, 17 May 1995 22:20:40 -0700 (PDT) Cc: mbone (Multicast Backbone mail list) In-Reply-To: <799823010.0.CASNER@XFR.ISI.EDU> from "Stephen Casner" at May 6, 95 10:03:30 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 459 I finally located the etherview distribution for SGIs. No other site known. Caveat emptor. The etherview distribution is listed in the SGI Free Sources FAQ and is at ftp://132.198.1.7/pub/iris/util regards, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv.html From list-mgr@ISI.EDU Thu May 18 06:51:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 07:57:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 07:52:14 -0700 Received: from mailer.jhuapl.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 07:52:13 -0700 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA09482; Thu, 18 May 1995 10:52:06 -0400 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA26278; Thu, 18 May 1995 10:51:13 -0400 Date: Thu, 18 May 1995 10:51:13 -0400 (EDT) From: Jim Bogard BIX Subject: sd entry propogation and more... To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1353 Hi- Does anyone happen to know if mrouted for Solaris handles the default route stuff (etc) implemented in mrouted 3.5 for SunOs 4.1.x? It appears to work ok, but I'd like some conformation. Also, what is the current version of mrouted for Solaris? I'm getting confused with all this about 3.4 and 3.5 and 4.1.x running here and not there... Is it still 2.2? And where's the best place to get it? My minor (odd) problem, and why I ask the above: 4.1.x box used as facility mrouter (3.5), works fine. 2 Solaris boxes running mrouted as end nodes. If I make an sd entryon one, it pops up on the other quickly, no problem. (yes, different IP subnets). So it's propogating throught the main mrouter ok. Problem is that when I delete it, the other doesn't. Also, it will let me delete sessions I don't own! I don't think its propogated, because they reappear in a bit, but still confusing. Minor other side problem: mrouted 3.5 doesn't seem to want to work in tunnel only mode. I was using that in 3.4, but I had to rem out the phyint disable line I was using to get 3.5 to stay running. (Yes, #tunnels > 1). Anybody else seen any of these behaviors? Thanks. J-. ---- Jim Bogard JHU/APL BIX Group "This is my banjo. There are many Backbone Network Engineer like it, but this one is mine." From list-mgr@ISI.EDU Thu May 18 20:55:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 08:12:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 08:12:16 -0700 Received: from sun1.iihe.ac.be by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 08:12:06 -0700 X400-Received: by mta sun1.iihe.ac.be in /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Thu, 18 May 1995 17:02:19 +0200 X400-Received: by mta elem5 in /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Thu, 18 May 1995 18:55:42 +0200 X400-Received: by /PRMD=iihe/ADMD=rtt/C=be/; Relayed; Thu, 18 May 1995 18:55:42 +0200 Date: Thu, 18 May 1995 18:55:42 +0200 X400-Originator: colin@helios.iihe.rtt.be X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=iihe/ADMD=rtt/C=be/;950518165542] X400-Content-Type: P2-1984 (2) Content-Identifier: 11050010 From: Michel Colin Message-Id: <11050010*/G=michel/S=colin/O=helios/PRMD=iihe/ADMD=rtt/C=be/@MHS> To: mbone (Non Receipt Notification Requested) Subject: vic 2.6 for HP I'm looking for a binary version of vic 2.6 compiled for HP 7xx systems Thanks in advance From list-mgr@ISI.EDU Thu May 18 17:34:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 08:39:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 08:37:44 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 08:37:43 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 18 May 1995 08:37:40 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 18 May 1995 16:35:01 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Jim Bogard BIX Cc: mbone Subject: Re: sd entry propogation and more... In-Reply-To: Your message of "Thu, 18 May 95 10:51:13 EDT." Date: Thu, 18 May 95 16:34:54 +0100 Message-Id: <10947.800811294@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >My minor (odd) problem, and why I ask the above: >4.1.x box used as facility mrouter (3.5), works fine. 2 Solaris boxes >running mrouted as end nodes. If I make an sd entryon one, it pops up on >the other quickly, no problem. (yes, different IP subnets). So it's >propogating throught the main mrouter ok. Problem is that when I delete >it, the other doesn't. Also, it will let me delete sessions I don't >own! I don't think its propogated, because they reappear in a bit, but >still confusing. sd deletion doesn't do what you think it does! If you started the session on the same machine, then deleting it stops the session being announced, removes it from you .sd_cache file and removes it from your display. It gets removed from everyone else's display when it times out. Deleting any other session merely removes it from your display. I've been looking at ways to make deletion more active in the next generation sd protocol, but no definite decisions so far (the interaction with proxies and preventing spoof deletions is what can make it complicated). Mark From list-mgr@ISI.EDU Thu May 18 03:11:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 10:15:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 10:14:46 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 10:14:46 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14546(5)>; Thu, 18 May 1995 10:11:17 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Thu, 18 May 1995 10:11:12 -0700 X-Mailer: exmh version 1.6 4/21/95 To: Jim Bogard BIX Cc: mbone Subject: Re: sd entry propogation and more... In-Reply-To: Your message of "Thu, 18 May 95 07:51:13 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 May 1995 10:11:01 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May18.101112pdt.49859@crevenia.parc.xerox.com> In message you write: >Does anyone happen to know if mrouted for Solaris handles the default >route stuff (etc) implemented in mrouted 3.5 for SunOs 4.1.x? Not yet. Sun is working on 3.5 for Solaris 2.4. Currently, you still need to run a 2.2 mrouted over Soalris 2.x . Bill From list-mgr@ISI.EDU Thu May 18 13:28:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 14:29:03 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 14:28:49 -0700 Received: from decvax.dec.com (decvax.zk3.dec.com) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 14:28:27 -0700 Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA02231; Thu, 18 May 1995 17:28:23 -0400 Received: from localhost by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA11542; Thu, 18 May 1995 17:28:18 -0400 Message-Id: <9505182128.AA11542@alpha.zk3.dec.com> To: Bill Fenner Cc: mbone Subject: Re: Announcing the 3.5 release of SunOS kernel mods In-Reply-To: Your message of "Mon, 08 May 95 22:21:08 PDT." <95May8.222116pdt.49859@crevenia.parc.xerox.com> Date: Thu, 18 May 95 17:28:17 -0400 From: ajay@zk3.dec.com X-Mts: smtp in the 3.5 diffs, ip_output.c.diff: shouldn't the following: (#else need see below lines prepanded w/ ">>") ---------------------- + /* + * Confirm that the outgoing interface supports multicast. + */ + #ifdef RSVP_ISI + if ((imo == NULL) || (imo->imo_multicast_vif == -1)) + #endif /* RSVP_ISI */ + if ((ifp->if_flags & IFF_MULTICAST) == 0) { + error = ENETUNREACH; + goto bad; + } ------------------- be (see #else added): ---------- + /* + * Confirm that the outgoing interface supports multicast. + */ + #ifdef RSVP_ISI + if ((imo == NULL) || (imo->imo_multicast_vif == -1)) >>#else + if ((ifp->if_flags & IFF_MULTICAST) == 0) { >>#endif /* RSVP_ISI */ + error = ENETUNREACH; + goto bad; + } ----------- Not that i'm ready for RSVP stuff yet, but when and if you enable RSVP_ISI -- this could be a problem. --Ajay Kachrani From list-mgr@ISI.EDU Thu May 18 08:18:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 15:18:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 15:18:37 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 15:18:37 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14554(3)>; Thu, 18 May 1995 15:18:26 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Thu, 18 May 1995 15:18:19 -0700 X-Mailer: exmh version 1.6 4/21/95 To: mbone Subject: Re: Announcing the 3.5 release of SunOS kernel mods In-Reply-To: Your message of "Thu, 18 May 95 14:28:17 PDT." <9505182128.AA11542@alpha.zk3.dec.com> Date: Thu, 18 May 1995 15:18:12 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May18.151819pdt.49859@crevenia.parc.xerox.com> In message <9505182128.AA11542@alpha.zk3.dec.com> ajay@zk3.dec.com writes: >be (see #else added): >---------- >+ /* >+ * Confirm that the outgoing interface supports multicast. >+ */ >+ #ifdef RSVP_ISI >+ if ((imo == NULL) || (imo->imo_multicast_vif == -1)) >>>#else >+ if ((ifp->if_flags & IFF_MULTICAST) == 0) { >>>#endif /* RSVP_ISI */ >+ error = ENETUNREACH; >+ goto bad; >+ } >----------- No, the original code is right. Although it should actually be more like if ((ifp->if_flags & IFF_MULTICAST) == 0) #ifdef RSVP_ISI if ((imo == NULL) || (imo->imo_multicast_vif == -1)) #endif { error = ENETUNREACH; goto bad; } to take the wasteful tests out of the normal case. Basically, imo_multicast_vif means "send on this interface no matter what", meaning that the check to see if the interface supports multicast should be bypassed. Bill From list-mgr@ISI.EDU Thu May 18 16:00:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 23:00:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 23:00:19 -0700 Received: from ell.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 18 May 1995 23:00:19 -0700 Received: by ell.ee.lbl.gov (8.6.12/1.43r) id XAA24773; Thu, 18 May 1995 23:00:05 -0700 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199505190600.XAA24773@ell.ee.lbl.gov> To: mbone, bsdi-users@bsdi.com Subject: ip multicast v3.5 for bsd/os 2.0 Date: Thu, 18 May 95 23:00:05 PDT Patches for the 3.5 multicast distribution from Xerox PARC are now available for BSD/OS 2.0 in ftp://ftp.ee.lbl.gov/ipmulti-3.5-bsdos2.0.tar.gz. This tar contains the kernel source patches necessary to run the latest version of mrouted (v3.5) from PARC (mrouted itself does not require patches for BSD/OS). Note that these changes affect only multicast routing functionality, not end-system functionality, so don't worry about upgrading unless you use your BSD/OS machine as a multicast router. Steve From list-mgr@ISI.EDU Fri May 19 12:04:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 19 May 1995 05:07:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 19 May 1995 05:05:31 -0700 Received: from fenris.hiof.no by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 19 May 1995 05:05:21 -0700 Received: from abdallah.hiof.no by fenris.hiof.no with SMTP (PP) id <01374-0@fenris.hiof.no>; Fri, 19 May 1995 14:05:03 +0200 Received: by abdallah.hiof.no (940816.SGI.8.6.9/940406.SGI.AUTO) id MAA11614; Fri, 19 May 1995 12:04:10 GMT Date: Fri, 19 May 1995 12:04:07 +0000 From: Borre Ludvigsen X-Sender: borrel@abdallah To: mbone Subject: SunVideo & SUN OS 4.1.4 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Anyone have the SunVideo Camera running under 4.1.4 on a SPARC Classic? - Barre ---------------------------------------------------------------------- Barre Ludvigsen - Ostfold Regional College- N-1750 HALDEN - Norway ---------------------------------------------------------------------- vox:+4769185400/home+4769341922/direct+4769185577ext219fax:+4769185485 ---------------------------------------------------------------------- Come and visit! ---------------------------------------------------------------------- CU-SeeMe on 158.36.33.3 or 158.36.49.13 From list-mgr@ISI.EDU Fri May 19 16:54:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 19 May 1995 07:59:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 19 May 1995 07:58:45 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 19 May 1995 07:54:55 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id PAA22231; Fri, 19 May 1995 15:54:39 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id PAA10996; Fri, 19 May 1995 15:54:34 +0100 Date: Fri, 19 May 1995 15:54:33 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Borre Ludvigsen Cc: mbone Subject: Re: SunVideo & SUN OS 4.1.4 In-Reply-To: Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 19 May 1995, Borre Ludvigsen wrote: > Anyone have the SunVideo Camera running under 4.1.4 on a SPARC Classic? SunVideo is only supported under Solaris 2.[34] ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Fri May 19 20:45:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 19 May 1995 09:46:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 19 May 1995 09:46:02 -0700 Received: from jerry.inria.fr by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 19 May 1995 09:45:57 -0700 Received: by jerry.inria.fr (8.6.12/8.6.12) id SAA06918; Fri, 19 May 1995 18:45:47 +0200 Message-Id: <199505191645.SAA06918@jerry.inria.fr> To: rem-conf@es.net, mbone Subject: ivs v3.5 available for anonymous ftp Date: Fri, 19 May 1995 18:45:46 +0200 From: Thierry Turletti A new version of the INRIA Videoconferencing System is available by anonymous ftp from zenon.inria.fr:rodeo/ivs/last_version. Attached is the list of changes, you can also consult the ivs home page which contains updated information of ivs: Thierry Turletti List of changes: ---------------- IVS version 3.5 (95/5/19) * This version is compatible with version 3.4. It still uses the RTPv1 version and the old version of the ``Packetization of H.261 video streams'' draft (Dec. 10th 1993). The new version of IVS under RTPv2 which implements the new packetization scheme is a bit delayed (expected by end of June). * Added support for the VigraPix board on SUN platforms. Information on this performant and cheap board is available on the following Web page: . * Added support for the ScreenMachine II board on Linux platforms. Support done by Frank Mueller * Added the -ni option to select a specific network interface rather than the default interface. (for platforms with several network interfaces). * Fixed several bugs. Main bugs are listed below - To limit packet loss at the receiving side, a connect() to the video sender has been added. In this way, all packets by video decoder processes are useful. - On SGI platforms, ivs crashed when there is no board available. Added the video input port selection in the Indy platform. - On SGI platforms, ivs_replay did not initialize the audio device. - The XShm functions were never used. - Removed a bug in the quantization function. - Sometimes the audio receiver slowed down interactivity of the user interface. From list-mgr@ISI.EDU Tue May 23 01:01:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 00:08:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 00:06:40 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 00:06:38 -0700 Received: from louis.ele.eng.osaka-u.ac.jp by quark.isi.edu (5.65c/5.61+local-20) id ; Mon, 22 May 1995 00:06:35 -0700 Received: (from yang@localhost) by louis.ele.eng.osaka-u.ac.jp (8.6.12+2.4W/3.3W9-kodama-prime-950227) id QAA08500; Mon, 22 May 1995 16:01:43 +0900 Date: Mon, 22 May 1995 16:01:43 +0900 From: Yang Jaewon Message-Id: <199505220701.QAA08500@louis.ele.eng.osaka-u.ac.jp> To: mbone unsubcribe From list-mgr@ISI.EDU Tue May 23 01:14:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 00:20:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 00:20:10 -0700 Received: from fgwmail.fujitsu.co.jp by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 00:19:40 -0700 Received: from fdmmail.fujitsu.co.jp by fgwmail.fujitsu.co.jp (8.6.12+2.5Wb4/3.3W5-MX941209-Fujitsu Mail Gateway) id QAA10081; Mon, 22 May 1995 16:19:35 +0900 Received: from pfrad.pfu.fujitsu.co.jp by fdmmail.fujitsu.co.jp (8.6.12+2.5Wb4/3.3W5-MX950127-Fujitsu Domain Mail Master) id QAA27936; Mon, 22 May 1995 16:19:04 +0900 Received: by pfrad.pfu.fujitsu.co.jp (4.12/6.4J.6-PFU-2.0) id AA20771; Mon, 22 May 95 16:21:58 JST Received: by minami.trad.pfu.fujitsu.co.jp (5.0/6.4J.6-PFU-2.0) id AA01795; Mon, 22 May 1995 16:14:35 --900 Message-Id: <9505220714.AA01795@minami.trad.pfu.fujitsu.co.jp> To: mbone Date: Mon, 22 May 1995 16:14:33 +0900 From: liyuekai Content-Length: 13 unsubscribe From list-mgr@ISI.EDU Mon May 22 15:01:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 07:36:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 07:35:21 -0700 Received: from cismsun.univ-lyon1.fr by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 07:35:18 -0700 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id NAA14042 for mbone@isi.edu; Mon, 22 May 1995 13:01:36 +0200 Message-Id: <199505221101.NAA14042@cismsun.univ-lyon1.fr> Subject: PIM and mrouted To: mbone Date: Mon, 22 May 1995 13:01:35 +0200 (MET DST) From: "Lucia Gradinariu" X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 238 Hi, Is there any workaround to stop traffic in a tunnel from a mrouted 3.3 to a PIM (IOS 10.2) when nobody's listening on PIM's dense interface? Any chance to "prune" ? Lucia.Gradinariu@univ-lyon1.fr CISM Univ. Cl.Bernard Lyon FRANCE From list-mgr@ISI.EDU Mon May 22 20:09:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 09:11:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 09:09:38 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 09:09:29 -0700 Received: from delos (eckert@faui45r.informatik.uni-erlangen.de [131.188.34.54]) by immd4.informatik.uni-erlangen.de with SMTP id SAA10590 (8.6.12/7.4b-FAU);; Mon, 22 May 1995 18:09:20 +0200 From: Toerless Eckert Message-Id: <199505221609.SAA10590@faui40.informatik.uni-erlangen.de> Subject: Re: PIM and mrouted To: lucia@univ-lyon1.fr (Lucia Gradinariu) Date: Mon, 22 May 1995 18:09:17 +0200 (MET DST) Cc: mbone In-Reply-To: <199505221101.NAA14042@cismsun.univ-lyon1.fr> from "Lucia Gradinariu" at May 22, 95 01:01:35 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Is there any workaround to stop traffic in a tunnel from a > mrouted 3.3 to a PIM (IOS 10.2) when nobody's listening on PIM's dense > interface? Any chance to "prune" ? As long as the mrouted host and the PIM router are on a common ethernet interface and not on a tunnel together pruning will work. On a tunnel, the pim router will listen to DVMRP routing updates and provide them to the mrouted machine. This setup destroys pruning. Running the machines together on an ethernet will cause the pim router not to send out dvmrp updates but only use igmp to register for groups with members in the pim cloud behin it. This will make pruning work with the one exception that all traffic within the pim cloud gets transmitted to the dvmrp router where it is pruned first. Best regards Toerless From list-mgr@ISI.EDU Mon May 22 08:50:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 09:50:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 09:50:23 -0700 Received: from fantasia.eng.clemson.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 May 1995 09:50:22 -0700 Received: (from dcrane@localhost) by fantasia.eng.clemson.edu (8.6.10/8.6.9) id MAA29351; Mon, 22 May 1995 12:50:20 -0400 Date: Mon, 22 May 1995 12:50:19 -0400 (EDT) From: Darren Crane To: mbone Subject: unsuscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please remove me from this list. Sorry to all that got this message. From list-mgr@ISI.EDU Tue May 23 13:32:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 23 May 1995 02:38:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 23 May 1995 02:33:01 -0700 Received: from cismsun.univ-lyon1.fr by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 23 May 1995 02:32:51 -0700 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id LAA26501; Tue, 23 May 1995 11:32:45 +0200 Message-Id: <199505230932.LAA26501@cismsun.univ-lyon1.fr> Subject: Re: PIM and mrouted To: Toerless.Eckert@informatik.uni-erlangen.de (Toerless Eckert) Date: Tue, 23 May 1995 11:32:44 +0200 (MET DST) From: "Lucia Gradinariu" Cc: mbone In-Reply-To: <199505221609.SAA10590@faui40.informatik.uni-erlangen.de> from "Toerless Eckert" at May 22, 95 06:09:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2082 > > > Is there any workaround to stop traffic in a tunnel from a > > mrouted 3.3 to a PIM (IOS 10.2) when nobody's listening on PIM's dense > > interface? Any chance to "prune" ? > > As long as the mrouted host and the PIM router are on a common > ethernet interface and not on a tunnel together pruning will work. With the penalty of doubling the traffic on the common network because of mrouted tunnel to Mbone. Thinking that an active conference (1 audio + 1 video channels) issues the same traffic as a News server I'll surely bias the quality of reception. The Ethernet where I can "join" PIM and mrouted is commonly a campus net "backbone" or its interconnection to Internet. Both of them support aggregated traffic (one intern traffic the other egress/ingress campus net traffic) so the charge will be heavy. On the other hand, I have to dimension my net to support some conferences in the same time. But how many? I think this will depend on how many may be active at a time (in my region). Let's say N. A very coarse approximation sais that if I have in the PIM cloud N/2 the first solution is better for me (always worse for Mbone community). > > On a tunnel, the pim router will listen to DVMRP routing updates > and provide them to the mrouted machine. This setup destroys pruning. Is this because PIM uses a format for its Report messages which is different from DVMRP's? > Running the machines together on an ethernet will cause the pim router > not to send out dvmrp updates but only use igmp to register for groups with > members in the pim cloud behin it. This will make pruning work with the > one exception that all traffic within the pim cloud gets transmitted to > the dvmrp router where it is pruned first. From my egoist point of view, this wouldn't harm so much because traffic sources are locale so they could be shut-down if not usefull. > Best regards > Toerless > Thanks, Lucia.Gradinariu@univ-lyon1.fr From list-mgr@ISI.EDU Tue May 23 14:49:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 23 May 1995 03:51:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 23 May 1995 03:49:57 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 23 May 1995 03:49:54 -0700 Received: from delos (eckert@faui45r.informatik.uni-erlangen.de [131.188.34.54]) by immd4.informatik.uni-erlangen.de with SMTP id MAA21530 (8.6.12/7.4b-FAU);; Tue, 23 May 1995 12:49:52 +0200 From: Toerless Eckert Message-Id: <199505231049.MAA21530@faui40.informatik.uni-erlangen.de> Subject: Re: PIM and mrouted To: lucia@univ-lyon1.fr (Lucia Gradinariu) Date: Tue, 23 May 1995 12:49:47 +0200 (MET DST) Cc: Toerless.Eckert@informatik.uni-erlangen.de, mbone In-Reply-To: <199505230932.LAA26501@cismsun.univ-lyon1.fr> from "Lucia Gradinariu" at May 23, 95 11:32:44 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > As long as the mrouted host and the PIM router are on a common > > ethernet interface and not on a tunnel together pruning will work. > With the penalty of doubling the traffic on the common network > because of mrouted tunnel to Mbone. Thinking that an active conference Nobody said you have to run the tunnels on the same interface. It's all a question of topology design. The cisco doesn't introduce additional overhad for this problem. > > On a tunnel, the pim router will listen to DVMRP routing updates > > and provide them to the mrouted machine. This setup destroys pruning. > Is this because PIM uses a format for its Report messages which is > different from DVMRP's? I guess the argument goes in that direction. At least it wasn't considered uttermost important and still is not by cisco. > > Running the machines together on an ethernet will cause the pim router > > not to send out dvmrp updates but only use igmp to register for groups with > > members in the pim cloud behin it. This will make pruning work with the > > one exception that all traffic within the pim cloud gets transmitted to > > the dvmrp router where it is pruned first. > From my egoist point of view, this wouldn't harm so much because traffic > sources are locale so they could be shut-down if not usefull. Right. In my configuration (university runs PIM, external access runs through a Sun with DVMRP) i've already changed the threshold on the last PIM router so that only that traffic is passed to the dvmrp ether that is expected to go outside the university anyway. Toerless From list-mgr@ISI.EDU Wed May 24 14:41:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 24 May 1995 15:43:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 24 May 1995 15:43:29 -0700 Received: from prom.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 24 May 1995 15:43:28 -0700 Received: (dschluss@localhost) by prom.engin.umich.edu (8.6.12/8.6.4) id SAA18289; Wed, 24 May 1995 18:43:15 -0400 Date: Wed, 24 May 1995 18:41:23 -0400 (EDT) From: "david a. schlussel" Sender: "david a. schlussel" Reply-To: "david a. schlussel" Subject: reflect.conf To: mbone, rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII my reflector has been giving me this error recvfrom error on msg_sock : Socket operation on non-socket: FATAL ERROR: EXITING when i try to run it. I didn't see anything in any of the faqs. anyone else run into this problem? -david From list-mgr@ISI.EDU Wed May 24 09:42:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 24 May 1995 16:42:09 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 24 May 1995 16:42:08 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id QAA19819; Wed, 24 May 1995 16:42:40 -0700 Message-Id: <199505242342.QAA19819@rx7.ee.lbl.gov> To: mbone-na Subject: b61464.student.CWRU.edu sending continuously to mbone Date: Wed, 24 May 95 16:42:39 PDT From: Van Jacobson Host b61464.STUDENT.CWRU.Edu (129.22.240.24) has been sending 70-80 kb/s continuously to 224.24.0.5/3000 for at least the past 24 hours. The MBone has very limited bandwidth (500kb/s) and is fairly busy this week with things like Dan Farmer's talk at Ohio State and the NANOG meeting. Perhaps the person originating this session could either stop it or reduce the ttl so that it stayed inside Case Western. Thanks. - Van Jacobson From list-mgr@ISI.EDU Fri May 26 03:29:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 25 May 1995 00:36:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 25 May 1995 00:35:28 -0700 Received: from neptune.anu.edu.au by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 25 May 1995 00:35:24 -0700 Received: from neptune (localhost) by neptune.anu.edu.au with SMTP id AA17066 (5.67b/IDA-1.5 for ); Thu, 25 May 1995 17:29:12 +1000 Message-Id: <199505250729.AA17066@neptune.anu.edu.au> X-Mailer: exmh version 1.6 4/21/95 To: "david a. schlussel" Cc: mbone, rem-conf@es.net Subject: Re: reflect.conf In-Reply-To: Your message of "Wed, 24 May 1995 18:41:23 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 May 1995 17:29:11 +1000 From: "John D. Barlow" > my reflector has been giving me this error > > recvfrom error on msg_sock : Socket operation on non-socket: > FATAL ERROR: EXITING Me too. Then I noticed that with a different reflect.conf file it didn't happen (note: only happened to me when I tried to put the "reflect" into background). Basically it won't handle being run in background with multicast "NV-MC-IN" and "NV-MC-OUT" being defined (and you can't define them differently) - same with "VAT-MC-IN" and "VAT-MC-OUT". For the moment I am using unicast nv & vat, and it runs beautifully in the background. Another problem with the reflector code is that in the reflect.conf a semicolon (;) must be followed by some text, otherwise the program fails to parse the next line ... A question - has anybody got the "ADMIT" keyword to work such that _only_ the given IP addresses can see/hear things from the reflector ? I am trying to set up a reflector with security restrictions so that only certain Mac and Sun clients can see/hear each other. Have fun, thanks for any feedback, John Barlow (PS: thanks to the reflector code author(s) for all the work they have done to get it where is is today !) From list-mgr@ISI.EDU Fri May 26 07:43:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 25 May 1995 04:46:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 25 May 1995 04:46:02 -0700 Received: from neptune.anu.edu.au by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 25 May 1995 04:45:59 -0700 Received: from neptune (localhost) by neptune.anu.edu.au with SMTP id AA17681 (5.67b/IDA-1.5 for ); Thu, 25 May 1995 21:43:52 +1000 Message-Id: <199505251143.AA17681@neptune.anu.edu.au> X-Mailer: exmh version 1.6 4/21/95 To: mbone, rem-conf@es.net Subject: Re: reflect.conf (use of ADMIT) In-Reply-To: Your message of "Thu, 25 May 1995 17:29:11 +1000." <199505250729.AA17066@neptune.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 May 1995 21:43:51 +1000 From: "John D. Barlow" I wrote in my previous message: > A question - has anybody got the "ADMIT" keyword to work such that > _only_ the given IP addresses can see/hear things from the reflector ? As a friend would say "use the force, read the source". It turns out that "ADMIT" has an implicit deny for all hosts not mentioned _but_ this is only applied to CUSeeMe input. I want it applied to all attempts to connect to the reflector (including unicast NV/VAT, and maybe even multicast NV/VAT). I added some code to "reflect.c" (around about line 160): case NV_UCAST: case NV_MCAST: if (restrict_cnt != 0) { goodmbone=0; for (cnt=0; cnt; Thu, 25 May 1995 14:06:11 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 25 May 1995 14:06:10 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id OAA21216; Thu, 25 May 1995 14:06:48 -0700 Message-Id: <199505252106.OAA21216@rx7.ee.lbl.gov> To: mbone-na Subject: Case Western Reserve University still sending garbage to the mbone Date: Thu, 25 May 95 14:06:47 PDT From: Van Jacobson Host b61464.student.cwru.edu (129.22.240.24), a linux box at Case Western Reserve University, is still sending 70-80 kb/s to 224.24.0.5/3000. It has been doing this, continuously, for more than two days. This is rather antisocial. Is there anyone at Case Western that could stop this? If not, perhaps their tunnel provider (ns2.oar.net) could do something. Thanks. - Van From list-mgr@ISI.EDU Fri May 26 15:54:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 26 May 1995 22:54:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 26 May 1995 22:53:47 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 26 May 1995 22:53:46 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id WAA23216; Fri, 26 May 1995 22:54:19 -0700 Message-Id: <199505270554.WAA23216@rx7.ee.lbl.gov> To: dino@cisco.com Cc: mbone, kc@upeksa.sdsc.edu, brutzman@cs.nps.navy.mil Subject: serious multicast routing loop at cisco Date: Fri, 26 May 95 22:54:18 PDT From: Van Jacobson Dino, There appears to be a serious multicast routing loop at or near cisco. This one has a slightly different behavior than the loops that cisco usually generates: It seems to be transient and appears every 3 minutes. E.g., I see 3 minutes worth of session messages from cbone-ss10 (~20 packets) that don't loop, then one that loops 120 times, another 3 minutes worth that don't loop, another that loops, etc. I've been watching the pattern for an hour now & it seems quite stable. Needless to say, the huge packet bursts from the cisco loop are doing bad things to nearby routers at barrnet and/or ames (this loop may be what caused the audio problems Kim Claffy observed during today's Hamming lecture). I can't tell from here whether it's at cisco or on the pim router at barrnet but it probably needs to be found & fixed fairly quickly. Thanks. - Van ----------------------- 21:49:37.049085 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 179, id 24603) 21:49:37.057498 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 178, id 24603) 21:49:37.075519 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 176, id 24603) 21:49:37.084152 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 175, id 24603) 21:49:37.092219 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 173, id 24603) 21:49:37.100200 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 172, id 24603) 21:49:37.108636 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 170, id 24603) 21:49:37.116745 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 169, id 24603) 21:49:37.291137 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 167, id 24603) 21:49:37.299081 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 166, id 24603) 21:49:37.322162 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 164, id 24603) 21:49:37.330235 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 163, id 24603) 21:49:37.338256 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 161, id 24603) 21:49:37.346533 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 160, id 24603) 21:49:37.354544 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 158, id 24603) 21:49:37.362566 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 157, id 24603) 21:49:37.504503 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 155, id 24603) 21:49:37.512408 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 154, id 24603) 21:49:37.521386 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 152, id 24603) 21:49:37.528950 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 151, id 24603) 21:49:37.536850 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 149, id 24603) 21:49:37.545258 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 148, id 24603) 21:49:37.553372 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 146, id 24603) 21:49:37.561831 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 145, id 24603) 21:49:37.570244 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 143, id 24603) 21:49:37.579184 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 142, id 24603) 21:49:37.586690 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 140, id 24603) 21:49:37.594700 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 139, id 24603) 21:49:37.602560 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 137, id 24603) 21:49:37.611623 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 136, id 24603) 21:49:37.621833 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 134, id 24603) 21:49:37.627060 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 133, id 24603) 21:49:37.635383 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 131, id 24603) 21:49:37.643418 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 130, id 24603) 21:49:37.651752 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 128, id 24603) 21:49:37.660216 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 127, id 24603) 21:49:37.668635 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 125, id 24603) 21:49:37.676738 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 124, id 24603) 21:49:37.685426 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 122, id 24603) 21:49:37.693530 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 121, id 24603) 21:49:37.701585 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 119, id 24603) 21:49:37.709802 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 118, id 24603) 21:49:37.718029 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 116, id 24603) 21:49:37.727457 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 115, id 24603) 21:49:37.734224 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 113, id 24603) 21:49:37.742403 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 112, id 24603) 21:49:37.750514 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 110, id 24603) 21:49:37.758807 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 109, id 24603) 21:49:37.766789 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 107, id 24603) 21:49:37.774811 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 106, id 24603) 21:49:37.782814 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 104, id 24603) 21:49:37.791119 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 103, id 24603) 21:49:37.799117 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 101, id 24603) 21:49:37.807637 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 100, id 24603) 21:49:37.815032 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 98, id 24603) 21:49:37.823326 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 97, id 24603) 21:49:37.831368 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 95, id 24603) 21:49:37.839541 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 94, id 24603) 21:49:37.847696 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 92, id 24603) 21:49:37.855411 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 91, id 24603) 21:49:37.864000 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 89, id 24603) 21:49:37.871476 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 88, id 24603) 21:49:37.879656 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 86, id 24603) 21:49:37.887646 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 85, id 24603) 21:49:37.895667 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 83, id 24603) 21:49:37.903813 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 82, id 24603) 21:49:37.912003 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 80, id 24603) 21:49:37.919772 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 79, id 24603) 21:49:37.928180 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 77, id 24603) 21:49:37.935919 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 76, id 24603) 21:49:37.943965 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 74, id 24603) 21:49:37.951959 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 73, id 24603) 21:49:37.960175 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 71, id 24603) 21:49:37.968166 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 70, id 24603) 21:49:37.976606 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 68, id 24603) 21:49:37.984271 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 67, id 24603) 21:49:37.992115 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 65, id 24603) 21:49:38.000330 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 64, id 24603) 21:49:38.017309 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 62, id 24603) 21:49:38.024843 cbone-ss10.cisco.com.1429 > 224.2.0.1.3457: (ttl 61, id 24603) From list-mgr@ISI.EDU Fri May 26 17:02:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 27 May 1995 00:03:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 27 May 1995 00:02:45 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 27 May 1995 00:02:44 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id AAA12646; Sat, 27 May 1995 00:02:25 -0700 Date: Sat, 27 May 1995 00:02:25 -0700 From: Dino Farinacci Message-Id: <199505270702.AAA12646@stilton.cisco.com> To: van@ee.lbl.gov Cc: mbone, kc@upeksa.sdsc.edu, brutzman@cs.nps.navy.mil, ecs-net@cisco.com In-Reply-To: Van Jacobson's message of Fri, 26 May 95 22:54:18 PDT <199505270554.WAA23216@rx7.ee.lbl.gov> Subject: serious multicast routing loop at cisco >> during today's Hamming lecture). I can't tell from here whether >> it's at cisco or on the pim router at barrnet but it probably >> needs to be found & fixed fairly quickly. Thanks. The problem was at the first hop router(s) directly connected to cbone-ss10. There was a bug in one of them that forwarded on the shared-tree where another parallel router was forwarding on the source-tree. Of course the RP and the source were in different directions which cause the loop to spin via the two routers (with other routers forwarding it towards our AS exit point). I fixed the problem and haven't seen loops for the last 20 minutes. Sorry for the nuisance. Dino From list-mgr@ISI.EDU Fri May 26 17:09:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 27 May 1995 00:11:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 27 May 1995 00:08:48 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 27 May 1995 00:08:47 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id AAA23238; Sat, 27 May 1995 00:09:19 -0700 Message-Id: <199505270709.AAA23238@rx7.ee.lbl.gov> To: mbone, rem-conf@es.net Subject: linux vat, sd & wb available on ftp.ee.lbl.gov Date: Sat, 27 May 95 00:09:17 PDT From: Van Jacobson Two weeks ago I sent a message saying we had just purchased a machine for linux development & it would probably take about two weeks to port vat, sd & wb to linux. Thanks to a lot of help from Craig Leres, it only took 9 days. We then spent 4 days trying (unsuccessfully) to fix a problem with the linux multicast code so we could offer a patch with the tools. Since the tools are usable even without fixing the kernel problem, we've decided to release them without a kernel patch. They're available in the usual place. I.e., ftp://ftp.ee.lbl.gov/conferencing/vat/linux-vat-3.5.tar.Z ftp://ftp.ee.lbl.gov/conferencing/wb/linux-wb-1.59.tar.Z ftp://ftp.ee.lbl.gov/conferencing/sd/linux-sd-1.17.tar.Z Everything has been build under the Slackware 1.2.8 distribution. The tools were all linked '-static' in the hopes of minimizing problems with different versions of various libraries. They were also all compiled "-g" so interested parties could send us gdb tracebacks with bug reports. Since -g makes the binaries huge, you might want to strip them if your system is tight on disk space. Let us know of any problems. Thanks. - Van Jacobson & Steve McCanne ------------ This is the README.linux from vat: Notes on vat for linux. Wed May 24 08:50:53 PDT 1995 This is the first release of vat for linux. It has had very little testing so expect bugs. There are some minor problems due to the way PC audio cards work & a major problem from a missing part of the linux multicast code. The audio problems are: - Most PC audio is half-duplex (cannot play & record at the same time) so none of the 'speakerphone' or full-duplex audio modes of vat are available. Essentially you always run in "mike mutes net" mode. We have a PAS-16 on order (the one card we know of that does full duplex audio) and hope to work on full-duplex linux audio support whenever it shows up. That's probably at least a month away. - The linux audio driver doesn't include any way to set the play or record volume so the volume sliders do nothing. The major problem is the multicast code is that multicast through the loopback interface does not work. This is a very serious deficiency since local (loopback) multicast sockets are used to implement "conference busses" that vat/vic/etc. use to do things like pass the audio hardware between different vats, automatically switch video windows on audio activity, etc. We, and others, also have floor & conference control agents (for moderated meetings) and key distribution agents (for private meetings with dynamic membership control) in the works. None of these things will work on linux without fixing the linux kernel. I was hoping to come up with a patch for this but, since the loopback interface is used (wrongly, in my view) to implement the IP_MULTICAST_LOOP socket option, quite a lot of code needs to be changed & I haven't yet figured out enough of the linux socket buffer & locking/ipl conventions to make the changes. Ignoring the future tools that won't work, right now you will find that the lack of local multicast makes it *very* difficult to switch the audio between multiple instances of vat. You will probably want to run just one at a time. There is another, minor, multicast bug that doesn't allow the multicast ttl to be set to 0 (the spec specifically defines 0 as "this machine"). I think the code in linux/net/inet/ip.c should be patched as follows: diff -c -r1.1 ip.c *** 1.1 1995/05/27 06:24:35 --- ip.c 1995/05/27 06:25:28 *************** *** 2090,2096 **** unsigned char ucval; ucval=get_fs_byte((unsigned char *)optval); ! if(ucval<1||ucval>255) return -EINVAL; sk->ip_mc_ttl=(int)ucval; return 0; --- 2090,2096 ---- unsigned char ucval; ucval=get_fs_byte((unsigned char *)optval); ! if(ucval>255) return -EINVAL; sk->ip_mc_ttl=(int)ucval; return 0; This bug currently has little effect but will be annoying if the loopback bug is fixed. Good luck. Please send any bug reports to "vat@ee.lbl.gov". Thanks. From list-mgr@ISI.EDU Mon May 29 18:35:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 29 May 1995 07:37:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 29 May 1995 07:35:32 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 29 May 1995 07:35:30 -0700 Received: from anxiety.electrum.kth.se (anxiety.electrum.kth.se [130.237.215.110]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id QAA09289; Mon, 29 May 1995 16:34:50 +0200 Received: from localhost.electrum.kth.se (localhost.electrum.kth.se [127.0.0.1]) by anxiety.electrum.kth.se (8.6.9/8.6.9) with SMTP id QAA07373; Mon, 29 May 1995 16:35:12 +0200 Message-Id: <199505291435.QAA07373@anxiety.electrum.kth.se> X-Authentication-Warning: anxiety.electrum.kth.se: Host localhost.electrum.kth.se didn't use HELO protocol To: mbone Cc: flag@it.kth.se Subject: PIM configuration FAQ? Date: Mon, 29 May 95 16:35:11 +0200 From: Christian Wettergren Hi! Is there any step-by-step guide for how to get the PIM to work with MBone? Anyone wanna share experiences? :-) I'm somewhat worried about the setup, since PIM has thrashed MBone a couple of times. What should one _not_ do? Thanks in advance! /Christian Wettergren, KTH/Teleinformatics From list-mgr@ISI.EDU Mon May 29 12:42:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 29 May 1995 19:48:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 29 May 1995 19:43:06 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 29 May 1995 19:43:05 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id TAA04036; Mon, 29 May 1995 19:42:32 -0700 Date: Mon, 29 May 1995 19:42:32 -0700 From: Dino Farinacci Message-Id: <199505300242.TAA04036@stilton.cisco.com> To: cwe@it.kth.se Cc: mbone, flag@it.kth.se In-Reply-To: Christian Wettergren's message of Mon, 29 May 95 16:35:11 +0200 <199505291435.QAA07373@anxiety.electrum.kth.se> Subject: PIM configuration FAQ? >> I'm somewhat worried about the setup, >> since PIM has thrashed MBone a couple of times. >> What should one _not_ do? I like to clarify a couple of things. PIM doesn't trash the MBONE. What trashes the MBONE is when too many unicast routes are advertised via DVMRP into the MBONE. If you want to know how to interoperate a cisco router running PIM and DVMRP with an mrouted machine, send email to multicast-support@cisco.com. Dino From list-mgr@ISI.EDU Mon May 29 18:52:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 01:55:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 01:51:52 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 01:51:51 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id BAA26946; Tue, 30 May 1995 01:52:03 -0700 Message-Id: <199505300852.BAA26946@rx7.ee.lbl.gov> To: cwe@it.kth.se Cc: dino@cisco.com, mbone, flag@it.kth.se Subject: Re: PIM configuration FAQ? In-Reply-To: Your message of Mon, 29 May 95 19:42:32 PDT. Date: Tue, 30 May 95 01:52:02 PDT From: Van Jacobson On Mon, 29 May 1995 19:42, Dino Farinacci said: > I like to clarify a couple of things. PIM doesn't trash the > MBONE. What trashes the MBONE is when too many unicast routes > are advertised via DVMRP into the MBONE. Hmm. Dino's answer was certainly a creative use of english but it probably leaves the wrong impression. Let me try to add some words he left out. PIM and DVMRP (the MBone/mrouted's protocol) work off of completely different models of the world & don't interoperate. To glue sites running cisco's PIM into the MBone, cisco supplies a DVMRP `stub' whose function in life is to make the local network numbers known to MBone & announce the stub's router as the best route to them. (When Dino says "DVMRP" above he's referring to his DVMRP stub.) The problem the stub has is that PIM isn't a routing protocol (it uses unicast routing) so it doesn't know which of all the networks it knows about have multicast clients on them. Since the networks that the stub needs to advertise can't be learned automatically, they need to be configured. Cisco provided two configuration options: 1) advertise the nets directly connected to the stub and 2) advertise all the nets known to the stub. I think (2) was intended to handle the case of a leaf network with a single attachment to the Internet & with a default route aimed at that attachment point. Thus the nets it knows about are just the leaf's nets. (I said "I think" because I never understood the rationale for (2) and, when Dino first proposed it a year ago at a PIM design meeting, Deborah Estrin, Steve Deering and I all said it was a seriously bad & dangerous idea.) Option (2) really advertises *all* the routes known locally so if you configure it and are not a singly-connected leaf (which means that you probably have to import most of the 20,000 routes of the Internet), your stub will inject all 20,000 of those routes into DVMRP/the MBone. This will crash mrouters all over the world. When PIM first shipped there was only a 1 character difference between option (1) & (2) (something like typing a 0 or 1 for some obscure config parameter) with no "sanity check" code or warning that you might be doing something dangerous. After the 10th or 12th time that some poor user typed in the wrong value and got flamed all over the planet, cisco finally admitted that they might have a problem and made it slightly more difficult to screw up the configuration. I have only seen one meltdown from this particular PIM problem since cisco changed their code but there may have been more. While getting this configuration parameter wrong is probably the easiest way to trash the MBone & meet a lot of new, angry, people, it is not the only way. Ever since cisco's PIM started to get widely deployed, we've seen a huge increase in duplicate packets on the MBone. On some important links there are more duplicates than originals. [The case I'm most worried about is the US-UK link -- we get many reports of poor audio reception in the UK & every time I've looked into it the cause has been duplicate packets (which vat doesn't filter out very well so they cause weird sounds). And we've started to use video from the UK as a test of the duplicate suppression code in vic -- last week I noticed 200kb/s coming from a MICE address (very unusual because they're very careful about bandwidth) and when I looked at the data stream it turned out to be 64kb/s of video & 128kb/s of duplicates, e.g., every packet duplicated twice.] Cisco has fixed some bugs that caused loops (which generate large numbers of duplicates) but there has still been a steady increase in the 'background' level of packets duplicated 1-3 times. I can think of two possible causes: Dense-mode PIM uses to an "assert" (contention) algorithm to decide which of multiple routers on a wire will forward packets. Steve Deering has pointed out that this is substantially less robust than the poisoned-reverse that DVMRP uses & there may be stable states of the dense-mode PIM algorithm, or cisco's implementation of it, where two routers both forward packets (which would generate dups but no loops). Another possible cause is simply that PIM & DVMRP are so fundamentally different. DVMRP is a routing protocol that computes distribution spanning trees based on hop-count metrics. All it knows about is the multicast nets & the virtual links (tunnels) between them, there is no information at all on the underlying physical topology. By contrast, PIM knows nothing about multicast hops, multicast nets or tunnels, all it knows is the underlying physical topology (via questions it asks of unicast routing). There is no reason for DVMRP's view of the world to match PIM's in any way yet, to distribute multicast with no duplicates & no black holes, the two views have to result in a single, self-consistent spanning tree for every possible traffic source. Right now, essentially the only way to generate the necessary consistency between the two views is to attach a PIM cloud to the MBone at a place where the unicast & multicast views of the world are the same. I.e., the PIM cloud has to have a single attachment to the Internet & the DVMRP stub should run at that attachment point. (There are a few other configurations that can be made to work but they are complicated & extremely fragile.) This model fits a lot of leaf sites (like a campus or company attached to the Internet through a single firewall DMZ) but does not fit the nets of a lot of the ISP's that have been experimenting with PIM. Cisco has not been very good about telling customers the topological limitations of PIM (in fact, I heard one cisco salesman tell a customer that PIM could be used as a transit between two DVMRP clouds even though it's almost impossible to make that work). That overzealous selling could have caused cisco PIM to be used in topologies where it won't work & the result is duplicates and/or black holes. Another worry you might have with cisco's PIM is that it doesn't do pruning. (This is another area where cisco has frequently played with words: PIM has its own from of prunes. When someone asks cisco "does PIM do pruning?" they say "yes", meaning PIM prunes, when the customer was almost certainly asking about MBone/mrouted prunes for which the answer is "no".) I.e., the DVMRP stub implements a (subset of) the mrouted 2.x protocol. The 2.x protocol does not include prunes and grafts. When a 3.x router finds itself talking to a 2.x router, the 3.x router can no longer prune anything (since a 2.x router can't prune, it always gets everything & anyone upstream of it gets stuck with transitting everything). So say, for example, your country has been very careful to deploy only pruning mrouteds so the only inbound international traffic is for sessions that are actually being watched. If even one site in the country starts running cisco PIM, suddenly all the world's traffic starts coming over the international links, not just the interesting stuff, because the 2.x cisco DVMRP stub can't prune any of it off. (I don't know of any international link where the traffic is actually monitored well enough to detect this but if someone ever takes a look, they might get mad at you.) As a final note, I should say that Steve Deering's & Bill Fenner's work on hierarchical DVMRP should solve all of these PIM problems -- it will prevent the route explosions, remove the topological restrictions on interconnecting PIM to the MBone, and provide a place to translate between PIM prunes & DVMRP prunes (assuming that cisco will take forever to bring their stub up the v3 protocol). But I would guess that hierarchical DVMRP is still several months away so in the interim we have a number of things to watch out for. - Van From list-mgr@ISI.EDU Tue May 30 11:13:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 02:34:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 02:29:32 -0700 Received: from iiit.swan.ac.uk ([137.44.100.1]) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 02:29:16 -0700 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Linux vat, sd & wb... To: vat@ee.lbl.gov Date: Tue, 30 May 1995 10:13:59 +0100 (BST) Cc: mbone X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 4643 > Subject: linux vat, sd & wb available on ftp.ee.lbl.gov > From: Van Jacobson > Two weeks ago I sent a message saying we had just purchased > a machine for linux development & it would probably take > about two weeks to port vat, sd & wb to linux. Thanks to > a lot of help from Craig Leres, it only took 9 days. We > then spent 4 days trying (unsuccessfully) to fix a problem > with the linux multicast code so we could offer a patch > with the tools. Since the tools are usable even without fixing > the kernel problem, we've decided to release them without a > kernel patch. They're available in the usual place. I.e., > > ftp://ftp.ee.lbl.gov/conferencing/vat/linux-vat-3.5.tar.Z > ftp://ftp.ee.lbl.gov/conferencing/wb/linux-wb-1.59.tar.Z > ftp://ftp.ee.lbl.gov/conferencing/sd/linux-sd-1.17.tar.Z > > Everything has been build under the Slackware 1.2.8 distribution. > The tools were all linked '-static' in the hopes of minimizing > problems with different versions of various libraries. They were > also all compiled "-g" so interested parties could send us gdb > tracebacks with bug reports. Since -g makes the binaries huge, > you might want to strip them if your system is tight on disk space. > Let us know of any problems. Thanks. > > - Van Jacobson & Steve McCanne > > > ------------ This is the README.linux from vat: > > Notes on vat for linux. Wed May 24 08:50:53 PDT 1995 > > This is the first release of vat for linux. It has had very > little testing so expect bugs. There are some minor problems > due to the way PC audio cards work & a major problem from > a missing part of the linux multicast code. The audio problems > are: > > - Most PC audio is half-duplex (cannot play & record at the > same time) so none of the 'speakerphone' or full-duplex > audio modes of vat are available. Essentially you always > run in "mike mutes net" mode. > > We have a PAS-16 on order (the one card we know of that does > full duplex audio) and hope to work on full-duplex linux audio > support whenever it shows up. That's probably at least a > month away. > > - The linux audio driver doesn't include any way to set the > play or record volume so the volume sliders do nothing. > > The major problem is the multicast code is that multicast through > the loopback interface does not work. This is a very serious > deficiency since local (loopback) multicast sockets are used to > implement "conference busses" that vat/vic/etc. use to do things > like pass the audio hardware between different vats, automatically > switch video windows on audio activity, etc. We, and others, also > have floor & conference control agents (for moderated meetings) > and key distribution agents (for private meetings with dynamic > membership control) in the works. None of these things will > work on linux without fixing the linux kernel. I was hoping to > come up with a patch for this but, since the loopback interface > is used (wrongly, in my view) to implement the IP_MULTICAST_LOOP > socket option, quite a lot of code needs to be changed & I haven't > yet figured out enough of the linux socket buffer & locking/ipl > conventions to make the changes. > > Ignoring the future tools that won't work, right now you will > find that the lack of local multicast makes it *very* difficult > to switch the audio between multiple instances of vat. You will > probably want to run just one at a time. > > There is another, minor, multicast bug that doesn't allow the > multicast ttl to be set to 0 (the spec specifically defines 0 > as "this machine"). I think the code in linux/net/inet/ip.c > should be patched as follows: > > diff -c -r1.1 ip.c > *** 1.1 1995/05/27 06:24:35 > --- ip.c 1995/05/27 06:25:28 > *************** > *** 2090,2096 **** > unsigned char ucval; > > ucval=get_fs_byte((unsigned char *)optval); > ! if(ucval<1||ucval>255) > return -EINVAL; > sk->ip_mc_ttl=(int)ucval; > return 0; > --- 2090,2096 ---- > unsigned char ucval; > > ucval=get_fs_byte((unsigned char *)optval); > ! if(ucval>255) > return -EINVAL; > sk->ip_mc_ttl=(int)ucval; > return 0; > > This bug currently has little effect but will be annoying if the > loopback bug is fixed. > > Good luck. Please send any bug reports to "vat@ee.lbl.gov". Thanks. From list-mgr@ISI.EDU Tue May 30 11:22:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 03:15:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 03:05:43 -0700 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 03:02:37 -0700 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: linux vat, sd & wb available on ftp.ee.lbl.gov To: mbone, vat@ee.lbl.gov Date: Tue, 30 May 1995 10:22:38 +0100 (BST) Cc: linux-multicast@www.linux.org.uk X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2044 > To: mbone@ISI.EDU, rem-conf@es.net > From: Van Jacobson Apologies for just bouncing the original message back to the list. Elm can be dangerous in the presence of Line noise. > - The linux audio driver doesn't include any way to set the > play or record volume so the volume sliders do nothing. The audio mixer code handles this part. Email me back and I'll send you an example. You can either drive the mixer via vat (as you would expect), or via an external mixer program like xvmixer. > The major problem is the multicast code is that multicast through > the loopback interface does not work. This is a very serious > deficiency since local (loopback) multicast sockets are used to > implement "conference busses" that vat/vic/etc. use to do things It ought to work 8). I will verify this and make a fix available if it is a problem (and given the name of the bug reporter I suspect its genuine) > come up with a patch for this but, since the loopback interface > is used (wrongly, in my view) to implement the IP_MULTICAST_LOOP > socket option, quite a lot of code needs to be changed & I haven't > yet figured out enough of the linux socket buffer & locking/ipl > conventions to make the changes. There are some fairly specific internal reasons for this to do with what happens if multicasts cause multicasts cause multicasts and running out of stack. If you find bugs in the Linux networking code the person to mail is me (Alan.Cox@linux.org). I do try and fix all the reported bugs especially when there are clear test cases I can run through a kernel under kernel gdb. > There is another, minor, multicast bug that doesn't allow the > multicast ttl to be set to 0 (the spec specifically defines 0 > as "this machine"). I think the code in linux/net/inet/ip.c > should be patched as follows: Added ready for 1.3.0 and submitted for inclusion in 1.2.9 if it beats Linus to sending out 1.2.9 PS: I don't normally read this list (I wish I had the time), so Cc: me back anything you want me to see. Alan From list-mgr@ISI.EDU Tue May 30 02:37:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 09:37:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 09:37:06 -0700 Received: from glare.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 09:37:05 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA02501 for ; Tue, 30 May 1995 09:37:05 -0700 Message-Id: <199505301637.JAA02501@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: mbone Subject: PIM configuration Information Date: Tue, 30 May 1995 09:37:04 -0700 From: "John M. Zwiebel" For 10.2 and 10.3 images you can find PIM configuration in the documents covering cisco IOS. You can also subscribe to the cd-rom with complete IOS documentation. Otherwise you may obtain information specific to PIM from: ftp.cisco.com://ftp/dino/multicast/Docs All-Commands cisco-mrinfo Multicast-over-GRE Quickstart-dvmrp Quickstart-pim As far as PIM is concerned there is little or no difference between 10.2 and 10.3. It is easiest to configure your network to run in densemode. If you choose sparse mode, you should configure your network to have the RP as close to the exit point from your network as possible. If you have a DVMRP tunnel into your network, you may want to move its endpoint to the cisco router, however, we do not support DVMRP pruning. Finally, PIM depends on the underlying unicast routing table to make multicast forwarding decisions. This means you need to understand the idea of RPF or reverse path forwarding (you aren't concerned with where the packet is going but where it came from) and you must have your unicast routing and multicast routing agree with each other. z From list-mgr@ISI.EDU Tue May 30 04:23:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 11:25:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 11:24:46 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 11:24:45 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id LAA28426; Tue, 30 May 1995 11:23:02 -0700 Date: Tue, 30 May 1995 11:23:02 -0700 From: Dino Farinacci Message-Id: <199505301823.LAA28426@stilton.cisco.com> To: van@ee.lbl.gov Cc: cwe@it.kth.se, mbone, flag@it.kth.se In-Reply-To: Van Jacobson's message of Tue, 30 May 95 01:52:02 PDT <199505300852.BAA26946@rx7.ee.lbl.gov> Subject: PIM configuration FAQ? >> To glue sites running cisco's PIM into the MBone, >> cisco supplies a DVMRP `stub' whose function in life is to make >> the local network numbers known to MBone & announce the stub's >> router as the best route to them. (When Dino says "DVMRP" above >> he's referring to his DVMRP stub.) This is true. >> Cisco >> provided two configuration options: 1) advertise the nets >> directly connected to the stub and 2) advertise all the nets >> known to the stub. This is not true, the interface subcommand syntax is: [no] ip dvmrp metric [] [ ] [dvmrp] Which means you can tailor what networks you send into the MBONE. It's not an all or nothing deal. : value from 0 to 32, the metric used to advertised routes. : access-list describing what networks are advertised. : indicates the routes from a specific unicast routing protocol are advertised (modulo what is indicated in the ). dvmrp: DVMRP routes. Typically DVMRP routes are propagated from one tunnel to another. However, you may want to tailor what you report on LANs. >> known to the stub. I think (2) was intended to handle the case >> of a leaf network with a single attachment to the Internet & >> with a default route aimed at that attachment point. Thus the No that wasn't the intent. The intent is to support a PIM cloud that is completely native multicast and all networks advertised were truly multicast capable and reachable. To handle single attachment points, it would be nice to do DVMRP default routing which we've supported early in 10.2 anticipating mrouted's 3.5 default capability. The command syntax is: [no] ip dvmrp default-information originate | only The cisco will always accept the DVMRP default route. The above command is only used if it should originate default and should only be used if peering with a mrouted 3.5 multicast router. >> nets it knows about are just the leaf's nets. (I said "I think" >> because I never understood the rationale for (2) and, when Dino >> first proposed it a year ago at a PIM design meeting, Deborah >> Estrin, Steve Deering and I all said it was a seriously bad & >> dangerous idea.) There is no other way to get DVMRP routers in a DVMRP cloud to accept packets from PIM sources unless this is done. Doing default routing handles most of these cases. I would encourage people to migrate to mrouted 3.5 to use this (and for a variety of other reasons too). >> Option (2) really advertises *all* the routes known locally so >> if you configure it and are not a singly-connected leaf (which >> means that you probably have to import most of the 20,000 routes >> of the Internet), your stub will inject all 20,000 of those >> routes into DVMRP/the MBone. This will crash mrouters all over >> the world. When PIM first shipped there was only a 1 character And what if someone really *needs* to import a lot of routes? We have put hooks into the cisco DVMRP implementation to do network number aggregation for those sites that have many blocks of class Cs allocated. Is it possible for mrouted 3.5 to accept CIDR routes? >> When PIM first shipped there was only a 1 character >> difference between option (1) & (2) (something like typing a 0 >> or 1 for some obscure config parameter) with no "sanity check" >> code or warning that you might be doing something dangerous. As many people already know, there are plenty of sanity checks in there now. >> wrong value and got flamed all over the planet, cisco finally >> admitted that they might have a problem and made it slightly >> more difficult to screw up the configuration. I have only seen Wrong. The problem was a simple bug. The way our access-lists work is if there is a reference to one before it is created, it assumes to permit everything. I changed this behavior in the "ip dvmrp metric" command. So, if you refer to "access-list 1" in the "ip dvmrp metric" command and haven't typed in the "access-list 1" command yet, DVMRP denys reporting anything until access list is configured. >> Right now, essentially the only way to generate the necessary >> consistency between the two views is to attach a PIM cloud to >> the MBone at a place where the unicast & multicast views of the >> world are the same. I.e., the PIM cloud has to have a single This is also the preferred method since it is more simple and efficient for people to maintain. A lot of people have rehomed their DVMRP tunnels to use less bandwidth at their site. This also helps them transition to native multicasting. >> Cisco has not been very good about >> telling customers the topological limitations of PIM (in fact, I >> heard one cisco salesman tell a customer that PIM could be used >> as a transit between two DVMRP clouds even though it's almost >> impossible to make that work). That overzealous selling could From anyone who has a clue, this is not true. We have a mailing list (multicast-support@cisco.com) where people are free to ask questions. The problem with using PIM as a transit is that the sources in the DVMRP clouds on each side need to know about each other. The unicast routing table typically has this information, but as you said Van, the topologies may not be congruent. Default routing can help this situation too. Salesman will always do what they have to to get a sale. Listening to technical information from a salesman is like ready reality in trade rags. ;-) >> impossible to make that work). That overzealous selling could >> have caused cisco PIM to be used in topologies where it won't >> work & the result is duplicates and/or black holes. You think this is new just with multicast routing. Misuse of any vendor's features is a way of life. Anyone that builds product will tell you that. >> Another worry you might have with cisco's PIM is that it doesn't >> do pruning. (This is another area where cisco has frequently >> played with words: PIM has its own from of prunes. When >> someone asks cisco "does PIM do pruning?" they say "yes", >> meaning PIM prunes, when the customer was almost certainly >> asking about MBone/mrouted prunes for which the answer is "no".) We have taken every effort to be crystal clear about this. >> played with words: PIM has its own from of prunes. When >> someone asks cisco "does PIM do pruning?" they say "yes", >> meaning PIM prunes, when the customer was almost certainly No one from cisco engineering has ever said this. >> As a final note, I should say that Steve Deering's & Bill >> Fenner's work on hierarchical DVMRP should solve all of these >> PIM problems -- it will prevent the route explosions, remove the >> topological restrictions on interconnecting PIM to the MBone, More generally stated, the hierarchical routing architecture will solve these problems (and probably introduce some too). Dino From list-mgr@ISI.EDU Tue May 30 15:24:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 22:25:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 22:25:05 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 30 May 1995 22:25:04 -0700 Received: from gratiano.parc.xerox.com ([13.2.116.55]) by alpha.xerox.com with SMTP id <14436(4)>; Tue, 30 May 1995 22:24:57 PDT Received: from localhost by gratiano.parc.xerox.com with SMTP id <177863>; Tue, 30 May 1995 22:24:53 -0700 X-Mailer: exmh version 1.6 4/21/95 To: Dino Farinacci Cc: mbone Subject: Re: PIM configuration FAQ? In-Reply-To: Your message of "Tue, 30 May 95 11:23:02 PDT." <199505301823.LAA28426@stilton.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 May 1995 22:24:46 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95May30.222453pdt.177863@gratiano.parc.xerox.com> In message <199505301823.LAA28426@stilton.cisco.com> you write: > [no] ip dvmrp default-information originate | only Oh, goody, now we can look forward to a new MBONE-spamming mechanism by misconfigured routers. > Is it possible for mrouted 3.5 to accept CIDR routes? Yes, 3.5 will accept CIDR routes. > ...A lot of people have rehomed their DVMRP tunnels > to use less bandwidth at their site. This also helps them transition to > native multicasting. But a lot of people still have tunnels on single-homed workstations. In fact, several large and important MBONE routers have only one interface... Bill From list-mgr@ISI.EDU Thu Jun 1 20:35:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 31 May 1995 17:39:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 31 May 1995 17:36:42 -0700 Received: from octavia.anu.edu.au by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 31 May 1995 17:36:34 -0700 Received: (from markus@localhost) by octavia.anu.edu.au (8.6.12/8.6.12) id KAA07211; Thu, 1 Jun 1995 10:35:38 +1000 Date: Thu, 1 Jun 1995 10:35:38 +1000 From: Markus Buchhorn Message-Id: <199506010035.KAA07211@octavia.anu.edu.au> To: CU-SEEME-L@cornell.edu, mbone Subject: Reflector patches: multicast/background and mbone ADMIT Cc: cu-seeme-bugs@cornell.edu, jdb@cisr.anu.edu.au, markus@cisr.anu.edu.au G'day all It has been commented on repeatedly here that using the reflector 3.0b3 with multicast receive/send options turned on will generate an error of the form: > recvfrom error on XXX : Socket operation on non-socket: FATAL ERROR: EXITING This happens either immediately (if run in background) or on any terminal input (if run in the foreground). If multicast is not used, only unicast, the problem does not appear. I finally tracked this down to some 'loose' code in socket.c, where it tries to suck from a pipe that isn't actually open :-( e.g. with nv_ucast turned *off* and only mcast, the above XXX can be nv_ucast_sock !! [To the source maintainers: FD_ISSET(0,p) always returns 1. In most places you've checked for this, but in several you've forgotten to ...] Save the following text (between 'cut here' lines) as 'sock.patch' in your reflector source directory, and apply with 'patch < sock.patch' to generate a new socket.c - recompile and away you go. I have it running here at the moment, in the background, and no problems so far. I also include a second patch, to reflect.c, which allows you to apply the ADMIT rules to the MBONE side of the network (unicast and multicast). This patch was developed by my colleague John Barlow (jdb@cisr.anu.edu.au). This allows us to set up a restricted list of mixed machines, either side of the reflector. Thus only those machines can join in. This won't stop multicast traffic between the other machines though, since that bypasses the reflector :-). Basically very useful in a fully unicast setup where all participants are connecting to the reflector. Save as reflect.patch and apply with 'patch < reflect.patch'. Hope these patches help some people ! Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] ------- start sock.patch ------- cut here ----------------------------- *** socket.c.ORIG Thu Jun 1 09:55:14 1995 --- socket.c Thu Jun 1 09:54:28 1995 *************** *** 50,56 **** unsigned char loop; - if (nv_ucast_port != 0){ if ((nv_ucast_sock = socket(AF_INET, SOCK_DGRAM, 0)) < 0) --- 50,55 ---- *************** *** 532,538 **** if (nv_inout_mcast.sin_addr.s_addr) FD_SET(nv_inout_mcast_sock,&readfds); - #endif if (msg_sock == 0) FD_SET(cntrl_sock, &readfds); --- 531,536 ---- *************** *** 553,559 **** cadrlen = sizeof(struct sockaddr_in); ! if (FD_ISSET(vid_sock, &readfds)) { if ((*msglen = recvfrom(vid_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) --- 551,557 ---- cadrlen = sizeof(struct sockaddr_in); ! if ((vid_sock) && (FD_ISSET(vid_sock, &readfds)) ) { if ((*msglen = recvfrom(vid_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) *************** *** 567,573 **** return(VIDEO); } ! if (FD_ISSET(nv_ucast_sock, &readfds)) { if ((*msglen = recvfrom(nv_ucast_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) --- 565,571 ---- return(VIDEO); } ! if ((nv_ucast_sock) && (FD_ISSET(nv_ucast_sock, &readfds))) { if ((*msglen = recvfrom(nv_ucast_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) *************** *** 577,589 **** my_perror("recvfrom error on nv_ucast_sock"); } if (debug) printf("packet received through nv_ucast_sock\n"); return(NV_UCAST); } ! ! if (FD_ISSET(maven_sock, &readfds)) { if ((*msglen = recvfrom(maven_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) --- 575,587 ---- my_perror("recvfrom error on nv_ucast_sock"); } + if (debug) printf("packet received through nv_ucast_sock\n"); return(NV_UCAST); } ! if ((maven_sock) && (FD_ISSET(maven_sock, &readfds)) ) { if ((*msglen = recvfrom(maven_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) *************** *** 598,604 **** return(MAVEN); } ! if (FD_ISSET(maven_cntl_sock, &readfds)) { if ((*msglen = recvfrom(maven_cntl_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) --- 596,602 ---- return(MAVEN); } ! if ((maven_cntl_sock) && (FD_ISSET(maven_cntl_sock, &readfds)) ) { if ((*msglen = recvfrom(maven_cntl_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) *************** *** 675,681 **** } ! if (FD_ISSET(vat_cntl_mcast_sock, &readfds)) { if ((*msglen = recvfrom(vat_cntl_mcast_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) --- 673,679 ---- } ! if ((vat_cntl_mcast_sock) && (FD_ISSET(vat_cntl_mcast_sock, &readfds)) ) { if ((*msglen = recvfrom(vat_cntl_mcast_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) *************** *** 726,732 **** #endif ! if (FD_ISSET(cntrl_sock, &readfds)) { if (msg_sock != 0) { --- 724,730 ---- #endif ! if ((cntrl_sock) && (FD_ISSET(cntrl_sock, &readfds)) ) { if (msg_sock != 0) { *************** *** 761,767 **** continue; } ! if (FD_ISSET(msg_sock, &readfds)) { if ((*msglen = recv(msg_sock,pkt,MAXMSG,0)) < 0) { --- 759,765 ---- continue; } ! if ((msg_sock) && (FD_ISSET(msg_sock, &readfds)) ) { if ((*msglen = recv(msg_sock,pkt,MAXMSG,0)) < 0) { --------- end sock.patch ------- cut here ------------------------ -------- start reflect.patch ---- cut here ---------------------- *** reflect.c.ORIG Thu Jun 1 09:55:03 1995 --- reflect.c Wed May 31 15:34:07 1995 *************** *** 51,57 **** struct timeval tp; struct timezone tzp; char *tmp; ! argc--; argv++; --- 51,58 ---- struct timeval tp; struct timezone tzp; char *tmp; ! int goodmbone; ! int cnt; argc--; argv++; *************** *** 137,143 **** type = receive(msg,&msglen,&csock); pkts_in++; bytes_in += msglen; - if (deny(csock)) { clnt_addr.sin_family = AF_INET; --- 138,143 ---- *************** *** 158,164 **** case NV_UCAST: case NV_MCAST: ! mbone_pkt(msg,msglen,csock,type); break; case REF1VIDEO: --- 158,177 ---- case NV_UCAST: case NV_MCAST: ! if (restrict_cnt != 0) ! { ! goodmbone=0; ! for (cnt=0; cnt; Thu, 1 Jun 1995 08:14:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 1 Jun 1995 08:13:37 -0700 Received: from mailer.psc.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 1 Jun 1995 08:13:35 -0700 Received: from zippy.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA15958; Thu, 1 Jun 1995 11:13:26 -0400 Message-Id: <9506011513.AA15958@mailer.psc.edu> To: mbone Cc: mathis@psc.edu Subject: MBone Contacts - several misc changes Date: Thu, 01 Jun 1995 11:13:21 -0400 From: "Matt Mathis" The MBone contact database at http://www.psc.edu/~mathis/contacts.html and in ftp://ftp.psc.edu/pub/mbone/contacts.txt have been updated. If you wish to receive text versions of the entire document (as a subscription) please drop me a note. Also, I will now accept URL's for providers. (But not as a substitute for other contact information.) Thanks, --MM-- From list-mgr@ISI.EDU Fri Jun 2 16:06:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 07:39:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 07:38:37 -0700 Received: from arco.na.cnr.it by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 07:38:24 -0700 Received: from cps.na.cnr.it ([140.164.14.3]) by arco.na.cnr.it (5.65c+/1.34) id AA01429; Fri, 2 Jun 1995 14:11:17 -0400 Received: by cps.na.cnr.it (4.1/SMI-4.1) id AA14427; Fri, 2 Jun 95 14:06:51 +0200 Date: Fri, 2 Jun 95 14:06:51 +0200 From: canonico@cps.na.cnr.it (Roberto Canonico) Message-Id: <9506021206.AA14427@cps.na.cnr.it> To: mbone Subject: NP FDDI SBus card & Multicast 3.5 Hi everybody, we have run the np_install script to install a NP's S-Bus FDDI card on our SPARCstation 10. The machine is running SunOS-4.1.3, with the 3.5 multicasting code installed. During the installation we replied "y" the question: "Has your system been modified to use IP MULTICAST applications [y|n]?" At the end, in the np_install.log file we got the following messages: ........... Making new vmunix ... ld: Undefined symbol _addmultiaddr _delmultiaddr *** Error code 2 make: Fatal error: Command failed for target `vmunix' ........... The vmunix produced is ok, but we can't see the other machines on the FDDI net. I'd appreciate any help to fix the problem. Thank you in advance. From list-mgr@ISI.EDU Fri Jun 2 07:50:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 08:53:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 08:50:57 -0700 Received: from mailer.jhuapl.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 08:50:56 -0700 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA10995; Fri, 2 Jun 1995 11:50:55 -0400 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA01763; Fri, 2 Jun 1995 11:50:08 -0400 Date: Fri, 2 Jun 1995 11:50:08 -0400 (EDT) From: Jim Bogard BIX Subject: quick question... To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 398 I've checked the web, etc... Are there any mirrors for zenon.inria.fr? Connectivity, at least for the moment, to France is terrible. I need ivs. SunOs 4, architecture 4m if anyone happens to have it laying around... Thanks. J-. ---- Jim Bogard JHU/APL BIX Group "This is my banjo. There are many Backbone Network Engineer like it, but this one is mine." From list-mgr@ISI.EDU Fri Jun 2 02:10:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 09:12:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 09:10:43 -0700 Received: from george.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 09:10:42 -0700 Received: (deba@localhost) by george.lbl.gov (8.6.10/8.6.5) id JAA19003 for mbone@ISI.EDU; Fri, 2 Jun 1995 09:10:42 -0700 Date: Fri, 2 Jun 1995 09:10:42 -0700 From: Deb Agarwal Message-Id: <199506021610.JAA19003@george.lbl.gov> To: mbone Subject: Problems generating sound on a sparc 20 . . . Content-Length: 718 Hi all, sorry to bother you but I have a demo in 3 hours and a weird problem just cropped up. This demo has worked in the past but now. . . . When I run vat, I can talk into the mic and the sound meter moves and my voice is transmit to the destination but I don't get a sound meter (or output) locally. When someone else sends to me, I can't hear them. I tested the speaker and mic by running the audio tool and recording something and playing it back (worked fine). I checked that all the audio controls are up and no speaker mute. I rebooted the machine . . . . I am running out of ideas. The only things I can think of haven't worked. Any ideas are much appreciated! Thanks, Deb Agarwal (DAAgarwal@lbl.gov) From list-mgr@ISI.EDU Fri Jun 2 07:37:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 09:36:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 09:36:36 -0700 Received: from svcs1.digex.net by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 09:36:34 -0700 Received: from houston_cc_smtp.hai-net.com (houston_cc_smtp.hai-net.com [204.91.94.67]) by svcs1.digex.net (8.6.12/8.6.12) with SMTP id MAA15933 for ; Fri, 2 Jun 1995 12:36:33 -0400 From: rsingleton@hai-net.com Received: from cc:Mail by houston_cc_smtp.hai-net.com id AA802122012; Fri, 02 Jun 95 12:37:28 EST Date: Fri, 02 Jun 95 12:37:28 EST Message-Id: <9505028021.AA802122012@houston_cc_smtp.hai-net.com> To: mbone Subject: Connectivity Hi everyone, I have went through the task of setting up Mbone on an SGI extreme here at my site and now I need to know what I need to do to get an Mbone feed to this machine. Can someone point me in the right direction? thx Rickie HAI Arlington, VA rsingleton@hai-net.com From list-mgr@ISI.EDU Fri Jun 2 09:50:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 10:52:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 10:52:01 -0700 Received: from Princeton.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 10:52:00 -0700 Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.118/princeton) id AA01513; Fri, 2 Jun 95 13:50:08 -0400 Received: from deepthought.Princeton.EDU by ponyexpress.princeton.edu (8.6.12/1.7/newPE) id NAA14241; Fri, 2 Jun 1995 13:50:07 -0400 Received: by deepthought.Princeton.EDU (4.1/Phoenix_Cluster_Client) id AA12083; Fri, 2 Jun 95 13:50:06 EDT Message-Id: <9506021750.AA12083@deepthought.Princeton.EDU> X-Mailer: exmh version 1.6 4/21/95 To: mbone Cc: tengi@Princeton.EDU Subject: Q: using reflect 3.0b3 to cross-connect vat & vic (or nv) X-Face: Bf#x_s+*GOjDqAJ)5qI'fpm&Y2OF`RgiD2w\&Qr7ly@(yzUB)zSw#@Bj)A"3sIEwTwdBY&} #v`i+!@m"7yGc;*@Gqk_LZW4l;q8jsoEKRHL'eC|($Jc wWNl X-Uri: http://www.Princeton.EDU/~tengi/ Mime-Version: 1.0 Content-Type: application/pgp; format=mime; x-action=signclear; x-originator=7DF9BB5D Content-Transfer-Encoding: 7bit Date: Fri, 02 Jun 1995 13:50:05 EDT From: "Christopher J. Tengi" -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii I'm sure that *somebody* has already done this, and right now it looks like *I* am re-inventing the flat tire. I am having 2 problems running reflect 3.0b3 on a SunOS 4.1.3_U1B machine (with multicast extensions). The first is that unless I run the program connected to a terminal, where I don't type anything after the program starts, it dies with a recvfrom error dealing with msg_sock. The other problem appears to be configuration oriented (I think). When I have 2 MAC CU-SeeMe users connected to the reflector, they can see and talk to each other just fine. When a Unix user fires up vat and vic, the audio works just fine, but there is no vic video on the CU-SeeMee machines, and the vic window for the CU-SeeMe reflector just stays blank, with the names of the 2 MAC users cycling through the user field. - Actually, I just figured this one out by trying nv instead of vic. nv let's me specify that I am talking to CU-SeeMe clients, and once I started sending with my screen grabber (alas, no video hardware on my SS5), I was able to see the one MAC user currently connected to the reflector. Here is the config file I am using for reflect. If anybody sees any holes in it (other than the fact that I am using 239 - that is intentional as our ISP is blocking that bidirectionally at the router), please let me know. REFMON 128.112.232.42 LOG reflect.openwire.log LOG-LIMIT 1000 MOTD Experimental CU-SeeMe Reflector for Princeton University OpenWire at deepthought.Princeton.EDU // NV-UC-PORT 424444 NV-MC-PORT 4444 NV-MC-IN 239.2.0.1 NV-MC-OUT 16 239.2.0.1 VAT-UC-PORT 423456 VAT-MC-PORT 3456 VAT-MC-IN 239.2.0.1 VAT-MC-OUT 16 239.2.0.1 VAT-CONF-ID 0 Finally, does anybody know a way to make vic work with CU-SeeMe? /Chris -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBL89PSLRsj6J9+btdAQE7HAQAnSaMO4mpg75QpfWxT/b5skv2ZhcuNaQU CE/rPEO3NPVMZPg4huX3jMtlHds+XFykawfs04tYEe19ou+8XqgQ7geVWNNwyxSS tXR7MJQhLHmAXa/TxMApWctNEIY71T08SajCF/hFZaOr2csTsPCYnV+Z5B0oJP1b 6z4pS7ZSeKI= =aaqc -----END PGP SIGNATURE----- From list-mgr@ISI.EDU Fri Jun 2 05:02:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 12:03:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 12:02:54 -0700 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 2 Jun 1995 12:02:53 -0700 Posted-Date: Fri 2 Jun 95 12:02:38 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 2 Jun 95 12:02:40 PDT Date: Fri 2 Jun 95 12:02:38 PDT From: Stephen Casner Subject: Re: Connectivity To: rsingleton@hai-net.com, MBONE Message-Id: <802119758.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9505028021.AA802122012@houston_cc_smtp.hai-net.com> Mail-System-Version: To get connected to the MBone, you should contact your network service provider (digex in your case?). If they don't know what MBone means, try to teach them and get them to set up a node. They in turn should contact the next higher level provider (maybe ANS in this case?). I know that ANS does have a couple of MBone nodes. Unfortunately, not all providers at that level do (I don't know of any nodes operated by MCI, for example). In such cases, then a tunnel should be set up to another customer of that provider who is topologically near. Finding who that would be is sometimes hard, but it is hoped that potential sites will respond to queries on this list. -- Steve ------- From list-mgr@ISI.EDU Sat Jun 3 16:20:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 3 Jun 1995 03:20:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 3 Jun 1995 03:20:21 -0700 Received: from cc.lut.fi by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 3 Jun 1995 03:20:19 -0700 Received: (from ruokonen@localhost) by cc.lut.fi (8.6.11/8.6.6/1.17.kim) id NAA17538; Sat, 3 Jun 1995 13:20:15 +0300 From: Vesa Ruokonen Message-Id: <199506031020.NAA17538@cc.lut.fi> Subject: Re: quick question... To: jimbo@aplcomm.jhuapl.edu (Jim Bogard BIX) Date: Sat, 3 Jun 1995 13:20:15 +0300 (EETDST) Cc: mbone In-Reply-To: from "Jim Bogard BIX" at Jun 2, 95 11:50:08 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 780 > I've checked the web, etc... Are there any mirrors for > zenon.inria.fr? Connectivity, at least for the moment, to France is > terrible. I need ivs. Funet has a collection of mbone tools organized by OS. In the file ftp://ftp.funet.fi/pub/networking/services/multicast/00README there are a couple other sites listed too: Some collection sites (each with their own keepers?): pick one nearest to you, don't go over oceans, if you can avoid it! ftp://munnari.oz.au/pub/mbone/ ftp://sh.wide.ad.jp/multicast/ ftp://aun.uninett.no/pub/misc/ipmulti/ ftp://ftp.funet.fi/pub/networking/services/multicast/ ftp://athene.uni-paderborn.de/mount/unix/network/multicast/ -- Vesa.Ruokonen@lut.fi From list-mgr@ISI.EDU Sat Jun 3 13:54:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 3 Jun 1995 13:57:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 3 Jun 1995 13:54:51 -0700 Received: from uni-paderborn.de (pbinfo-gw.uni-paderborn.de) by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 3 Jun 1995 13:54:50 -0700 Received: from tunix (tici@tunix.uni-paderborn.de [131.234.2.80]) by uni-paderborn.de (8.6.12/8.6.12) with SMTP id WAA21591; Sat, 3 Jun 1995 22:54:38 +0200 Date: Sat, 3 Jun 1995 22:54:34 +0200 (MET DST) From: Thomas Thissen X-Sender: tici@tunix To: Vesa Ruokonen Cc: Jim Bogard BIX , mbone Subject: Re: quick question... In-Reply-To: <199506031020.NAA17538@cc.lut.fi> Message-Id: X-Info: http://www.uni-paderborn.de/Admin/tici.html X-Line: Thomas Thissen (TiCi) X-Line: c/o University of Paderborn; FB 17; Informatik; Raum: E3.148 X-Line: Warburger Str. 100; 33095 Paderborn X-Line: Phone: +49 5251 60-3318 or 60-3322 Fax: +49 5251 60-3853 Return-Receipt-To: tici@uni-paderborn.de Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 3 Jun 1995, Vesa Ruokonen wrote: > Date: Sat, 3 Jun 1995 13:20:15 +0300 (EETDST) > From: Vesa Ruokonen > To: Jim Bogard BIX > Cc: mbone@ISI.EDU > Subject: Re: quick question... > > Funet has a collection of mbone tools organized by OS. > In the file > > ftp://ftp.funet.fi/pub/networking/services/multicast/00README > > there are a couple other sites listed too: > > Some collection sites (each with their own keepers?): > pick one nearest to you, don't go over oceans, if you can avoid it! > ftp://munnari.oz.au/pub/mbone/ > ftp://sh.wide.ad.jp/multicast/ > ftp://aun.uninett.no/pub/misc/ipmulti/ > ftp://ftp.funet.fi/pub/networking/services/multicast/ > ftp://athene.uni-paderborn.de/mount/unix/network/multicast/ ----------------------------------------------------------- The correct location here is: ftp://ftp.uni-paderborn.de/pub/unix/network/multicast It's mirrored every night from ftp.funet.fi Best regards Thomas --------------------------------------------------------------------------- Thomas Thissen, c/o Uni-GH Paderborn, FB-17/400 - E3.148, 33095 Paderborn Email: tici@uni-paderborn.de Tel: 05251/60-3318, 60-3322, FAX: 60-3853 --------------------------------------------------------------------------- Admin: FTP, WWW, IRC, MBone http://www.uni-paderborn.de/Admin/tici.html From list-mgr@ISI.EDU Mon Jun 5 19:32:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 16:33:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 16:32:18 -0700 Received: from octavia.anu.edu.au by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 16:32:16 -0700 Received: (from markus@localhost) by octavia.anu.edu.au (8.6.12/8.6.12) id JAA23430; Mon, 5 Jun 1995 09:32:07 +1000 Date: Mon, 5 Jun 1995 09:32:07 +1000 From: Markus Buchhorn Message-Id: <199506042332.JAA23430@octavia.anu.edu.au> To: tengi@Princeton.EDU Subject: Re: Q: using reflect 3.0b3 to cross-connect vat & vic (or nv) Cc: mbone > The first is > that unless I run the program connected to a terminal, where I don't type > anything after the program starts, it dies with a recvfrom error dealing with > msg_sock. I posted a patch for this just last week to the CU-SeeMe and MBONE mailing lists ... anyway - I append it below.. > > NV-UC-PORT 424444 > NV-MC-PORT 4444 > NV-MC-IN 239.2.0.1 > NV-MC-OUT 16 239.2.0.1 > > VAT-UC-PORT 423456 > VAT-MC-PORT 3456 > VAT-MC-IN 239.2.0.1 > VAT-MC-OUT 16 239.2.0.1 > VAT-CONF-ID 0 Do port numbers that large make any sense ? I presume they get folded into the 0-65535 range... ? Not sure how the reflector parser handles blank lines - it may ignore the following line. Beware of using a ; on a line by itself too - it either crashes the parser or it ignores the following line. > Finally, does anybody know a way to make vic work with CU-SeeMe? At this stage you can't directly - vic doesn't support CUSeeMe encoding. Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] save the following to sock.patch in your reflector source dir, apply with patch < sock.patch to create a new socket.c, recompile the reflector. ----------- cut here ------ *** socket.c.ORIG Thu Jun 1 09:55:14 1995 --- socket.c Thu Jun 1 09:54:28 1995 *************** *** 50,56 **** unsigned char loop; - if (nv_ucast_port != 0){ if ((nv_ucast_sock = socket(AF_INET, SOCK_DGRAM, 0)) < 0) --- 50,55 ---- *************** *** 532,538 **** if (nv_inout_mcast.sin_addr.s_addr) FD_SET(nv_inout_mcast_sock,&readfds); - #endif if (msg_sock == 0) FD_SET(cntrl_sock, &readfds); --- 531,536 ---- *************** *** 553,559 **** cadrlen = sizeof(struct sockaddr_in); ! if (FD_ISSET(vid_sock, &readfds)) { if ((*msglen = recvfrom(vid_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) --- 551,557 ---- cadrlen = sizeof(struct sockaddr_in); ! if ((vid_sock) && (FD_ISSET(vid_sock, &readfds)) ) { if ((*msglen = recvfrom(vid_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) *************** *** 567,573 **** return(VIDEO); } ! if (FD_ISSET(nv_ucast_sock, &readfds)) { if ((*msglen = recvfrom(nv_ucast_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) --- 565,571 ---- return(VIDEO); } ! if ((nv_ucast_sock) && (FD_ISSET(nv_ucast_sock, &readfds))) { if ((*msglen = recvfrom(nv_ucast_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) *************** *** 577,589 **** my_perror("recvfrom error on nv_ucast_sock"); } if (debug) printf("packet received through nv_ucast_sock\n"); return(NV_UCAST); } ! ! if (FD_ISSET(maven_sock, &readfds)) { if ((*msglen = recvfrom(maven_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) --- 575,587 ---- my_perror("recvfrom error on nv_ucast_sock"); } + if (debug) printf("packet received through nv_ucast_sock\n"); return(NV_UCAST); } ! if ((maven_sock) && (FD_ISSET(maven_sock, &readfds)) ) { if ((*msglen = recvfrom(maven_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) *************** *** 598,604 **** return(MAVEN); } ! if (FD_ISSET(maven_cntl_sock, &readfds)) { if ((*msglen = recvfrom(maven_cntl_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) --- 596,602 ---- return(MAVEN); } ! if ((maven_cntl_sock) && (FD_ISSET(maven_cntl_sock, &readfds)) ) { if ((*msglen = recvfrom(maven_cntl_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) *************** *** 675,681 **** } ! if (FD_ISSET(vat_cntl_mcast_sock, &readfds)) { if ((*msglen = recvfrom(vat_cntl_mcast_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) --- 673,679 ---- } ! if ((vat_cntl_mcast_sock) && (FD_ISSET(vat_cntl_mcast_sock, &readfds)) ) { if ((*msglen = recvfrom(vat_cntl_mcast_sock,pkt,MAXMSG,0,caddr,&cadrlen)) < 0) *************** *** 726,732 **** #endif ! if (FD_ISSET(cntrl_sock, &readfds)) { if (msg_sock != 0) { --- 724,730 ---- #endif ! if ((cntrl_sock) && (FD_ISSET(cntrl_sock, &readfds)) ) { if (msg_sock != 0) { *************** *** 761,767 **** continue; } ! if (FD_ISSET(msg_sock, &readfds)) { if ((*msglen = recv(msg_sock,pkt,MAXMSG,0)) < 0) { --- 759,765 ---- continue; } ! if ((msg_sock) && (FD_ISSET(msg_sock, &readfds)) ) { if ((*msglen = recv(msg_sock,pkt,MAXMSG,0)) < 0) { ------------------- cut here ---------- From list-mgr@ISI.EDU Mon Jun 5 19:17:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 18:18:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 18:17:58 -0700 Received: from ns1.noc.titech.ac.jp by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 18:17:55 -0700 Message-Id: <199506050117.KAA09983@ns1.noc.titech.ac.jp> Received: from noc.titech.ac.jp by ns1.noc.titech.ac.jp (8.6.12+2.4W/TM2.1-bn3.3) id KAA09983; Mon, 5 Jun 1995 10:17:51 +0900 To: mbone Subject: Re: NP FDDI SBus card & Multicast 3.5 In-Reply-To: Your message of "Fri, 2 Jun 95 14:06:51 +0200" References: <9506021206.AA14427@cps.na.cnr.it> X-Mailer: Mew beta version 0.89 on Emacs 19.28.1, Mule 2.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 05 Jun 1995 10:17:51 +0900 From: IIJIMA Akihiro > ld: Undefined symbol > _addmultiaddr > _delmultiaddr We use SunLink FDDI/S 1.0 on SunOS 4.1.3_U1. in this CD-ROM /usr/etc/bf.o is FDDI driver module. this module load into kernel /etc/rc.local -> /etc/loadable -> /dev/bf.LOAD -> modload /dev/bf.o this module bf.o use these 2 function (_addmultiaddr , _delmultiaddr) BTW, impulti3.5 provide /sys/sun4m/OBJ/if_subr.o . Sun original if_subr.o have 2 function (_addmultiaddr , _delmultiaddr) but ipmulti3.5's if_subr.o not HAVE! ipmulti3.3 package include fddi/bf.o . this driver version FDDI/S 1.0. BUT does not work ipmulti3.5 kernel. please help me HOW TO USE FDDI on ipmulti3.5_sun413. -- Network Operation Center, Tokyo Institute of Technology, Japan. IIJIMA AKIHIRO aki@noc.titech.ac.jp From list-mgr@ISI.EDU Mon Jun 5 19:47:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 18:48:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 18:48:31 -0700 Received: from peer.cc.uec.ac.jp by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 18:48:28 -0700 Received: from localhost (ikob@localhost [127.0.0.1]) by peer.cc.uec.ac.jp (8.6.12/8.6.9) with SMTP id KAA13326; Mon, 5 Jun 1995 10:47:27 +0900 Message-Id: <199506050147.KAA13326@peer.cc.uec.ac.jp> X-Authentication-Warning: peer.cc.uec.ac.jp: Host localhost didn't use HELO protocol To: aki@noc.titech.ac.jp Cc: mbone Subject: Re: NP FDDI SBus card & Multicast 3.5 Reply-To: ikob@cc.uec.ac.jp In-Reply-To: Your message of "Mon, 05 Jun 1995 10:17:51 +0900" References: <199506050117.KAA09983@ns1.noc.titech.ac.jp> X-Mailer: Mew beta version 0.89 on Emacs 19.28.7, Mule 2.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 05 Jun 1995 10:47:26 +0900 From: Katushi Kobayashi From: IIJIMA Akihiro Subject: Re: NP FDDI SBus card & Multicast 3.5 Date: Mon, 05 Jun 1995 10:17:51 +0900 > > ld: Undefined symbol > > _addmultiaddr > > _delmultiaddr > > We use SunLink FDDI/S 1.0 on SunOS 4.1.3_U1. > in this CD-ROM /usr/etc/bf.o is FDDI driver module. > this module load into kernel /etc/rc.local -> /etc/loadable -> > /dev/bf.LOAD -> modload /dev/bf.o > > this module bf.o use these 2 function (_addmultiaddr , _delmultiaddr) np_install is the installer script of SunLink FDDI/S 3.0. ^^^^^^^^^^^^^^^^^ The product 1.0 and 3.0 may not compatible on interface card. ikob@peer.cc.uec.ac.jp From list-mgr@ISI.EDU Sun Jun 4 18:34:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 19:38:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 19:37:10 -0700 Received: from Princeton.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 19:37:09 -0700 Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.118/princeton) id AA10668; Sun, 4 Jun 95 22:34:35 -0400 Received: from deepthought.Princeton.EDU by ponyexpress.princeton.edu (8.6.12/1.7/newPE) id WAA00861; Sun, 4 Jun 1995 22:34:34 -0400 Received: by deepthought.Princeton.EDU (4.1/Phoenix_Cluster_Client) id AA17652; Sun, 4 Jun 95 22:34:33 EDT Message-Id: <9506050234.AA17652@deepthought.Princeton.EDU> X-Mailer: exmh version 1.6 4/21/95 Pgp-Action: none; rfc822=off To: Markus Buchhorn Cc: tengi@Princeton.EDU, mbone Subject: Re: Q: using reflect 3.0b3 to cross-connect vat & vic (or nv) In-Reply-To: Your message of "Mon, 05 Jun 1995 09:32:07 +1000." <199506042332.JAA23430@octavia.anu.edu.au> X-Face: Bf#x_s+*GOjDqAJ)5qI'fpm&Y2OF`RgiD2w\&Qr7ly@(yzUB)zSw#@Bj)A"3sIEwTwdBY&} #v`i+!@m"7yGc;*@Gqk_LZW4l;q8jsoEKRHL'eC|($Jc wWNl X-Uri: http://www.Princeton.EDU/~tengi/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Jun 1995 22:34:32 EDT From: "Christopher J. Tengi" Thanks for the patch info. I was a few days behind in reading mailing-list mail when I sent out my message. I was quite amused at the timing when I saw that you had posted the answer to one of my questions the day before I asked it. /Chris From list-mgr@ISI.EDU Fri Jun 5 05:03:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 22:17:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 22:12:34 -0700 Received: from flop.mcom.com by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 4 Jun 1995 22:12:33 -0700 Received: (from news@localhost) by flop.mcom.com (8.6.9/8.6.9) id WAA24243; Sun, 4 Jun 1995 22:03:19 -0700 To: mbone Path: wwwww.mcom.com!dmose From: dmose@wwwww.mcom.com (Dan Mosedale) Newsgroups: mcom.list.mbone Subject: Re: Connectivity Date: 5 Jun 1995 05:03:15 GMT Organization: Netscape Communications Corporation Lines: 11 Message-Id: <3qu36j$nlb@flop.mcom.com> References: <9505028021.AA802122012@houston_cc_smtp.hai-net.com> <802119758.0.CASNER@XFR.ISI.EDU> Nntp-Posting-Host: wwwww.mcom.com CASNER@ISI.EDU (Stephen Casner) writes: > Unfortunately, not all providers at that level do (I don't know of > any nodes operated by MCI, for example). For what it's worth, I asked about this recently, and MCI said that they have had a bunch of requests for MBONE feeds and that they are working on something (but have nothing available at the moment). -- Dan Mosedale Systems Exorcist dmose@netscape.com Netscape Communications Corp. From list-mgr@ISI.EDU Mon Jun 5 11:21:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 13:02:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 13:02:29 -0700 Received: from and.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 13:02:28 -0700 Received: (dschluss@localhost) by and.engin.umich.edu (8.6.12/8.6.4) id QAA21567; Mon, 5 Jun 1995 16:02:14 -0400 Date: Mon, 5 Jun 1995 15:21:13 -0400 (EDT) From: "david a. schlussel" Subject: cu-seeme and the Mbone To: CU-SEEME , mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm trying to find a way to rebroadcast mbone sessions over our cu-seeme reflector. Most of our machines are PC's or macs. I have found a high level cluge for sending the video, simply grabbing a fixed area of the screen showing the video. Not too fancy, but it works. Would anyone else who as done any work in this area kindly contact me. +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ From list-mgr@ISI.EDU Mon Jun 5 12:41:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 13:41:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 13:40:50 -0700 Received: from clark.dgim.doc.ca by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 13:40:48 -0700 Received: from info.ic.gc.ca by clark.dgim.doc.ca (4.1/SMI-4.1.tee) id AA05282; Mon, 5 Jun 95 16:40:36 EDT Received: by info.ic.gc.ca (4.1/SMI-4.1) id AA13322; Mon, 5 Jun 95 16:41:27 EDT Date: Mon, 5 Jun 1995 16:41:27 -0400 (EDT) From: "William F. Maton" To: "david a. schlussel" Cc: CU-SEEME , mbone Subject: Re: cu-seeme and the Mbone In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 5 Jun 1995, david a. schlussel wrote: > I'm trying to find a way to rebroadcast mbone sessions over > our cu-seeme reflector. Most of our machines are PC's > or macs. > Well, for the Net95 conference here in Ottawa, we are planning an m-bone broadcast and a re-broadcast through CUSEEME to participants locally on PCs. Any more light on this would be nice too..... William F. Maton From list-mgr@ISI.EDU Mon Jun 5 14:35:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 15:35:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 15:35:18 -0700 Received: from overdrive.ccrl.nj.nec.com (overdrive3.ccrl.nj.nec.com) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 15:35:17 -0700 Received: by overdrive.ccrl.nj.nec.com (4.1/YDL1.9-920708.13) id AA23497(overdrive.ccrl.nj.nec.com); Mon, 5 Jun 95 18:35:08 EDT From: bansal@ccrl.nj.nec.com (Vivek Bansal) Received: by depot (4.1/CNC-Client) id AA10079; Mon, 5 Jun 95 18:35:07 EDT Date: Mon, 5 Jun 95 18:35:07 EDT Message-Id: <9506052235.AA10079@depot> To: mbone, rem-conf@es.net, van@ee.lbl.gov Subject: CellB decoder... We are looking for a software decoder for a video stream which has been encoded using Sun's cellB video format. Is it possible to use vic to take a cellb encoded file and display it ?? or is there any other tool to do that ??? Thanks Vivek.. From list-mgr@ISI.EDU Tue Jun 6 18:46:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 15:47:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 15:46:34 -0700 Received: from octavia.anu.edu.au by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 15:46:31 -0700 Received: (from markus@localhost) by octavia.anu.edu.au (8.6.12/8.6.12) id IAA14596 for mbone@isi.edu; Tue, 6 Jun 1995 08:46:29 +1000 Date: Tue, 6 Jun 1995 08:46:29 +1000 From: Markus Buchhorn Message-Id: <199506052246.IAA14596@octavia.anu.edu.au> To: mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications This just wandered across the CUSeeMe mailing list.... --------- Received message begins Here --------- > From owner-CU-SEEME-L@cornell.edu Tue Jun 6 04:17:40 1995 > Date: Mon, 5 Jun 1995 19:45:40 +0200 > From: Luk.VandeHeyning@ping.be (Luk Van de Heyning) > To: > Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications > > Hi all, > > remember me causing a 'black out" over here in Europe, just by using CuSeeme? > > > Here's a transcript from a message I just received from my Provider. > > I think it is of interest to all CuSeeme-users... > > > >>> > >>> Damaging Video / Voice Traffic on the Internet > >>> ---------------------------------------------- > >>> > >>> Eg: Cu-SeeMe and similar applications > >>> > >>> Summary: > >>> > >>> There are a number of Software and Hardware products > >>> that allow a variety of Audio and Video applications > >>> between LAN's over TCP/IP and therefore to run on > >>> Internet links. > >>> > >>> These applications, due to their unique requirements > >>> for a constant and high traffic stream, do not use the > >>> normal management layers of the Internet Protocol i.e TCP, > >>> and therefore have a very detrimental effect on other > >>> traffic - they are able to totally 'hog' links, no > >>> matter how large the link size. > >>> > >>> This has a very disruptive effect on the network > >>> performance as seen by other users, and can upset > >>> networks at any or many links worldwide between the two or > >>> more communicating application end-users. > >>> > >>> Internet Providers worldwide are concerned at the > >>> danger from indiscriminate use of these applications, > >>> and EUnet, like many others, will apply it's Terms > >>> and Conditions to prevent service impairment to it's > >>> networks and to those of other providers worldwide, > >>> in order to maintain a good service to all users. > >>> > >>> User Organisations must therefore make written requests to > >>> EUnet, and receive written confirmation that EUnet will allow > >>> such usage, in advance of using such Video / Audio > >>> applications across the Internet. > >>> > >>> Acknowledgement required > >>> ------------------------ > >>> > >>> This situation is being taken very seriously in the context > >>> of maintaining an effective Internet service to users, and > >>> EUnet will require a written (email or other) acknowldedgement > >>> from all User Organisations that this message has been received and > >>> understood. > >>> > >>> Technical > >>> --------- > >>> > >>> Technically, it is UDP being transmitted in real > >>> time, large volume. This violates the fundamental > >>> design of the Internet, which is largely based on > >>> TCP (advanced, highly adaptive, robust, flow control) > >>> for high volume), and UDP (simple, crude, unreliable, > >>> no flow control) for single, occasional datagrams. > >>> > >>> Applications that need high volume, real time traffic > >>> currently have no option other than to use UDP. > >>> > >>> But the result can be, and usually is, devastating > >>> for TCP-based traffic. When a TCP connection detects > >>> packet loss, it immediately backs off. In the presence > >>> of high volume UDP traffic, the ensuing packet loss will > >>> cause TCP connections to slow down to a crawl. > >>> > >>> In brief, when TCP traffic is high on a link, all > >>> connections 'back-off' thus sharing equally the available > >>> bandwidth. UDP however, does not back-off in this controlled > >>> manner but will take all available bandwidth. > >>> > >>> These video/voice applications are new, 'exciting' and > >>> work fine on high bandwidth Local Area Networks or > >>> specialist high bandwidth Wide Area Networks such as JANET, > >>> where 34 MBits government financed links exist. > >>> > >>> The Worldwide InterNet, however, has a wide variety > >>> of links scaled to a capacity to handle well behaved TCP/IP > >>> traffic, but Audio and Video applications should not be used > >>> without permission from your Internet provider. > >>> > >>> Terms and Conditions > >>> -------------------- > >>> > >>> It is in all our interest of both Internet Customers > >>> and Internet Providers worldwide that this policy is strictly > >>> observed, so that *all* users have the best possible service. > >>> > >>> EUnet's Terms and Conditions state: > >>> > >>> Section 4 para 4 > >>> > >>> "Unless otherwise agreed in a service agreement, > >>> EUnet provides international bandwidth on an as-available > >>> basis, and User Organisation's bandwidth and other resource > >>> consumption must be commensurate with the type of service > >>> taken" > >>> > >>> It is apparent even from the pricing of Internet services worldwide, > >>> that users paying a fixed annual fee for eg a modem access, will > >>> at best slowly bankrupt Internet providers if they take full modem speed > >>> constant international bandwidth when connected. At worst they > >>> will cause Providers networks to very quickly become unusable > >>> by most users. > >>> > >>> Section 5 > >>> > >>> "The User Organisation is assumed to be competent in making and > >>> maintaining an Internet connection, including where applicable > >>> Internet/ IP/ DNS/ system administration. > >>> > >>> "Where such administration is inadequate to prevent damaging traffic > >>> or effects on the EUnet network or external Internet, EUnet reserves the > >>> right to unilaterally apply packet filtering/ blocking and other menas to > >>> limit such damage or effects. > >>> > >>> "The User Organisation is liable for all expenses incurred by EUnet as a > >>> result of neglect, incompetenmce, wilful malice or other inappropraite > >>> behaviour or Internet/ IP/ DNS/ system administration on the User > >>> Organisations part, including but not limited to legal fees, technical fees > >>> and loss of income. > >>> > >>> In this context EUnet, in line with other providers, > >>> ask that written permission is obtained *prior* to use > >>> of these Video / Audio services. > >>> > >>> Other UDP applications > >>> ---------------------- > >>> > >>> The above policy has been codified because we want to ensure that CuSeeMe > >>> and similar applications do not adversely affect the Internet. However > >>> there are other `non-dangerous' UDP applications, so if you are running > >>> or likely to run such applications please advise us both of the nature of > >>> these and of the ports used. This will help us to control damaging traffic > >>> while hopefully not harming `non-dangerous traffic'. > >>> > >>> Peter Houlder > >>> > >>> Technical Director - 3rd March 1995 > > > > > > > > > Greatings / groetjes > > Luk Van de Heyning > > (-: PhD Internet-Addictions :-) > > mailto:Luk.VandeHeyning@ping.be > Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] From list-mgr@ISI.EDU Tue Jun 6 18:50:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 15:51:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 15:51:13 -0700 Received: from mail.mel.aone.net.au by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 15:51:11 -0700 Received: from ipx.office.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by mail.mel.aone.net.au (8.6.11/8.6.11) with ESMTP id IAA20830; Tue, 6 Jun 1995 08:51:08 +1000 Received: from ipx.office.bne.aone.net.au (ggm@ipx.office.bne.aone.net.au [203.12.179.65]) by ipx.office.bne.aone.net.au (8.6.11/8.6.12) with ESMTP id IAA05247; Tue, 6 Jun 1995 08:50:52 +1000 To: Markus Buchhorn Cc: mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 1995 08:46:29 +1000." <199506052246.IAA14596@octavia.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <5241.802392651.1@ipx.office.bne.aone.net.au> Date: Tue, 06 Jun 1995 08:50:51 +1000 Message-Id: <5243.802392651@ipx.office.bne.aone.net.au> From: George Michaelson Looks to me like the .AU policy of gluing together CuSeeMe cells with MBONE is more and more plausible. That, or IDONP (news at 01.00 GMT) -George From list-mgr@ISI.EDU Fri Jun 5 09:16:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 17:41:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 17:36:18 -0700 Received: from ocate.edu (oregon.ocate.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 17:36:16 -0700 Received: from ocatemail.ocate.edu by ocate.edu (4.1/SMI-4.1) id AA01711; Mon, 5 Jun 95 17:40:13 PDT Message-Id: <9506060040.AA01711@ocate.edu> Date: 5 Jun 1995 17:16:44 -0800 From: "Danm" Subject: 2 cents To: "George Michaelson" , "Markus Buchhorn" Cc: mbone Hi, [my 2 cents] Although mbone is great it has been limited to sun's and related equipment. The masses are looking for a way to receive mbone on a platform that is both cost effective and somewhat user friendly on the operating system level. [The number of unix guru's is limited.] Products like cuseeme allow for a more common spirit on the internet with interaction between all platforms on a common product, if not a common platform. The future is inoperability on the grand scale, world wide. We are currently at the point where that interoperability is bursting on the scene and it is exciting to see the differences in the internet that have transpired in just the last few months because of it. Though the rebuild of the infrastructure is underway, we can now see that the demands on the net are growing incredibly fast, and that newer and faster resources need development to keep pace with user growth and participation. dan _______________________________________________________________________________ From: George Michaelson on Mon, Jun 05, 1995 5:02 PM Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications To: Markus Buchhorn Cc: mbone@ISI.EDU Looks to me like the .AU policy of gluing together CuSeeMe cells with MBONE is more and more plausible. That, or IDONP (news at 01.00 GMT) -George ------------------ RFC822 Header Follows ------------------ Received: by ocatemail.ocate.edu with SMTP;5 Jun 1995 17:02:39 -0800 Received: from norman.nwnet.net by ocate.edu (4.1/SMI-4.1) id AA01704; Mon, 5 Jun 95 17:04:59 PDT Errors-To: owner-mbone@nwnet.net Received: by norman.nwnet.net (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA11569; Mon, 5 Jun 95 16:59:49 -0700 Errors-To: owner-mbone@nwnet.net Sender: owner-mbone@nwnet.net Return-Path: Received: from venera.isi.edu by norman.nwnet.net (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA11563; Mon, 5 Jun 95 16:59:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 15:51:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 15:51:13 -0700 Received: from mail.mel.aone.net.au by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 5 Jun 1995 15:51:11 -0700 Received: from ipx.office.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by mail.mel.aone.net.au (8.6.11/8.6.11) with ESMTP id IAA20830; Tue, 6 Jun 1995 08:51:08 +1000 Received: from ipx.office.bne.aone.net.au (ggm@ipx.office.bne.aone.net.au [203.12.179.65]) by ipx.office.bne.aone.net.au (8.6.11/8.6.12) with ESMTP id IAA05247; Tue, 6 Jun 1995 08:50:52 +1000 To: Markus Buchhorn Cc: mbone@ISI.EDU Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 1995 08:46:29 +1000." <199506052246.IAA14596@octavia.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <5241.802392651.1@ipx.office.bne.aone.net.au> Date: Tue, 06 Jun 1995 08:50:51 +1000 Message-Id: <5243.802392651@ipx.office.bne.aone.net.au> From: George Michaelson From list-mgr@ISI.EDU Tue Jun 6 00:02:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 00:03:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 00:02:47 -0700 Received: from ns.riken.go.jp by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 00:02:45 -0700 Received: from RIKAX1.riken.go.jp by ns.riken.go.jp (8.6.8.1/TISN-1.3M/R2) id QAA00431; Tue, 6 Jun 1995 16:02:40 +0900 Received: by rikax1.riken.go.jp (MX V4.1 AXP) id 3; Tue, 06 Jun 1995 16:01:15 JST Date: Tue, 06 Jun 1995 16:01:14 JST From: "Takashi Ichihara " To: mbone Message-Id: <009917AF.373B6478.3@rikax1.riken.go.jp> Subject: Mbone link between USA and Japan problem Hello Folks The mbone link between USA (mbone.nsi.nasa.gov: 192.203.230.241) and Japan (fasthand.sfc.wide.ad.jp: 133.4.11.23) seems to be out of order for couple of days. The link status shown by the "mrionfo" for both side seems to be different, as shown below. Anyway, the link is not working for several days. Could anyone fix this problem ? Thank you in advance. (at Japan side) > # mrinfo 133.4.11.23 > 133.4.11.23 (fasthand.sfc.wide.ad.jp) [version 3.3]: > 133.4.11.23 -> 0.0.0.0 (local) [1/1/querier] > 133.4.11.23 -> 192.203.230.241 (mbone.nsi.nasa.gov) [1/96/tunnel/down] <-- (at USA side) > # mrinfo 192.203.230.241 > 192.203.230.241 (mbone.nsi.nasa.gov) [version 3.4]: > 192.203.230.241 -> 0.0.0.0 (local) [1/1/disabled] > : > 192.203.230.241 -> 133.4.11.23 (133.4.11.23) [1/64/tunnel] <- up ??? ---------------------------------------------------------------------- Takashi Ichihara Radiation lab/Accelerator Research Facility RIKEN (The Institute of Physical and Chemical Research) 2-1, Hirosawa, Wako, 351-01, Japan (Internet) Ichihara@rikvax.riken.go.jp (HEPnet/span) RIKEN::ICHIHARA (41910::Ichihara) From list-mgr@ISI.EDU Tue Jun 6 09:46:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 00:52:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 00:47:52 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 00:47:51 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 6 Jun 1995 00:47:46 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Jun 1995 08:46:38 +0100 To: Markus Buchhorn Cc: mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 95 08:46:29 +0900." <199506052246.IAA14596@octavia.anu.edu.au> Date: Tue, 06 Jun 95 08:46:32 +0100 Message-Id: <504.802424792@cs.ucl.ac.uk> From: Jon Crowcroft >This just wandered across the CUSeeMe mailing list.... the message below is ill informed since Cu-SeeMe and other tools are either constant rate (approximately) or adaptive to network conditions just as TCP is the provider below (i'm not going to name them, but they are a UK provider who underprovisions their backbone) would have you ban DNS and SNMP by their arguments (actually, TCP based DNS and SNMP might not be a nbad idea, but thats another story) they are threatening their subscribers with this, and they are WRONG - their subscreibers (I know one group is) wil lmove to other providers who have properly provisoned backbones... tyhe problem they allude to is simply one that requires either a decent backbone, or without one the advent of RSVP....or else a POP architecture (e.g. the BT and Pipex Internet services both have) that protects the net... what they are doing is like saying "you';ve paid your roasd tax, but you can't go so often on the road as we said..." its just plain wrong.... >--------- Received message begins Here --------- > >> From owner-CU-SEEME-L@cornell.edu Tue Jun 6 04:17:40 1995 >> Date: Mon, 5 Jun 1995 19:45:40 +0200 >> From: Luk.VandeHeyning@ping.be (Luk Van de Heyning) >> To: >> Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications >> >> Hi all, >> >> remember me causing a 'black out" over here in Europe, just by using CuSeeme? >> >> >> Here's a transcript from a message I just received from my Provider. >> >> I think it is of interest to all CuSeeme-users... >> >> >> >>> >> >>> Damaging Video / Voice Traffic on the Internet >> >>> ---------------------------------------------- >> >>> >> >>> Eg: Cu-SeeMe and similar applications >> >>> >> >>> Summary: >> >>> >> >>> There are a number of Software and Hardware products >> >>> that allow a variety of Audio and Video applications >> >>> between LAN's over TCP/IP and therefore to run on >> >>> Internet links. >> >>> >> >>> These applications, due to their unique requirements >> >>> for a constant and high traffic stream, do not use the >> >>> normal management layers of the Internet Protocol i.e TCP, >> >>> and therefore have a very detrimental effect on other >> >>> traffic - they are able to totally 'hog' links, no >> >>> matter how large the link size. >> >>> >> >>> This has a very disruptive effect on the network >> >>> performance as seen by other users, and can upset >> >>> networks at any or many links worldwide between the two or >> >>> more communicating application end-users. >> >>> >> >>> Internet Providers worldwide are concerned at the >> >>> danger from indiscriminate use of these applications, >> >>> and EUnet, like many others, will apply it's Terms >> >>> and Conditions to prevent service impairment to it's >> >>> networks and to those of other providers worldwide, >> >>> in order to maintain a good service to all users. >> >>> >> >>> User Organisations must therefore make written requests to >> >>> EUnet, and receive written confirmation that EUnet will allow >> >>> such usage, in advance of using such Video / Audio >> >>> applications across the Internet. >> >>> >> >>> Acknowledgement required >> >>> ------------------------ >> >>> >> >>> This situation is being taken very seriously in the context >> >>> of maintaining an effective Internet service to users, and >> >>> EUnet will require a written (email or other) acknowldedgement >> >>> from all User Organisations that this message has been received and >> >>> understood. >> >>> >> >>> Technical >> >>> --------- >> >>> >> >>> Technically, it is UDP being transmitted in real >> >>> time, large volume. This violates the fundamental >> >>> design of the Internet, which is largely based on >> >>> TCP (advanced, highly adaptive, robust, flow control) >> >>> for high volume), and UDP (simple, crude, unreliable, >> >>> no flow control) for single, occasional datagrams. >> >>> >> >>> Applications that need high volume, real time traffic >> >>> currently have no option other than to use UDP. >> >>> >> >>> But the result can be, and usually is, devastating >> >>> for TCP-based traffic. When a TCP connection detects >> >>> packet loss, it immediately backs off. In the presence >> >>> of high volume UDP traffic, the ensuing packet loss will >> >>> cause TCP connections to slow down to a crawl. >> >>> >> >>> In brief, when TCP traffic is high on a link, all >> >>> connections 'back-off' thus sharing equally the available >> >>> bandwidth. UDP however, does not back-off in this controlled >> >>> manner but will take all available bandwidth. >> >>> >> >>> These video/voice applications are new, 'exciting' and >> >>> work fine on high bandwidth Local Area Networks or >> >>> specialist high bandwidth Wide Area Networks such as JANET, >> >>> where 34 MBits government financed links exist. >> >>> >> >>> The Worldwide InterNet, however, has a wide variety >> >>> of links scaled to a capacity to handle well behaved TCP/IP >> >>> traffic, but Audio and Video applications should not be used >> >>> without permission from your Internet provider. >> >>> >> >>> Terms and Conditions >> >>> -------------------- >> >>> >> >>> It is in all our interest of both Internet Customers >> >>> and Internet Providers worldwide that this policy is strictly >> >>> observed, so that *all* users have the best possible service. >> >>> >> >>> EUnet's Terms and Conditions state: >> >>> >> >>> Section 4 para 4 >> >>> >> >>> "Unless otherwise agreed in a service agreement, >> >>> EUnet provides international bandwidth on an as-available >> >>> basis, and User Organisation's bandwidth and other resource >> >>> consumption must be commensurate with the type of service >> >>> taken" >> >>> >> >>> It is apparent even from the pricing of Internet services worldwide, >> >>> that users paying a fixed annual fee for eg a modem access, will >> >>> at best slowly bankrupt Internet providers if they take full modem speed >> >>> constant international bandwidth when connected. At worst they >> >>> will cause Providers networks to very quickly become unusable >> >>> by most users. >> >>> >> >>> Section 5 >> >>> >> >>> "The User Organisation is assumed to be competent in making and >> >>> maintaining an Internet connection, including where applicable >> >>> Internet/ IP/ DNS/ system administration. >> >>> >> >>> "Where such administration is inadequate to prevent damaging traffic >> >>> or effects on the EUnet network or external Internet, EUnet reserves the >> >>> right to unilaterally apply packet filtering/ blocking and other menas to >> >>> limit such damage or effects. >> >>> >> >>> "The User Organisation is liable for all expenses incurred by EUnet as a >> >>> result of neglect, incompetenmce, wilful malice or other inappropraite >> >>> behaviour or Internet/ IP/ DNS/ system administration on the User >> >>> Organisations part, including but not limited to legal fees, technical fees >> >>> and loss of income. >> >>> >> >>> In this context EUnet, in line with other providers, >> >>> ask that written permission is obtained *prior* to use >> >>> of these Video / Audio services. >> >>> >> >>> Other UDP applications >> >>> ---------------------- >> >>> >> >>> The above policy has been codified because we want to ensure that CuSeeMe >> >>> and similar applications do not adversely affect the Internet. However >> >>> there are other `non-dangerous' UDP applications, so if you are running >> >>> or likely to run such applications please advise us both of the nature of >> >>> these and of the ports used. This will help us to control damaging traffic >> >>> while hopefully not harming `non-dangerous traffic'. >> >>> >> >>> Peter Houlder >> >>> >> >>> Technical Director - 3rd March 1995 >> > >> > >> > >> >> >> Greatings / groetjes >> >> Luk Van de Heyning >> >> (-: PhD Internet-Addictions :-) >> >> mailto:Luk.VandeHeyning@ping.be >> > >Markus Buchhorn, Parallel Computing Research Facility >email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU >Australian National University, Canberra, 0200 , Australia. >[International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] jon From list-mgr@ISI.EDU Tue Jun 6 02:27:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 02:28:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 02:28:00 -0700 Received: from mailhost.lut.ac.uk (bgate.lut.ac.uk) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 02:27:58 -0700 Received: by hpd.lut.ac.uk (15.11/SMI-4.1) id AA14947; Tue, 6 Jun 95 10:06:54 bst Message-Id: <9506060906.AA14947@hpd.lut.ac.uk> From: Ben Anderson Subject: Re: cu-seeme and the Mbone To: will@info.ic.gc.ca (William F. Maton) Date: Tue, 6 Jun 95 10:06:52 BST Cc: dschluss@engin.umich.edu, CU-SEEME-L@cornell.edu, mbone In-Reply-To: ; from "William F. Maton" at Jun 5, 95 4:41 pm X-Mailer: ELM [version 2.3 PL0 (LUT)] > > On Mon, 5 Jun 1995, david a. schlussel wrote: > > > I'm trying to find a way to rebroadcast mbone sessions over > > our cu-seeme reflector. Most of our machines are PC's > > or macs. > > > > Well, for the Net95 conference here in Ottawa, we are planning an m-bone > broadcast and a re-broadcast through CUSEEME to participants locally on > PCs. Any more light on this would be nice too..... > > William F. Maton > The latest version (3.01 ?) of Cornell University's CU-SeeMe reflector will 'listen' for packets (audio and video) on a specified multicast address and then reflect them in a unicast manner to any connected CU-SeeMe clients. So it does exactly what you both want. It's all in the reflector README. Of course you may want to ensure that _only_ local CU-SeeMe users connect to the reflector... Ben -- Please read my signature. From list-mgr@ISI.EDU Tue Jun 6 13:48:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 02:54:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 02:49:07 -0700 Received: from pobox.cscs.ch ([148.187.10.13]) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 02:48:58 -0700 Received: from cscs.ch by pobox.cscs.ch with SMTP inbound id <15972-0@pobox.cscs.ch>; Tue, 6 Jun 1995 11:48:49 +0200 Received: from monte (monte [148.187.160.20]) by piora-ether.cscs.ch (8.6.10/8.6.10) with SMTP id LAA10054; Tue, 6 Jun 1995 11:48:45 +0200 From: Stefano Klett Received: by monte (5.x) id AA03992; Tue, 6 Jun 1995 11:48:44 +0200 Date: Tue, 6 Jun 1995 11:48:44 +0200 Message-Id: <9506060948.AA03992@monte> To: mbone Subject: Mrouted 3.5 core dump with phyint disable Cc: sklett@cscs.ch X-Sun-Charset: US-ASCII Hi, I install Mrouted 3.5 on SUN-LX with SunOS Release 4.1.4. If I disable the local phyint then Mrouted will produce core dump. ------------------------------------------------------------------------------- /etc/mrouted.conf: pruning on phyint 130.59.159.10 disable tunnel 130.59.159.10 130.59.8.1 metric 1 threshold 64 rate_limit 500 tunnel 130.59.159.10 148.187.160.20 metric 1 threshold 64 rate_limit 500 ------------------------------------------------------------------------------- # /usr/local/etc/mrouted -d debug level 2 11:29:16.749 mrouted version 3.5 11:29:16.817 Getting vifs from kernel interfaces 11:29:16.820 installing le0 (130.59.159.10 on subnet 130.59.159/24) as vif #0 - rate=0 11:29:16.822 Getting vifs from /etc/mrouted.conf 11:29:16.829 installing tunnel from 130.59.159.10 to 130.59.8.1 as vif #1 - rate=500 11:29:16.834 installing tunnel from 130.59.159.10 to 148.187.160.20 as vif #2 - rate=500 11:29:16.837 warning - no enabled interfaces, forwarding via tunnels only 11:29:16.841 Installing vifs in kernel... 11:29:16.843 vif #1, tunnel 130.59.159.10 -> 130.59.8.1 11:29:16.847 vif #2, tunnel 130.59.159.10 -> 148.187.160.20 pruning on vifs_with_neighbors = 0 Virtual Interface Table Vif Name Local-Address M Thr Rate Flags 0 le0 130.59.159.10 subnet: 130.59.159/24 1 1 0 disabled pkts in : 0 pkts out: 0 1 le0 130.59.159.10 tunnel: 130.59.8.1 1 64 500 pkts in : 0 pkts out: 0 2 le0 130.59.159.10 tunnel: 148.187.160.20 1 64 500 pkts in : 0 pkts out: 0 Multicast Routing Table (0 entries) Origin-Subnet From-Gateway Metric Tmr In-Vif Out-Vifs Segmentation fault (core dumped) ------------------------------------------------------------------------------- The same configuration without the following line will work: #phyint 130.59.159.10 disable Do you have any Idea? Regards Stefano ___ (' ') ---------------------------oOO--(_)--OOo------------------------------------ Stefano Klett phone: +41 91 50 82 15 CSCS (Centro Svizzero di Calcolo Scientifico) fax: +41 91 50 67 11 Via Cantonale e-mail: sklett@cscs.ch CH-6928 Manno (Switzerland) X.400: S=sklett O=cscs P=switch A=arcom C=ch URL: http://www.cscs.ch/ ---------------------------------------------------------------------------- From list-mgr@ISI.EDU Tue Jun 6 14:30:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 03:31:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 03:30:34 -0700 Received: from ncc.ripe.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 03:30:32 -0700 Received: from reif.ripe.net by ncc.ripe.net with SMTP id AA02007 (5.65a/NCC-2.23); Tue, 6 Jun 1995 12:30:21 +0200 Message-Id: <9506061030.AA02007@ncc.ripe.net> To: Jon Crowcroft Cc: mbone Subject: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of Tue, 06 Jun 1995 08:46:32 BST. <504.802424792@cs.ucl.ac.uk> References: <504.802424792@cs.ucl.ac.uk> From: Daniel Karrenberg X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Date: Tue, 06 Jun 1995 12:30:20 +0200 Sender: Daniel.Karrenberg@ripe.net > Jon Crowcroft writes: > > the message below is ill informed since Cu-SeeMe and other tools are > either constant rate (approximately) Unfortunately it is not ill informed. Being 'constant rate' does not solve the problem of no back-off. All TCP connections using a link will back off if 'constant rate' UDP packets cause drops. The 'constant rate' application will not back off. It is 'constant rate', right? This is even worse, since many such applications do not even require a receiver to be active anywhere. This is a consequence of the Internet architecture which assumes cooperating hosts and little policing by the network, as opposed to PTO type architectures like X.25 which assume the opposite. A couple of non cooperating applications can easily render low bandwidth links unusable. Such links exist in the Internet for economical reasons and in some areas simply because nothing better exists. You do not have to go far from the UK to get into places where provisioning a 128kbit/s circuit is not just expensive, but impossible! > or adaptive to network conditions just as TCP is Please enlighten me about nv, vat, CuSeeMe... basically anything A/V and designed to run over multicast. Which of these is adaptive? > the provider below (i'm not going to name them, but they are a UK > provider who underprovisions their backbone) Aren't we a bit hypocritical here since their name is all over the included message as well as the subject. Without knowing what caused it I personally think the quoted message is a little overdone but it certainly addresses a problem. Burying your head in the sand and/or shouting "provision bigger infrastructure" is not going to solve the problem. Makeing the applications adaptive to the network layer is. Daniel From list-mgr@ISI.EDU Tue Jun 6 12:47:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 03:56:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 03:51:07 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 03:51:06 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 6 Jun 1995 03:51:02 -0700 Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Jun 1995 11:47:29 +0100 To: Daniel Karrenberg Cc: mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 95 12:30:20 +0100." <9506061030.AA02007@ncc.ripe.net> Date: Tue, 06 Jun 95 11:47:24 +0100 Message-Id: <1696.802435644@cs.ucl.ac.uk> From: Jon Crowcroft > > > Jon Crowcroft writes: > > > > the message below is ill informed since Cu-SeeMe and other tools are > > either constant rate (approximately) > >Unfortunately it is not ill informed. Being 'constant rate' does not >solve the problem of no back-off. All TCP connections using a link will >back off if 'constant rate' UDP packets cause drops. The 'constant >rate' application will not back off. It is 'constant rate', right? >This is even worse, since many such applications do not even require >a receiver to be active anywhere. this is a misunderstanding - for example, TCP does not have infinite backoff - the minumum rate for TCP with a controlled feedback loop is 1 packet per round trip time currently, the UK-US link has so many connections at any one time that not even Van's stuff can help - none of them can get to the point where ack and loss clocking works, so we suffer....would the Internet Provider's rulew this out bby some TCP connection counting and addmissio ncontrol? i think not... >This is a consequence of the Internet architecture which assumes >cooperating hosts and little policing by the network, as opposed >to PTO type architectures like X.25 which assume the opposite. sorry, i disagree - this is a post-hoc definition of the Internet Architecture... provided adequate bandwidth, a mix of adapative (e.g. exponential backoff and linear increase) and cosntant rate conenctions can co-exist perfectly safely... >A couple of non cooperating applications can easily render low >bandwidth links unusable. Such links exist in the Internet for >economical reasons and in some areas simply because nothing better >exists. You do not have to go far from the UK to get into places >where provisioning a 128kbit/s circuit is not just expensive, but >impossible! sure - but this is not to do with the model - it is to do with provisioning... > > or adaptive to network conditions just as TCP is >Please enlighten me about nv, vat, CuSeeMe... basically anything >A/V and designed to run over multicast. Which of these >is adaptive? IVS. see sigcomm last year. (and CuSeeMe > > the provider below (i'm not going to name them, but they are a UK > > provider who underprovisions their backbone) >Aren't we a bit hypocritical here since their name is all over the >included message as well as the subject. oh - ok - sorry - i didn't spot that.... >Without knowing what caused it I personally think the quoted message >is a little overdone but it certainly addresses a problem. Burying >your head in the sand and/or shouting "provision bigger infrastructure" >is not going to solve the problem. >Makeing the applications adaptive to the network layer is. now this i can totally agree with! in extremis, though, you have to have a bare minimum bandwodtyh - e.g. for voice, below LPC4 (say approx 10kbps) is unusalble - for TCP, as i've said, below 1 packet per RTT is tricky (not impossible, but tricky) so you need some sort of idea of a minimum provision for expected number of users..... above that, adaption, and fair share adaption, is a good thing.... jon From list-mgr@ISI.EDU Tue Jun 6 15:01:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:02:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:01:51 -0700 Received: from eunet.EU.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:01:41 -0700 Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id NAA07805; Tue, 6 Jun 1995 13:01:39 +0200 Received: by jotun.EU.net id AA05378 (5.67a/IDA-1.5); Tue, 6 Jun 1995 13:01:37 +0200 Message-Id: <199506061101.AA05378@jotun.EU.net> From: Per Gregers Bilse Date: Tue, 6 Jun 1995 13:01:37 +0200 In-Reply-To: <504.802424792@cs.ucl.ac.uk> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Jon Crowcroft Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone On Jun 6, 8:46, Jon Crowcroft wrote: > >This just wandered across the CUSeeMe mailing list.... > > the message below is ill informed since Cu-SeeMe and other tools are > either constant rate (approximately) or adaptive to network conditions > just as TCP is You're overlooking some basic facts here. The CU-SeeMe data stream is unicast UDP at a constant rate of at least 80 kbits/sec (per window, as far as I know users can have as many windows open as they want). There's practically no flow control, back off strategy or any manual controls that lets the application or the user deal meaningfully with real-world bandwidth constraints. The protocol will gradually (over a period of 15 minutes or so) back off until packet loss has dropped to 5%, which it considers optimal. By that time, there won't be a single TCP connection alive anymore. To put it another way, a dozen CU-SeeMe users will kill off the JANET 'fat pipe' that everybody on your side of the channel is so proud of. > the provider below (i'm not going to name them, but they are a UK > provider who underprovisions their backbone) would have you ban DNS > and SNMP by their arguments (actually, TCP based DNS and SNMP might > not be a nbad idea, but thats another story) > > they are threatening their subscribers with this, and they are WRONG > - their subscreibers (I know one group is) wil lmove to other > providers who have properly provisoned backbones... > > tyhe problem they allude to is simply one that requires either a > decent backbone, or without one the advent of RSVP....or else a POP > architecture (e.g. the BT and Pipex Internet services both have) that > protects the net... If you have an axe to grind with EUnet GB you have chosen to do so in a particularly unprofessional way. The 'decent backbone' you talk about exists and is paid for with real money; this in turn comes from customers, who buy service. I don't know if this squares with your view of the world, but that's our view. The most fundamental problem with CU-SeeMe is that as a service provider you end up carrying around up to half a megabit of data that gets dropped on the provider side of the customer connection. > what they are doing is like saying "you';ve paid your roasd tax, but > you can't go so often on the road as we said..." You've paid your road tax but you still can't drive a tank at 100mph down the high street. That's what we're talking about. -- === ___ === Per G. Bilse, Mgr Network Operations Ctr === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Tue Jun 6 02:11:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:14:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:13:01 -0700 Received: from svcs1.digex.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:12:59 -0700 Received: from houston_cc_smtp.hai-net.com (houston_cc_smtp.hai-net.com [204.91.94.67]) by svcs1.digex.net (8.6.12/8.6.12) with SMTP id HAA06695; Tue, 6 Jun 1995 07:10:43 -0400 From: rsingleton@hai-net.com Received: from cc:Mail by houston_cc_smtp.hai-net.com id AA802448046; Tue, 06 Jun 95 07:11:58 EST Date: Tue, 06 Jun 95 07:11:58 EST Message-Id: <9505068024.AA802448046@houston_cc_smtp.hai-net.com> To: Ben Anderson , will@info.ic.gc.ca Cc: dschluss@engin.umich.edu, CU-SEEME-L@cornell.edu, mbone Subject: Re[2]: cu-seeme and the Mbone I would be interested also if anyone can send some light my way. I have loaded cu-seeme on a mac but I need to be pointed in the right direction for hardware and software installation. thx Rickie _______________________________________________________________________________ Subject: Re: cu-seeme and the Mbone From: Ben Anderson at internet Date: 6/6/95 06:54 > > On Mon, 5 Jun 1995, david a. schlussel wrote: > > > I'm trying to find a way to rebroadcast mbone sessions over > > our cu-seeme reflector. Most of our machines are PC's > > or macs. > > > > Well, for the Net95 conference here in Ottawa, we are planning an m-bone > broadcast and a re-broadcast through CUSEEME to participants locally on > PCs. Any more light on this would be nice too..... > > William F. Maton > The latest version (3.01 ?) of Cornell University's CU-SeeMe reflector will 'listen' for packets (audio and video) on a specified multicast address and then reflect them in a unicast manner to any connected CU-SeeMe clients. So it does exactly what you both want. It's all in the reflector README. Of course you may want to ensure that _only_ local CU-SeeMe users connect to the reflector... Ben -- Please read my signature. From list-mgr@ISI.EDU Tue Jun 6 13:31:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:32:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:32:12 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:32:11 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 6 Jun 1995 04:32:01 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Jun 1995 12:31:39 +0100 To: Per Gregers Bilse Cc: mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 95 13:01:37 +0100." <199506061101.AA05378@jotun.EU.net> Date: Tue, 06 Jun 95 12:31:36 +0100 Message-Id: <1463.802438296@cs.ucl.ac.uk> From: Jon Crowcroft >> they are threatening their subscribers with this, and they are WRONG >> - their subscreibers (I know one group is) wil lmove to other >> providers who have properly provisoned backbones... >> tyhe problem they allude to is simply one that requires either a >> decent backbone, or without one the advent of RSVP....or else a POP >> architecture (e.g. the BT and Pipex Internet services both have) that >> protects the net... >If you have an axe to grind with EUnet GB you have chosen to do so >in a particularly unprofessional way. >The 'decent backbone' you talk about exists and is paid for with real >money; this in turn comes from customers, who buy service. I don't >know if this squares with your view of the world, but that's our >view. The most fundamental problem with CU-SeeMe is that as a >service provider you end up carrying around up to half a megabit of >data that gets dropped on the provider side of the customer connection. we pay to use the UKERNA provided backbone - it is a misconception that the UK academic net is free (UKERNA are not for proft which may make them a tad cheaper....) >> what they are doing is like saying "you';ve paid your roasd tax, but >> you can't go so often on the road as we said..." >You've paid your road tax but you still can't drive a tank at 100mph >down the high street. That's what we're talking about. In europe and the US, in 1995, the bandwidth used by CUSeeMe should be regarded as the norm - it is after all typically what the phone net uses per subscriber.... if i lease Internet service with access speed X, i should expect a reasonable percentage of this end to end during average daily load... if i dont get it, and especially if i am using a dialup link which i pay on a pay time unit basis usually to a local telco) i have a right to ask what exactly my service provider has redefined the "the fundamental design of the Internet" to be "largely based on TCP (advanced, highly adaptive, robust, flow control) for high volume), and UDP (simple, crude, unreliable, no flow control) for single, occasional datagrams." the model of the internet is that of IP - the model of TCP is as you say, but there is no implication about how you choose to serve different end to end protocols... whilst I totally agree with Daniel Karrenberg's statement that all applications _should_ be adaptive, i also think that providers should either quarantine traffic types by using smarter routers, or else provide more backbone or both.... I do understand that in some parts of europe, the "open market" has not quite got there, so provisioning is too expensive - i would encourage people to start talking lawsuits here... it is not in anyone's interest to redefine the Internet Service model downwards, but rather to talk it up.... I apologise if i have in anyway implied bad things about EUNet this is a common internet problem... jon From list-mgr@ISI.EDU Tue Jun 6 15:27:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:33:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:28:37 -0700 Received: from ncc.ripe.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:28:34 -0700 Received: from reif.ripe.net by ncc.ripe.net with SMTP id AA03256 (5.65a/NCC-2.23); Tue, 6 Jun 1995 13:27:55 +0200 Message-Id: <9506061127.AA03256@ncc.ripe.net> To: Jon Crowcroft Cc: mbone Subject: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of Tue, 06 Jun 1995 11:47:24 BST. <1696.802435644@cs.ucl.ac.uk> References: <1696.802435644@cs.ucl.ac.uk> From: Daniel Karrenberg X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Date: Tue, 06 Jun 1995 13:27:54 +0200 Sender: Daniel.Karrenberg@ripe.net > Jon Crowcroft writes: > > this is a misunderstanding - for example, TCP does not have infinite > backoff - the minumum rate for TCP with a controlled feedback loop is > 1 packet per round trip time > > currently, the UK-US link has so many connections at any one time > that not even Van's stuff can help - none of them can get to the point > where ack and loss clocking works, so we suffer....would the Internet > Provider's rulew this out bby some TCP connection counting and > addmissio ncontrol? i think not... In this case I would agree that infrastrcuture is insufficient. The argument is about 'so many connections at any one time' versus one UDP application using all of the bandwidth and causing everyone else to suffer. > >This is a consequence of the Internet architecture which assumes > >cooperating hosts and little policing by the network, as opposed > >to PTO type architectures like X.25 which assume the opposite. > > sorry, i disagree - this is a post-hoc definition of the Internet > Architecture... Sidetrack: It is far from post hoc. Maybe the original internet architects were not consciously aware of the issues, although I assume some were. Remember 'End-toEnd'. See 'M.A. Padlipsky: The Elements of Networking Style' for a thorough and entertaining discussion of this. > > > or adaptive to network conditions just as TCP is > >Please enlighten me about nv, vat, CuSeeMe... basically anything > >A/V and designed to run over multicast. Which of these > >is adaptive? > > IVS. see sigcomm last year. (and CuSeeMe I'll have a look. I was under the impression that CuSeeMe would send video even without a receiver active? Is this due to reflectors? > >Without knowing what caused it I personally think the quoted message > >is a little overdone but it certainly addresses a problem. Burying > >your head in the sand and/or shouting "provision bigger infrastructure" > >is not going to solve the problem. > > >Makeing the applications adaptive to the network layer is. > > now this i can totally agree with! > > in extremis, though, you have to have a bare minimum bandwodtyh - e.g. > for voice, below LPC4 (say approx 10kbps) is unusalble - for TCP, as > i've said, below 1 packet per RTT is tricky (not impossible, but > tricky) so you need some sort of idea of a minimum provision for > expected number of users..... > > above that, adaption, and fair share adaption, is a good thing.... I knew we would agree about the important issues! ;-) Daniel From list-mgr@ISI.EDU Tue Jun 6 13:42:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:48:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:43:17 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 04:43:16 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 6 Jun 1995 04:43:08 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Jun 1995 12:42:46 +0100 To: Daniel Karrenberg Cc: mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 95 13:27:54 +0100." <9506061127.AA03256@ncc.ripe.net> Date: Tue, 06 Jun 95 12:42:41 +0100 Message-Id: <1526.802438961@cs.ucl.ac.uk> From: Jon Crowcroft > > sorry, i disagree - this is a post-hoc definition of the Internet > > Architecture... >Sidetrack: >It is far from post hoc. Maybe the original internet architects were >not consciously aware of the issues, although I assume some were. >Remember 'End-toEnd'. >See 'M.A. Padlipsky: The Elements of Networking Style' for a >thorough and entertaining discussion of this. ok. ok - though there werre packet voice experiemtns on the Internet in 1981 i can remember... but lets not forget this is the Mbone list 1 IP datagram visits n places - i.e. you get a bandwidth _reduction_ compared with unicast to n places... this is a part of the Internet Service model and implementations have been around since 1988 do we really want to have islands of non mbone reachability....? should service providers start to list which "service model" they really subscribe to when they offer a service to customers....? like PNOs list QoS parameters....? i spose so....i suppose it has come to that... oh well... jon From list-mgr@ISI.EDU Tue Jun 6 14:23:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 05:27:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 05:26:15 -0700 Received: from cancer.ucs.ed.ac.uk ([129.215.200.7]) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 05:24:03 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id NAA03439; Tue, 6 Jun 1995 13:23:50 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id NAA04723; Tue, 6 Jun 1995 13:23:48 +0100 Date: Tue, 6 Jun 1995 13:23:47 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Jon Crowcroft Cc: Daniel Karrenberg , mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: <1526.802438961@cs.ucl.ac.uk> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Jon Crowcroft wrote: > should service providers start to list which "service model" they > really subscribe to when they offer a service to customers....? like > PNOs list QoS parameters....? > > i spose so....i suppose it has come to that... > > oh well... Well maybe but provided there are enough service providers then customers will use the ones that provide them with the services that they want. You already hinted that in your first message which said that you knew of one GBnet customer who was changing. What EUnet need to worry about is if they don't provide their customers with services that their customers want (and clearly their customers do want this otherwise they would not perceive it as a problem) then they will lose business. However, what is at question here is whether EUnet have correctly identified what might be causing bandwidth problems on their backbones. I am not certain that currently they have but then what do I know. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Tue Jun 6 14:32:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 05:39:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 05:38:45 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 05:38:44 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 6 Jun 1995 05:36:04 -0700 Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Jun 1995 13:33:06 +0100 To: Graeme.Wood@ucs.ed.ac.uk Cc: Daniel Karrenberg , mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 95 13:23:47 BST." Date: Tue, 06 Jun 95 13:32:52 +0100 Message-Id: <2239.802441972@cs.ucl.ac.uk> From: Jon Crowcroft >However, what is at question here is whether EUnet have correctly >identified what might be causing bandwidth problems on their backbones. >I am not certain that currently they have but then what do I know. Graeme right - when some of the NAP/FIX/LINXes publish traffic matricies, and publish service policies based on this (and implement them with priorirtty or newer queueing schemes in routers, e.g. CBQ:-), then we can choose providers for the service mix/charge and so forth but i think the first obvious culprit based on what few figures we can get (e.g. off our campus net) is http if providers all ran hierarchical caching proxy web servers, i would be far happier with them telling subscribers to turn off random offensive applications - or even blocking them by ipproto or tcpport... but it better be written into the service contract before hand... cheers jon From list-mgr@ISI.EDU Tue Jun 6 15:01:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 06:07:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 06:06:41 -0700 Received: from tamdhu.dcs.st-andrews.ac.uk (tamdhu.dcs.st-and.ac.uk) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 06:02:09 -0700 Received: from bushmills.dcs.st-and.ac.uk by tamdhu.dcs.st-andrews.ac.uk (4.1/SMI-4.1) id AA11015; Tue, 6 Jun 95 14:03:05 BST Message-Id: <9506061303.AA11015@tamdhu.dcs.st-andrews.ac.uk> To: Jon Crowcroft Cc: mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 1995 12:31:36 BST." <1463.802438296@cs.ucl.ac.uk> Date: Tue, 06 Jun 1995 14:01:47 +0100 From: "Paul Harrington" this is an interesting set of exchanges: I started off in violent disagreement with what you were saying in the first few messages. However, this last one has set me thinking about 'what exactly is a X bps Internet service' I don't like volume-based charging but ... How about making people pay for the cost of upgraded infrastructure in some kind of proportion to their contribution to the _congestion_ of the original links? If you choke a link due to spewing loads of video/audio then you should be made to pay in some way for the new provisioning to get rid of the congestion. I am assuming that all TCP traffic is well-behaved and squirts in datagrams at just the right rate. Fair? How difficult is it to identify the time-slice of traffic that led to congestion? pjjH From list-mgr@ISI.EDU Tue Jun 6 17:10:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 06:12:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 06:10:25 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 06:10:18 -0700 Received: from anxiety.electrum.kth.se (anxiety.electrum.kth.se [130.237.215.110]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id PAA14865; Tue, 6 Jun 1995 15:08:53 +0200 Received: from localhost.electrum.kth.se (localhost.electrum.kth.se [127.0.0.1]) by anxiety.electrum.kth.se (8.6.9/8.6.9) with SMTP id PAA19127; Tue, 6 Jun 1995 15:10:02 +0200 Message-Id: <199506061310.PAA19127@anxiety.electrum.kth.se> X-Authentication-Warning: anxiety.electrum.kth.se: Host localhost.electrum.kth.se didn't use HELO protocol To: Jon Crowcroft Cc: Graeme.Wood@ucs.ed.ac.uk, Daniel Karrenberg , mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of Tue, 06 Jun 95 13:32:52 BST. <2239.802441972@cs.ucl.ac.uk> Date: Tue, 06 Jun 95 15:10:01 +0200 From: Christian Wettergren | but i think the first obvious culprit based on what few figures we can | get (e.g. off our campus net) is http | | if providers all ran hierarchical caching proxy web servers, i would | be far happier with them telling subscribers to turn off random | offensive applications - or even blocking them by ipproto or | tcpport... I played around with an idea where one could locate nearest copy of a HTML-document by "pinging" for it over multicast, each time with a higher ttl. I called the scheme "Global URL Locator Protocol" or GULP for short. It looked something like this; GULP://community[:realm[:subrealm...]]/ There were something like a fuzzy 'here' also. Each client would contact the nearest GULP-server, and a simple strategy for caching would be for each GULP-server to cache all documents requested. The problem of deploying a "document-propagating WWW" would then consist of 1/ some kind of caching http:s (they exist), 2/ deploying a GULP-hierachy and 3/ come up with a good caching strategy. You see, it's sooo easy! ;-) Wouldn't you all love to have a URL like GULP://here:tourism/maps/ Or what about GULP://Europe:UN/register-as-volonteer This would also need URN/URIs and could maybe use a anycasting service as well. My contribution to the noble art of hand-waveing! :-) /Christian Wettergren, KTH/Teleinformatics From list-mgr@ISI.EDU Tue Jun 6 16:07:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 07:11:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 07:08:47 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 07:08:45 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 6 Jun 1995 07:08:06 -0700 Message-Id: <199506061408.AA10510@quark.isi.edu> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Jun 1995 15:07:35 +0100 To: Paul Harrington Cc: mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 95 14:01:47 BST." <9506061303.AA11015@tamdhu.dcs.st-andrews.ac.uk> Date: Tue, 06 Jun 95 15:07:30 +0100 From: Zheng Wang >How difficult is it to identify the time-slice of traffic that led to >congestion? That's not easy. I think one should install Fair Queuing at the bottleneck, and monitor the average number of active flows so that one can estimate the average performance each individual gets (or to work out how much bandwidth the bottleneck should have). Cheers Zheng From list-mgr@ISI.EDU Tue Jun 6 18:31:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 07:31:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 07:31:23 -0700 Received: from eunet.EU.net (ns2.EU.net) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 07:31:21 -0700 Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id QAA26915 for ; Tue, 6 Jun 1995 16:31:20 +0200 Received: by jotun.EU.net id AA06074 (5.67a/IDA-1.5 for mbone@ISI.EDU); Tue, 6 Jun 1995 16:31:18 +0200 Message-Id: <199506061431.AA06074@jotun.EU.net> From: Per Gregers Bilse Date: Tue, 6 Jun 1995 16:31:18 +0200 In-Reply-To: Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications A few snippets: On Jun 6, 14:01, "Paul Harrington" wrote: > However, this last one has set me thinking about 'what exactly is a X > bps Internet service' :-) This has been discussed "a couple of times" on com-priv. > I don't like volume-based charging but ... How about making people > pay for the cost of upgraded infrastructure in some kind of proportion > to their contribution to the _congestion_ of the original links? If This is extremely difficult. Not least because even if you have pure volume charge, 95% of the traffic gets dropped on the provider side of the connection. You can't send a bill for several hundred kbits of traffic to a dial-up modem user. On Jun 6, 13:23, Graeme Wood wrote: > that you knew of one GBnet customer who was changing. What EUnet need to > worry about is if they don't provide their customers with services that > their customers want (and clearly their customers do want this otherwise > they would not perceive it as a problem) then they will lose business. This is exactly what is being done -- ensuring that customers get the service they need and expect. What you are overlooking is that a single user armed with a Mac and a modem can turn on many hundred kbits of real time, unrestricted traffic. It doesn't take a lot of that to take out links of 1Mbit and more. Period. > However, what is at question here is whether EUnet have correctly > identified what might be causing bandwidth problems on their backbones. It beats me how you can conclude that there is such a problem; is it the case that many people in the UK have a need to generally badmouth EUnet GB? If so, please get in touch and let me know what you see as a problem. What is being addressed is the threat of incidents of serious congestion, caused largely by a single, very ill-behaved application. That, folks, is just plain good network and business management. In case it isn't obvious (there are technical people on this list, right?) it is extremely easy to cause serious damage to Internet (backbone) links, almost no matter how big they are; CU-SeeMe is reminiscent of 'udpblast', only with presumably more interesting packet contents. One thing "you" (the generic "you") want to look for in a service provider is some indication that they stay on top of things, and do at least something to make sure your connection is reliable and can be said to generally work. That includes laying down some general rules, which is generally a sign of a civilized society or some such thing. You will not want to be connected to a provider that does little else than collect your money. But does this stuff really belong on the Mbone list? -- === ___ === Per G. Bilse, Mgr Network Operations Ctr === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Tue Jun 6 17:13:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 08:17:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 08:17:23 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 08:17:23 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 6 Jun 1995 08:17:06 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Jun 1995 16:13:39 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Jon Crowcroft Cc: Per Gregers Bilse , mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 95 12:31:36 BST." <1463.802438296@cs.ucl.ac.uk> Date: Tue, 06 Jun 95 16:13:36 +0100 Message-Id: <6893.802451616@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >if i lease Internet service with access speed X, i should expect a >reasonable percentage of this end to end during average daily load... ...and thus if your provider's backbone is properly provisioned for TCP then it should be pretty close for UDP, or your provider is not supplying you with what you payed for. However, this doesn't mean that your provider should necessarily give you your link speed to everywhere. If their backbone is properly provisioned then for example your 64K link should be able to get close to 64K for a reasonable proportion of the average day to another (64K or greater) site connected by the same provider. It doesn't necessarily mean you should be able to get that same performance to someone on another provider. And if you try you may cause problems for one or both providers. Given the price of international bandwidth, that is where charging for reservation may provide a means for the provider to recoup their costs and provide a better network. It also provides some necessary negative feedback preventing unnecessary transmission where it causes a problem (and also depending on your charging model). I don't particularly like the whole principle of reservations, but it's difficult to see how we get from where we are now to where we'd like to be without charging for reservations (at least in some parts of the world). There's definitely a place for adaptive applications, but in general there's a threshold below which you don't want to be driven or the data flow stops being useful, and it's probably somewhere around this level that we want to reserve and pay for. If IP providers can't do reasonable realtime traffic and do it fairly soon, we'll drive the realtime traffic onto pure ATM networks along with all their associated problems, when what we want is one integrated internet. Banning realtime traffic is a bad solution, but I can see their viewpoint. In the meantime though, we're probably going to see more providers complaining about realtime traffic. Mark From list-mgr@ISI.EDU Tue Jun 6 17:20:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 08:21:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 08:21:15 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 08:20:49 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id QAA06351; Tue, 6 Jun 1995 16:20:42 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id QAA05060; Tue, 6 Jun 1995 16:20:36 +0100 Date: Tue, 6 Jun 1995 16:20:33 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Per Gregers Bilse Cc: mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: <199506061431.AA06074@jotun.EU.net> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Per Gregers Bilse wrote: > On Jun 6, 13:23, Graeme Wood wrote: > > that you knew of one GBnet customer who was changing. What EUnet need to > > worry about is if they don't provide their customers with services that > > their customers want (and clearly their customers do want this otherwise > > they would not perceive it as a problem) then they will lose business. > > This is exactly what is being done -- ensuring that customers > get the service they need and expect. What you are overlooking > is that a single user armed with a Mac and a modem can turn on > many hundred kbits of real time, unrestricted traffic. It doesn't > take a lot of that to take out links of 1Mbit and more. Period. Well as has already been pointed out the vast majority of the traffic isn't of this kind and most applications that you malign do do some kind of backoff so the situation is not as bad as you describe. > > However, what is at question here is whether EUnet have correctly > > identified what might be causing bandwidth problems on their backbones. > > It beats me how you can conclude that there is such a problem; > is it the case that many people in the UK have a need to generally > badmouth EUnet GB? If so, please get in touch and let me know what > you see as a problem. It beats me how you conclude from what I said that I was badmouthing EUnet. It was you that concluded that CU-SeeME and MBONE type traffic was causing a problem not I. What I may have done was bring into doubt EUnet's conclusions about where the problem may lie. I don't see how that is badmouthing you. I did not and do not intend to disparage EUnet or any other Internet provider. > What is being addressed is the threat of incidents of serious > congestion, caused largely by a single, very ill-behaved > application. That, folks, is just plain good network and business > management. In case it isn't obvious (there are technical people on > this list, right?) it is extremely easy to cause serious damage to > Internet (backbone) links, almost no matter how big they are; > CU-SeeMe is reminiscent of 'udpblast', only with presumably more > interesting packet contents. > > One thing "you" (the generic "you") want to look for in a service > provider is some indication that they stay on top of things, and do > at least something to make sure your connection is reliable and can > be said to generally work. That includes laying down some general > rules, which is generally a sign of a civilized society or some such > thing. You will not want to be connected to a provider that does > little else than collect your money. > > But does this stuff really belong on the Mbone list? Yes and no. Discussions about CU-SeeMe and MBONE applications and how they impinge on the network infrastructure and how we monitor and control their affect certainly do belong on this list. I think what people on this list may be worried about is that EUnet have introduced a restriction on their customers without doing sufficient diagnosis of whether the problem is due to CU-SeeMe traffic. I am sure I will be corrected if I am wrong :-) Discussions about the pros and cons CU-SeeMe method of distribution over MBONE have been going on for sometime on this list and others. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Tue Jun 6 01:34:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 08:36:49 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 08:36:21 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 08:36:20 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14496(6)>; Tue, 6 Jun 1995 08:35:15 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 6 Jun 1995 08:35:05 -0700 To: mbone Cc: Per Gregers Bilse , deering@parc.xerox.com Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Date: Tue, 6 Jun 1995 08:34:51 PDT Sender: Steve Deering From: Steve Deering Message-Id: <95Jun6.083505pdt.75270@digit.parc.xerox.com> I object to having the MBone applications lumped in with CUSeeMe as bandwidth hogs. The software for the MBone routers includes (since almost two years ago) a manually-configurable per-tunnel and per-interface rate limiting capability. That capability was added specifically to protect the resources of bandwidth-poor service providers who have not yet gotten around to protecting themselves by implementing some approximation of fair qeueing. > Technically, it is UDP being transmitted in real > time, large volume. This violates the fundamental > design of the Internet, which is largely based on > TCP (advanced, highly adaptive, robust, flow control) > for high volume), and UDP (simple, crude, unreliable, > no flow control) for single, occasional datagrams. What nonsense. One of the main reasons that UDP exists as an alternative to TCP is to support real-time applications. For example, the reason why the UDP data checksum is optional is to support real-time applications that can tolerate some bit damage but cannot tolerate the delays of repair by TCP-style retransmission. Real-time voice and video have been transmitted over parts of the Internet for as long as there has been an Internet. Also, there's nothing in the "fundamental design of the Internet" that requires routers to do only FIFO queueing. Deploy per-source fair queueing in your routers, and the applications will learn to adapt to whatever share they get. And size your network so that those shares are big enough to keep your customers from taking their business elsewhere. Relying only on the good behavior of end hosts to keep your network working seems awfully foolish, in today's soon-to-be-if-not-already-PC-dominated Internet. Steve From list-mgr@ISI.EDU Tue Jun 6 01:51:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 08:53:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 08:52:33 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 08:52:32 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14417(5)>; Tue, 6 Jun 1995 08:52:08 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Tue, 6 Jun 1995 08:52:03 -0700 To: Stefano Klett Cc: mbone Subject: Re: Mrouted 3.5 core dump with phyint disable In-Reply-To: Your message of "Tue, 06 Jun 95 02:48:44 PDT." <9506060948.AA03992@monte> Date: Tue, 6 Jun 1995 08:51:55 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun6.085203pdt.49859@crevenia.parc.xerox.com> In message <9506060948.AA03992@monte> you write: >I install Mrouted 3.5 on SUN-LX with SunOS Release 4.1.4. >If I disable the local phyint then Mrouted will produce core dump. This is a bug in 3.5. There were a number of minor but annoying bugs in 3.5, so I will be releasing 3.6 soon (3.6 will be an *mrouted-only* upgrade, no kernel modifications). Bill From list-mgr@ISI.EDU Tue Jun 6 16:18:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:25:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:25:00 -0700 Received: from fenris.hiof.no by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:20:49 -0700 Received: from abdallah.hiof.no by fenris.hiof.no with SMTP (PP) id <15865-0@fenris.hiof.no>; Tue, 6 Jun 1995 18:19:58 +0200 Received: by abdallah.hiof.no (940816.SGI.8.6.9/940406.SGI.AUTO) id QAA16485; Tue, 6 Jun 1995 16:18:52 GMT Date: Tue, 6 Jun 1995 16:18:50 +0000 From: Borre Ludvigsen X-Sender: borrel@abdallah To: CU-SeeMe Cc: mbone, Per Gregers Bilse , deering@parc.xerox.com Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: <95Jun6.083505pdt.75270@digit.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII It would help GREATLY if the Cornell team were to release a version of CU-SeeMe where the default sending bandwidth was set to max 20kbps rather than the present 80. Very few first time users are aware of the bandwidth consequences of firing up CU-SeeMe "out of the box". It would also help a lot if a README file on bandwidth and polite usage were shrink-packed along with the binary. - Barre From list-mgr@ISI.EDU Tue Jun 6 08:24:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:25:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:24:50 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:24:49 -0700 Received: by chops.icp.net id <20696>; Tue, 6 Jun 1995 12:24:36 -0400 From: Sean Doran To: Graeme.Wood@ucs.ed.ac.uk, J.Crowcroft@cs.ucl.ac.uk Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: Daniel.Karrenberg@ripe.net, mbone Message-Id: <95Jun6.122436-0400_edt.20696+338@chops.icp.net> Date: Tue, 6 Jun 1995 12:24:33 -0400 >when some of the NAP/FIX/LINXes publish traffic matricies http://www.mfsdatanet.com/MAE/east.stats.html >priority or newer queueing schemes in routers Right. Using what type of CPU, pray tell? Reality check - the Internet is BIG and growing BIGGER and keeping it actually working for production unicast traffic will be given MUCH more priority by NSPs and ISPs and so forth than making it easier for you to play with your various pet toys. I regret that the Internet is now so large and suffering from scaling problems that made EUNET GB's statements necessary, however I support their position fully. Sean. - -- Sean Doran / Sprint/NSFNET International Connectivity Project From list-mgr@ISI.EDU Tue Jun 6 20:32:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:32:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:32:11 -0700 Received: from eunet.EU.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:32:10 -0700 Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id SAA14280; Tue, 6 Jun 1995 18:32:08 +0200 Received: by jotun.EU.net id AA06497 (5.67a/IDA-1.5); Tue, 6 Jun 1995 18:32:06 +0200 Message-Id: <199506061632.AA06497@jotun.EU.net> From: Per Gregers Bilse Date: Tue, 6 Jun 1995 18:32:06 +0200 In-Reply-To: <95Jun6.083505pdt.75270@digit.parc.xerox.com> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Steve Deering Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone On Jun 6, 8:34, Steve Deering wrote: > I object to having the MBone applications lumped in with CUSeeMe as > bandwidth hogs. The software for the MBone routers includes (since This isn't being done either; if this has been inferred, it is a mistake. OTOH, Mbone stuff can't really be said to be lean and mean either and the strategic problem is one of user behaviour -- the Mbone has its fair share of "user x on machine y is sending 400 kbit of empty office". And yet, that's a smaller problem than 20 users watching 80kbit NASA shuttle archives. > > Technically, it is UDP being transmitted in real > > time, large volume. This violates the fundamental > > design of the Internet, which is largely based on > > TCP (advanced, highly adaptive, robust, flow control) > > for high volume), and UDP (simple, crude, unreliable, > > no flow control) for single, occasional datagrams. > > What nonsense. One of the main reasons that UDP exists as an alternative > to TCP is to support real-time applications. For example, the reason why The issue here isn't one of the theoretical design considerations of the current Internet; rather, the issue is what is the case in practice. Fundamentally changing this "overnight" (ie, in a matter of a few months) requires strategic changes ranging from technology to pricing. This won't happen "overnight". > Also, there's nothing in the "fundamental design of the Internet" that > requires routers to do only FIFO queueing. Deploy per-source fair queueing > in your routers, and the applications will learn to adapt to whatever share And which routers should be used for that? Our favourite platform at the moment is Cisco 4500 since it has the horsepower to do just that. However, if you have higher speed WAN connections than E1 your only choice is the 7000, which has CPU power like a healthy MacIntosh -- can't be done. Again, this is not an issue of what is theoretically desirable, but rather what it is realistic to achieve. Moreover, fair queueing, even when done on a 4500, introduces unpleasant delays, largely due to the granularity of the queue sizes and the way the router schedules them (we're talking about RTT going up from 30-40ms on an unmanaged connection, to 100-150ms). > Relying only on the good behavior of end hosts to keep your network working > seems awfully foolish, in today's soon-to-be-if-not-already-PC-dominated > Internet. I don't think anybody does that. However, that doesn't preclude you from establishing some basic rules, one of which is "you are not allowed to do damage". You also don't want to live in a society where bullet proof vests are worn by everybody because the streets are full of kids with machine guns. Generally, I'm rather astounded by the responses (and bizarre conclusions) I've seen so far on this list. There is absolutely nothing unusual about those terms and conditions -- you'll find practically the same in most other providers T&Cs, modulo some variation (like ultra-cheap bandwidth being the order of the day in the US, ultra-expensive being the order of the day in Europe). -- === ___ === Per G. Bilse, Mgr Network Operations Ctr === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Tue Jun 6 18:40:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:41:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:41:23 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:41:14 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id RAA07304; Tue, 6 Jun 1995 17:40:25 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id RAA05324; Tue, 6 Jun 1995 17:40:22 +0100 Date: Tue, 6 Jun 1995 17:40:21 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Sean Doran Cc: mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: <95Jun6.122436-0400_edt.20696+338@chops.icp.net> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Sean Doran wrote: > >when some of the NAP/FIX/LINXes publish traffic matricies > > http://www.mfsdatanet.com/MAE/east.stats.html > > >priority or newer queueing schemes in routers > > Right. Using what type of CPU, pray tell? > > Reality check - the Internet is BIG and growing BIGGER and > keeping it actually working for production unicast traffic > will be given MUCH more priority by NSPs and ISPs and so > forth than making it easier for you to play with your > various pet toys. > > I regret that the Internet is now so large and suffering > from scaling problems that made EUNET GB's statements > necessary, however I support their position fully. Well it seems very sad that it has come to this. What you are saying is that we should all go home and forget about any new development. I wonder how long the Internet would remain if that is the attitude everyone took. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Tue Jun 6 08:44:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:46:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:44:41 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:44:40 -0700 Received: by chops.icp.net id <20696>; Tue, 6 Jun 1995 12:44:29 -0400 From: Sean Doran To: phrrngtn@dcs.st-and.ac.uk, Z.Wang@cs.ucl.ac.uk Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone Message-Id: <95Jun6.124429-0400_edt.20696+339@chops.icp.net> Date: Tue, 6 Jun 1995 12:44:17 -0400 >I think one should install Fair Queuing at the bottleneck >and monitor the average number of active flows ... Reality check - at the moment one of the ICM connectees talking at E1 (2Mbps) is moving 1700pps to Europe and 1200pps from Europe. It's quiet now, relatively speaking, however I'm probably safe in asserting that there are lots more TCP flows moving or trying to move through that link in a given minute than 10*pps. I'd guess that the multiple now approaches 30*pps over a minute, and that it peaks much too close to 60*pps over a minute at unusably congested times. Unfortunately, attempting to measure this carefully generally causes routers to keel over due to CPU load, which obviously changes traffic patterns... If you care to implement code for, say, a Cisco 7000 to do Fair Queuing (or whatever toy technology you choose) on a box which is doing in the neighbourhood of several thousand pps (or several tens of thousands of pps) without a serious performance hit, then I'm sure you'll see people investigating it at some point. Sean. From list-mgr@ISI.EDU Tue Jun 6 08:49:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:50:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:50:12 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:50:10 -0700 Received: by chops.icp.net id <20696>; Tue, 6 Jun 1995 12:50:00 -0400 From: Sean Doran To: bilse@EU.net, mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Message-Id: <95Jun6.125000-0400_edt.20696+340@chops.icp.net> Date: Tue, 6 Jun 1995 12:49:52 -0400 >But does this stuff really belong on the Mbone list? Interesting people read the list, and there are few noisy com-priv types lurking here. :-) Ob.MBONE: if anyone is actively looking at testing PIM in the near future (you know who you are likely to be) on a big backbone with lots of DVMRP in place, I'd love it if you'd drop me a note... Sean. From list-mgr@ISI.EDU Tue Jun 6 08:59:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:59:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:59:16 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 09:59:14 -0700 Received: by chops.icp.net id <20696>; Tue, 6 Jun 1995 12:59:03 -0400 From: Sean Doran To: Graeme.Wood@ucs.ed.ac.uk Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone Message-Id: <95Jun6.125903-0400_edt.20696+341@chops.icp.net> Date: Tue, 6 Jun 1995 12:59:00 -0400 No, what is happening here is that a bunch of people who are lacking some understanding of how the Internet works at the packet-forwarding level are now being told that their favourite toys are breaking things. On congested international links, CU-SEEME is a large-scale denial-of-service attack with a pretty user-interface. Sean. - -- Sean Doran / From list-mgr@ISI.EDU Tue Jun 6 21:03:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:03:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:03:20 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:03:14 -0700 Received: from anxiety.electrum.kth.se (anxiety.electrum.kth.se [130.237.215.110]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id TAA21260; Tue, 6 Jun 1995 19:01:53 +0200 Received: from localhost.electrum.kth.se (localhost.electrum.kth.se [127.0.0.1]) by anxiety.electrum.kth.se (8.6.9/8.6.9) with SMTP id TAA21440; Tue, 6 Jun 1995 19:03:03 +0200 Message-Id: <199506061703.TAA21440@anxiety.electrum.kth.se> X-Authentication-Warning: anxiety.electrum.kth.se: Host localhost.electrum.kth.se didn't use HELO protocol To: Graeme.Wood@ucs.ed.ac.uk Cc: Sean Doran , mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of Tue, 06 Jun 95 17:40:21 BST. Date: Tue, 06 Jun 95 19:03:01 +0200 From: Christian Wettergren | On Tue, 6 Jun 1995, Sean Doran wrote: | | > >when some of the NAP/FIX/LINXes publish traffic matricies | > | > http://www.mfsdatanet.com/MAE/east.stats.html | > | > >priority or newer queueing schemes in routers | > | > Right. Using what type of CPU, pray tell? | > | > Reality check - the Internet is BIG and growing BIGGER and | > keeping it actually working for production unicast traffic | > will be given MUCH more priority by NSPs and ISPs and so | > forth than making it easier for you to play with your | > various pet toys. | > | > I regret that the Internet is now so large and suffering | > from scaling problems that made EUNET GB's statements | > necessary, however I support their position fully. | | Well it seems very sad that it has come to this. What you are saying is | that we should all go home and forget about any new development. I | wonder how long the Internet would remain if that is the attitude | everyone took. Could EUnet please provide some figures about traffic mix, utilization and so on? I wonder what measurements EUnet has to support this position? If you have them, please share them. That might help convince us MBoners that Mbone/real-time traffic really is the problem. WWW recently made it to the top protocol on NSFnet(?). Are EUnet sure that Web traffic shouldn't be policed? (I'm still unsure whether the MIME/multipart solution has been implemented in most Web-browsers. Shouldn't that soon be a requirement?) I suggest that EUnet sponsors the MICE Network of Support Centers as a more positive solution than simply outright forbidding real-time traffic. The Network has tried to develop different guide on proper use, educating users etc. (Self-promotion, isn't that great? ;-) Take a look at http://www.cs.ucl.ac.uk/mice/mice-nsc for more information.) How do EUnet plan to enforce this policy? It sure wont be simple. It is of course always possible to police MBone traffic, but it is a whole lot more difficult for CuSeeMe and even point-to-point connections. I have a feeling that we are trying to wring out the last few kbps of links with this. Maybe I'm wrong. I might support this ban if it is a short-term solution, working frantically towards a better long-term one. That might be a pragmatic solution. But then I would like to see far more figures and statistics before I'm convinced. Regards, Christian Wettergren KTH/Teleinformatics From list-mgr@ISI.EDU Tue Jun 6 03:02:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:03:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:02:51 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:02:50 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id KAA26357; Tue, 6 Jun 1995 10:02:28 -0700 Date: Tue, 6 Jun 1995 10:02:28 -0700 From: Dino Farinacci Message-Id: <199506061702.KAA26357@stilton.cisco.com> To: deering@parc.xerox.com Cc: mbone, bilse@eu.net, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Tue, 6 Jun 1995 08:34:51 PDT <95Jun6.083505pdt.75270@digit.parc.xerox.com> Subject: EUnet GB policy on Cu-SeeMe and similar applications >> I object to having the MBone applications lumped in with CUSeeMe as >> bandwidth hogs. The software for the MBone routers includes (since >> almost two years ago) a manually-configurable per-tunnel and >> per-interface rate limiting capability. That capability was added >> specifically to protect the resources of bandwidth-poor service >> providers who have not yet gotten around to protecting themselves by >> implementing some approximation of fair qeueing. I'd like to add that cisco routers have been doing priority/custom queuing for years. And our next release of software will provide rate-limiting and fair-queuing as well. Dino From list-mgr@ISI.EDU Tue Jun 6 09:11:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:12:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:11:16 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:11:15 -0700 Received: by chops.icp.net id <20696>; Tue, 6 Jun 1995 13:11:07 -0400 From: Sean Doran To: J.Crowcroft@cs.ucl.ac.uk, M.Handley@cs.ucl.ac.uk Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: bilse@EU.net, mbone Message-Id: <95Jun6.131107-0400_edt.20696+342@chops.icp.net> Date: Tue, 6 Jun 1995 13:11:07 -0400 | it's difficult to see how we get from where we are now to where we'd | like to be without charging for reservations Where _who_'d like to be? | If IP providers can't do reasonable realtime traffic and do it fairly | soon, we'll drive the realtime traffic onto pure ATM networks along Fine. Have fun building it. Send a postcard from the ATM-global-multicast-backbone mailing list. Sean. P.S.: "banning realtime traffic is a bad solution" - no kidding; so is building or using a tool that lacks the kind of congestion-avoidance mechanisms in even ancient TCPs and then arguing that The Internet Must Change To Make This Tool Work Well. From list-mgr@ISI.EDU Sat Jun 6 05:24:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:25:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:25:05 -0700 Received: from br4130mail.nrel.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:25:03 -0700 Message-Id: Date: 6 Jun 1995 11:24:20 -0600 From: "Andrew T" Return-Receipt-To: "Andrew T" Subject: RE: EUnet GB policy on Cu-SeeMe and similar applications To: mbone X-Mailer: Mail*Link SMTP-MS 3.0.2 This topic is turning into it's own BANDWIDTH hog. Please be kind with this list. Not all of care about everyone's opinion on this issue. Andrew Tennant From list-mgr@ISI.EDU Tue Jun 6 09:28:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:29:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:28:38 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:28:37 -0700 Received: by chops.icp.net id <20696>; Tue, 6 Jun 1995 13:28:25 -0400 From: Sean Doran To: cwe@it.kth.se, Graeme.Wood@ucs.ed.ac.uk Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone, smd@icp.net Message-Id: <95Jun6.132825-0400_edt.20696+343@chops.icp.net> Date: Tue, 6 Jun 1995 13:28:12 -0400 > How do EUnet plan to enforce this policy? I thought that it was clear that they plan to use the customer service agreement rather than a technical solution. This strikes me as perfectly appropriate. This is how most people seem have reacted to Van Jacobson's notes about people flooding out MBONE traffic -- "when please stop doing X" doesn't work, one escalates up the offender's local administrative food-chain or the provider hierarchy or both asking for help in stopping X. If X keeps happening due to malice or simple stubbornness ("The Internet Must Adapt To Make This Tool Work Properly"), a provider _ought_ to take appropriate steps, from filtering X to discontinuing service. EUNet GB seeks to eliminate ignorance as a key reason for X happening over and over again, and I applaud them. Sean. From list-mgr@ISI.EDU Tue Jun 6 03:55:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:56:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:56:23 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 10:56:22 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14433(1)>; Tue, 6 Jun 1995 10:55:54 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 6 Jun 1995 10:55:44 -0700 To: Per Gregers Bilse Cc: mbone, deering@parc.xerox.com Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: bilse's message of Tue, 06 Jun 95 09:32:06 -0800. <199506061632.AA06497@jotun.EU.net> Date: Tue, 6 Jun 1995 10:55:31 PDT Sender: Steve Deering From: Steve Deering Message-Id: <95Jun6.105544pdt.75270@digit.parc.xerox.com> Per, > > I object to having the MBone applications lumped in with CUSeeMe as > > bandwidth hogs. The software for the MBone routers includes (since > > This isn't being done either; if this has been inferred, it is a > mistake. OK, then I misunderstood. The policy note that triggered this discussion referred to "Damaging Video/Voice Traffic on the Internet". If that excludes MBone-based applications (since they are not "damaging"), then I withdraw my objection. > OTOH, Mbone stuff can't really be said to be lean and > mean either and the strategic problem is one of user behaviour -- > the Mbone has its fair share of "user x on machine y is sending > 400 kbit of empty office". Agreed, but the rate-limiting feature of the MBone software allows you, the provider, to put a hard bound on how much of your bandwidth can be consumed by such behavior. The problem then becomes ours (the MBone community's) to deal with, which we do through a mix of technical (e.g., scope limits, tunnel disabling, and, in the future, maybe fair queueing in the MBone routers) and administrative (e.g., Van-o-grams) means. But it *really* would be nice to get some sort of FQ into the bottleneck unicast routers, so we don't have to keep inventing more and more complicated band-aids at the mrouter level. > > What nonsense. One of the main reasons that UDP exists as an alternative > > to TCP is to support real-time applications. For example, the reason why > > The issue here isn't one of the theoretical design considerations > of the current Internet; rather, the issue is what is the case > in practice. The issue I was responding was the claim made in Peter Houlder's policy note that real-time, high-volume UDP traffic "violates the fundamental design of the Internet". If that note had said that parts of the current Internet are not well engineered to support real-time UDP, I would not have disagreed. > Fundamentally changing this "overnight" (ie, in a matter of a few months) > requires strategic changes ranging from technology to pricing. This won't > happen "overnight". Understood. I didn't mean to imply that real-time-challenged parts of the Internet should or could be fixed overnight. I am just urging the providers to move in the right direction as soon as possible. Simply outlawing real-time applications is not the right direction, in my opinion -- that will just remove the incentive to improve the infrastructure and will prevent the Internet from fulfilling its potential as the GII. If the No Real-Time Traffic dictum had been stated as a temporary measure until facilities can be upgraded, rather than a result of the fundamental design of the Internet, I (and presuambly others) would not have responded so strongly. > You also don't want to live in a society where > bullet proof vests are worn by everybody because the streets are full > of kids with machine guns. True. But if you *do* happen to live in a world where the streets are full of kids with nachine guns, it would be dangerous to rely only on asking them to refrain from using those machine guns unless they had written permission. > Generally, I'm rather astounded by the responses (and bizarre > conclusions) I've seen so far on this list. Partly this is a response to the bizarre conclusions that some providers have been leaping to. One of those conclusions has been that real-time UDP-based traffic is frivolous and must be discriminated against in favor of "serious", TCP-based traffic, much of which consists of pornographic GIF images and audio samples of Socks the Cat. Steve From list-mgr@ISI.EDU Tue Jun 6 10:20:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 11:22:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 11:22:13 -0700 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 11:22:12 -0700 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA23335; Tue, 6 Jun 1995 14:20:58 +0500 Message-Id: <9506061820.AA23335@msf.psi.net.> To: Graeme.Wood@ucs.ed.ac.uk Cc: Sean Doran , mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 1995 17:40:21 BST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <23333.802462857.1@msf.psi.net> Date: Tue, 06 Jun 1995 14:20:57 -0400 From: "Mark S. Fedor" Content-Length: 1954 Graeme, Sean does not speak for all ISP's. I assume he speaks for sprintlink and his message outlined sprintlink's position. There are ISP's out there (at lease one I know of :^) who are interested in the multicast/multimedia developments and working on ways to integrate them into the entire mix of things and making them work together... Mark PSINet ------------------ > On Tue, 6 Jun 1995, Sean Doran wrote: > > > >when some of the NAP/FIX/LINXes publish traffic matricies > > > > http://www.mfsdatanet.com/MAE/east.stats.html > > > > >priority or newer queueing schemes in routers > > > > Right. Using what type of CPU, pray tell? > > > > Reality check - the Internet is BIG and growing BIGGER and > > keeping it actually working for production unicast traffic > > will be given MUCH more priority by NSPs and ISPs and so > > forth than making it easier for you to play with your > > various pet toys. > > > > I regret that the Internet is now so large and suffering > > from scaling problems that made EUNET GB's statements > > necessary, however I support their position fully. > > Well it seems very sad that it has come to this. What you are saying is > that we should all go home and forget about any new development. I > wonder how long the Internet would remain if that is the attitude > everyone took. > > ============================================================================= > Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk > Unix Systems Support Phone: +44 131 650 5003 > The University of Edinburgh Fax: +44 131 650 6552 > ----------------------------------------------------------------------------- > Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk > for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ > ============================================================================= > From list-mgr@ISI.EDU Tue Jun 6 12:11:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 13:12:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 13:11:50 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 13:11:49 -0700 Received: by chops.icp.net id <20696>; Tue, 6 Jun 1995 16:11:42 -0400 From: Sean Doran To: bilse@EU.net, deering@parc.xerox.com Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone Message-Id: <95Jun6.161142-0400_edt.20696+348@chops.icp.net> Date: Tue, 6 Jun 1995 16:11:38 -0400 >"serious", TCP-based traffic, much of which consists of pornographic GIF >images and audio samples of Socks the Cat. Uh huh, and when everyone with an ISDN line is doing voice+video to his or her friends, you expect this to be used for serious stuff as opposed to further nifty ways of using the Internet for sex-on-demand? There is a simple way to turn the bias towards TCP on its head, and that is to tell your various sales teams that you are willing to take significant cuts in TCP goodput in favour of UDP stuff, MBONE or otherwise. Send me a copy of any such agreement you come up with. Sean. From list-mgr@ISI.EDU Tue Jun 6 12:36:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 13:37:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 13:37:06 -0700 Received: from prom.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 13:37:05 -0700 Received: (dschluss@localhost) by prom.engin.umich.edu (8.6.12/8.6.4) id QAA29470; Tue, 6 Jun 1995 16:36:48 -0400 Date: Tue, 6 Jun 1995 16:36:35 -0400 (EDT) From: "david a. schlussel" Sender: "david a. schlussel" Reply-To: "david a. schlussel" Subject: Re: CellB decoder... To: Vivek Bansal Cc: mbone, rem-conf@es.net, van@ee.lbl.gov In-Reply-To: <9506052235.AA10079@depot> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII the standard video tool for mbone, nv, has a sun CellB setting. you can find that at parcftp.xerox.com/pub/net-research/ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ On Mon, 5 Jun 1995, Vivek Bansal wrote: > > We are looking for a software decoder for a video stream which has been > encoded using Sun's cellB video format. > Is it possible to use vic to take a cellb encoded file and display it ?? > or is there any other tool to do that ??? > > Thanks > > Vivek.. > > > From list-mgr@ISI.EDU Wed Jun 7 01:06:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 14:15:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 14:15:32 -0700 Received: from kolibri.runit.sintef.no (eaj5.runit.sintef.no) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 14:15:18 -0700 Received: from kolibri.runit.sintef.no (he@localhost [127.0.0.1]) by kolibri.runit.sintef.no (8.6.12/8.6.9) with ESMTP id XAA00201; Tue, 6 Jun 1995 23:06:02 +0200 Message-Id: <199506062106.XAA00201@kolibri.runit.sintef.no> To: van@ee.lbl.gov Cc: cwe@it.kth.se, dino@cisco.com, mbone, flag@it.kth.se Subject: Re: PIM configuration FAQ? From: Havard.Eidnes@runit.sintef.no In-Reply-To: Your message of "Tue, 30 May 95 01:52:02 PDT" References: <199505300852.BAA26946@rx7.ee.lbl.gov> X-Mailer: Mew beta version 0.89 on Emacs 19.28.1 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 06 Jun 1995 23:06:02 +0200 Sender: he@kolibri.runit.sintef.no Hi, I think Dino Farinacci answered most of Van's complaints. However, I think I have something to add. I think that Cisco did an unwise choice when the syntax for the "inject unicast routes into DVMRP" command was chosen. As Dino said, the command (in context) looks more or less like this: ! interface tunnel 0 tunnel mode dvmrp ip dvmrp metric [] [ ] [dvmrp] ! Note that if you omit all the optional parameters, this can become ! interface tunnel 0 tunnel mode dvmrp ip dvmrp metric 5 ! This is too similar to ! interface ethernet 0 ip ospf metric 10 ! However, one of them adjusts the interface metric (OSPF) whereas we now know what the other one does (it does not adjust the DVMRP interface metric for the tunnel interface ;-). There is no obvious sign that the DVMRP command actually does route re- distribution -- the syntax is quite different from that used for redistribution between ordinary unicast (IP) routing protocols. By the principle of least astonishment, I would claim that the choice of command name for this function is particularly bad, and is likely to trap more newcomers who read the manual after the fact (if at all). If this can be redone, I would suggest using a syntax which is somewhat more similar to the ordinary IP redistribution syntax for this function. A less drastic approach would be to change the access list in the "ip dvmrp metric" configuration command from being an optional to a mandatory parameter. I must say, though, that the ease with which it is possible to trash the MBone really should tell us something about the fragility of the current protocols and implementations -- I am certain that all the bright protocol designers out there have taken this lesson with them back to the drawing board and are coming up with something less fragile next time around, right? ;-) I won't bore you with why I think PIM (sparse mode, of course ;-) is much better than the current incarnation of DVMRP, suffice it to say that the fact that PIM is integrated in ordinary routers probably contributes the most. Tunnelled solutions never really know the underlying topology of the network and this can have some highly undesireable effects in certain configurations. I freely admit not to know all the details about the proposed two-level DVMRP (I did at least attend Van's presentation of it at the San Jose IETF), but running the MBone on essentially 2-level RIP appear to me to be a kludge, no less. That combined with duplication of traffic for transit routing domains which also have local listeners more or less killed my interest in it. - H=E5vard From list-mgr@ISI.EDU Tue Jun 6 07:33:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 14:49:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 14:47:45 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 14:47:44 -0700 Received: from stilton.cisco.com by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 6 Jun 1995 14:35:54 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id OAA07644; Tue, 6 Jun 1995 14:33:00 -0700 Date: Tue, 6 Jun 1995 14:33:00 -0700 From: Dino Farinacci Message-Id: <199506062133.OAA07644@stilton.cisco.com> To: Havard.Eidnes@runit.sintef.no Cc: van@ee.lbl.gov, cwe@it.kth.se, mbone, flag@it.kth.se In-Reply-To: Havard.Eidnes@runit.sintef.no's message of Tue, 06 Jun 1995 23:06:02 +0200 <199506062106.XAA00201@kolibri.runit.sintef.no> Subject: PIM configuration FAQ? >> If this can be redone, I would suggest using a syntax which is >> somewhat more similar to the ordinary IP redistribution syntax >> for this function. We avoided this because the capability is really not unicast redistribution. If you redistribute DVMRP routes into your IGP your unicast packets will take that path. You don't want unicast packets taking an MBONE path. We specifically didn't want to mix DVMRP unicast routing with "router" subcommands. The redistribution, as you term it, goes one way. Unicast routes (from the unicast routing table) where there are multicast sources, are injected into DVMRP. If transitivity of MBONE routes through a regular IGP cloud is required, you must tunnel across it or explicitly list on the other side(s) what routes you want to propagate. Dino From list-mgr@ISI.EDU Tue Jun 6 08:10:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 15:11:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 15:10:57 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 15:10:57 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14490(4)>; Tue, 6 Jun 1995 15:10:43 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 6 Jun 1995 15:10:39 -0700 To: Sean Doran Cc: mbone, deering@parc.xerox.com Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: smd's message of Tue, 06 Jun 95 09:59:00 -0800. <95Jun6.125903-0400_edt.20696+341@chops.icp.net> Date: Tue, 6 Jun 1995 15:10:24 PDT Sender: Steve Deering From: Steve Deering Message-Id: <95Jun6.151039pdt.75270@digit.parc.xerox.com> > From: Sean Doran > > No, what is happening here is that a bunch > of people who are lacking some understanding > of how the Internet works at the packet-forwarding > level are now being told that their favourite > toys are breaking things. > > On congested international links, CU-SEEME is > a large-scale denial-of-service attack with a pretty > user-interface. Same could be said about WWW browsers, only more so. Are you ready to ban those too? Steve From list-mgr@ISI.EDU Wed Jun 7 18:38:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 15:40:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 15:40:12 -0700 Received: from mail.mel.aone.net.au by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 15:40:11 -0700 Received: from ipx.office.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by mail.mel.aone.net.au (8.6.11/8.6.11) with ESMTP id IAA23151; Wed, 7 Jun 1995 08:40:09 +1000 Received: from ipx.office.bne.aone.net.au (ggm@ipx.office.bne.aone.net.au [203.12.179.65]) by ipx.office.bne.aone.net.au (8.6.11/8.6.12) with ESMTP id IAA08907; Wed, 7 Jun 1995 08:39:52 +1000 To: Paul Harrington Cc: Jon Crowcroft , mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 1995 14:01:47 +0100." <9506061303.AA11015@tamdhu.dcs.st-andrews.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <8873.802478283.1@ipx.office.bne.aone.net.au> Date: Wed, 07 Jun 1995 08:38:03 +1000 Message-Id: <8875.802478283@ipx.office.bne.aone.net.au> From: George Michaelson This is bandwidth and not volume related IMNSHO. absolute bitcounts (depth of bucket filled/emptied) are less important than RATE of consumption in matters of congestion. With time-dependant data, isn't that especially true? Perhaps this is a misunderstanding of what 'volume charging' means. Down here, its bitcount. -George From list-mgr@ISI.EDU Tue Jun 6 08:49:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 15:50:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 15:49:31 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 15:49:29 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14532(3)>; Tue, 6 Jun 1995 15:49:18 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 6 Jun 1995 15:49:11 -0700 To: Sean Doran Cc: mbone, deering@parc.xerox.com Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: smd's message of Tue, 06 Jun 95 13:11:38 -0800. <95Jun6.161142-0400_edt.20696+348@chops.icp.net> Date: Tue, 6 Jun 1995 15:49:06 PDT Sender: Steve Deering From: Steve Deering Message-Id: <95Jun6.154911pdt.75270@digit.parc.xerox.com> Sean, > Uh huh, and when everyone with an ISDN line is doing voice+video > to his or her friends, you expect this to be used for serious > stuff as opposed to further nifty ways of using the Internet > for sex-on-demand? I expect it to be used for serious stuff and not-so-serious stuff, just like TCP-based traffic, and telephone traffic, and TV traffic, and every other form of human communication. My point is that I don't want the service providers making value judgements about the contents of users' packets based on what transport headers they carry. > There is a simple way to turn the bias towards TCP on its > head, and that is to tell your various sales teams that you > are willing to take significant cuts in TCP goodput in favour > of UDP stuff, MBONE or otherwise. I don't want to turn the bias towards TCP on its head; I want to eliminate bias as much as possible. That's why I'm advocating (an approximation of) fair queueing instead of protocol discrimination. > Send me a copy of any such agreement you come up with. Your sarcasm and condescending style of discourse probably do more harm than good to your cause, whatever that cause may be. Steve From list-mgr@ISI.EDU Wed Jun 7 03:53:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 15:54:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 15:53:16 -0700 Received: from fac.anu.edu.au (durras.anu.edu.au) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 15:53:13 -0700 Received: by fac.anu.edu.au (4.1/SMI-4.0) id AA13835; Wed, 7 Jun 95 08:53:11 EST Date: Wed, 7 Jun 95 08:53:11 EST From: gremarth@fac.anu.edu.au (Michael Greenhalgh) Message-Id: <9506062253.AA13835@fac.anu.edu.au> To: mbone Subject: unsubscribe unsubscribe From list-mgr@ISI.EDU Wed Jun 7 19:18:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 16:19:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 16:19:02 -0700 Received: from munnari.OZ.AU by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 16:18:59 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13730; Wed, 7 Jun 1995 09:18:31 +1000 (from kre@munnari.OZ.AU) To: Steve Deering Cc: Sean Doran , mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 1995 15:49:06 PDT." <95Jun6.154911pdt.75270@digit.parc.xerox.com> Date: Wed, 07 Jun 1995 09:18:25 +1000 Message-Id: <2390.802480705@munnari.OZ.AU> From: Robert Elz Date: Tue, 6 Jun 1995 15:49:06 PDT From: Steve Deering Message-ID: <95Jun6.154911pdt.75270@digit.parc.xerox.com> > There is a simple way to turn the bias towards TCP on its > head, I don't want to turn the bias towards TCP on its head; I want to eliminate bias as much as possible. Is there a need for affirmative action for UDP ? kre (I'm joking!) From list-mgr@ISI.EDU Tue Jun 6 09:45:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 16:47:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 16:46:04 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 16:46:02 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14431(2)>; Tue, 6 Jun 1995 16:45:50 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 6 Jun 1995 16:45:45 -0700 To: mbone Cc: deering@parc.xerox.com Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Date: Tue, 6 Jun 1995 16:45:30 PDT Sender: Steve Deering From: Steve Deering Message-Id: <95Jun6.164545pdt.75270@digit.parc.xerox.com> Thought I should also mention that I am *not* defending the CU-SeeMe design (or the WWW design, for that matter). I think that CU-SeeMe's use of replicated unicasts, rather than IP multicast, to achieve multi-destination delivery is very undesirable. However: - I don't put the blame for that on the users. I think much of the blame belongs to Apple for not making available multicast- capable version of MacTCP (yes, I know that CU-SeeMe also runs on PCs, but the "bad habit" of using replicated unicasts seems to have been picked up during the development of CU-SeeMe on Macs). - The issue of using replicated unicasts is orthogonal to the issue of uncontrolled UDP traffic consuming link resources. For multi-destination delivery, regardless of how its accomplished, how to do good flow control is much more complicated than "just do what TCP does": - end-to-end acknowledgement schemes don't scale well to large multicast groups (the "ack implosion" problem), and - it would be preferable for some applications not to have to limit senders to the rate of the slowest receiver or the slowest branch of the multicast tree, but that means accepting the fact that some links or receivers will be overrun, and sensible packet dropping inside the network will be necessary. This is a very active area of ongoing research. - Adding mechanisms to the routers to prevent any one source from monopolizing the bandwidth of a link seems only sensible to me, whether or not real-time applications become "well behaved", if for no other reason than to defend the networks from buggy or malicious programs. Since detecting whether or not packets are a result of bugs or malice is unlikely to be possible in a router, I suggest fair sharing among all active sources. And once you have that, the right incentives are in place to cause the application writers to make the best use of whatever share of bandwidth is available at a particular time over a particular path. This is also not to say the fair queueing is trivial -- there are hard issues concerning the granularity of sharing (per source? per subscriber site? per connection/session?) and the prevention of cheating by masquerading as multiple sources, sites, connections, whatever. My hunch, though, is that these are second-order concerns -- *any* form of fair queueing would be much better than FIFO. Steve From list-mgr@ISI.EDU Tue Jun 6 10:10:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 17:11:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 17:10:35 -0700 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 17:10:34 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA17075; Tue, 6 Jun 95 17:10:25 PDT Message-Id: <9506070010.AA17075@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 Jun 1995 17:10:29 -0700 To: mbone From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: EUnet Cu-SeeMe Policy - missing something I believe that I have read most of what has shown up on the list on this very interesting topic. One thing that I didn't see is any discussion of sourcing vs. sinking. When the policy says: >User Organisations must therefore make written requests to >EUnet, and receive written confirmation that EUnet will allow > such usage, in advance of using such Video / Audio >applications across the Internet. is it referring to sourcing Cu-SeeMe or MBONE tool audio/video (whiteboard, Web multicast, ...) or is it also including users sinking such transmissions? Namely, must users viewing such transmissions get written permission before doing so? If not, isn't the bandwidth "hogging" still going to happen on EUnet, but just from other sources? If so, it seems a policy with some very serious consequences for the users. On a separate but related topic - in all the discussion about the relative merits or demerits of audio/video in terms of value, I would hope that the value of multicast in more general terms as a bandwidth saving mechanism is not lost. It is perhaps unfortunate that UDP is the only way we have currently to multicast (corrections solicited). Perhaps this makes sense with the early emphasis of multicast for real time multimedia (the MBone tools, etc.). I guess Usenet news distribution might qualify as a non-UDP "multicast" application, but it is not (yet) making use of the MBone infrastructure to my knowledge. I do believe that a "TCP" multicast is technically practical that would eliminate the UDP vs. TCP aspect of this discussion (at the cost of some overhead that perhaps the real time traffic could not accept). I described such a scheme in my paper at the last WWW conference: http://www-atp.llnl.gov/atp/papers/HRM/HRM.html --Jed http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Tue Jun 6 10:17:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 17:18:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 17:17:30 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 17:17:29 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14518(1)>; Tue, 6 Jun 1995 17:17:22 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 6 Jun 1995 17:17:17 -0700 To: Havard.Eidnes@runit.sintef.no Cc: van@ee.lbl.gov, cwe@it.kth.se, dino@cisco.com, mbone, flag@it.kth.se, deering@parc.xerox.com Subject: Re: PIM configuration FAQ? In-Reply-To: Havard.Eidnes's message of Tue, 06 Jun 95 14:06:02 -0800. <199506062106.XAA00201@kolibri.runit.sintef.no> Date: Tue, 6 Jun 1995 17:17:16 PDT Sender: Steve Deering From: Steve Deering Message-Id: <95Jun6.171717pdt.75270@digit.parc.xerox.com> > I won't bore you with why I think PIM (sparse mode, of course ;-) > is much better than the current incarnation of DVMRP, suffice it > to say that the fact that PIM is integrated in ordinary routers > probably contributes the most. Tunnelled solutions never really > know the underlying topology of the network and this can have > some highly undesireable effects in certain configurations. If all the routers in the Internet supported PIM, I might agree with you. But until they all at least support *some* IP multicast routing protocol, we have to use tunnels and "unordinary routers" to enable people to get on the MBone and to keep the MBone connected. And if we just turn off the MBone until all the routers are upgraded, that upgrade will never happen. DVMRP is graduate student programming project that was never intended to be used in a network of the size and geographic scope of the MBone. Although the author knew less then than he does now about routing in the Internet, he has never claimed that DVMRP is the answer to global multicast routing. > I freely admit not to know all the details about the proposed > two-level DVMRP (I did at least attend Van's presentation of it > at the San Jose IETF), but running the MBone on essentially > 2-level RIP appear to me to be a kludge, no less. Yep. A kludge we need to do to keep the MBone alive while the non-kludges are being designed and debugged. Steve From list-mgr@ISI.EDU Tue Jun 6 12:26:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 19:31:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 19:26:41 -0700 Received: from guest.apple.com by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 19:26:40 -0700 Received: from max1.atg.apple.com by guest.apple.com with SMTP (5.64/8-Feb-1993-eef) id AA11744; Tue, 6 Jun 95 19:26:18 PDT for mbone@ISI.EDU Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 Jun 1995 19:26:20 -0700 To: Steve Deering , mbone From: max@guest.apple.com (Mark Q. Maxham) Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications > - I don't put the blame for that on the users. I think much of > the blame belongs to Apple for not making available multicast- > capable version of MacTCP While it's true that Apple has been dragging its feet about supporting UDP multicast, IMHO you can't lay the bulk of the blame there. The vast majority of CUSM users don't have immediate access to the MBone (meaning a multicast-capable router on their subnet). I speak from experience. I also suspect that quite a bit of CUSM traffic is point-to-point anyway and would not benefit from multicast. FYI (obligatory product plug), Apple's conferencing system software ("QuickTime Conferencing") has a bandwidth-management scheme which is highly sensitive to packet loss and thus should not clobber anybody's link. The bad side (from my biased standpoint) of that is that in being a better net.citizen its user- perceived performance can compare poorly to network blasters. QTC will also use IP multicast as soon as Apple releases that stack (it does exist :-]). Rumor has it that some sort of MBone tools will be released about the same time. max and uh you probably shouldn't quote me on that. From list-mgr@ISI.EDU Tue Jun 6 18:58:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 19:59:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 19:58:47 -0700 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 19:58:46 -0700 Received: from [132.236.236.62] (CU-DIALUP-0220.CIT.CORNELL.EDU [132.236.236.62]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id WAA00901 for ; Tue, 6 Jun 1995 22:58:39 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 Jun 1995 22:58:51 -0400 To: mbone From: Scott W Brim Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Skipping the exaggerations & manipulative hyperbole ... At 08:34 06/06/95, Steve Deering wrote: >Relying only on the good behavior of end hosts to keep your network working >seems awfully foolish, in today's soon-to-be-if-not-already-PC-dominated >Internet. Hear him, ye people! CU-SeeMe only sends when someone is watching or listening, so it won't invade your network unless your users want it. Instead of throwing people off if they use more resources than you would like, charge them for what they want you to provide, and use the money to improve your infrastructure. Good luck blocking users! "The tree desires peace, but the wind will not subside", or whatever it was Mao said. I won't say that CU-SeeMe has the best resource management scheme ever -- but it's quite polite for UDP. Its behavior approximates the equivalent of a TCP slow-start scheme on a congested path losing 1 out of every 20 packets, steady state. Just so you know, the latest CU-SeeMe allows the recipient to set his/her receive rate, so you can tell your users what their maximum aggregate receive rate should be. Per-link rate controls are a good idea, and I hope that the inter-reflector links will have per-link, per-reflector and per-group controls. (Apologies for all the hyphens.) ...Scott From list-mgr@ISI.EDU Tue Jun 6 17:40:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 20:45:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 20:40:33 -0700 Received: from everest.cclabs.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 20:40:32 -0700 Received: from sgi17.phlab.missouri.edu (sgi17.phlab.missouri.edu [128.206.115.47]) by everest.cclabs.missouri.edu (8.6.12/8.6.6-Arete-2) with SMTP id WAA28088; Tue, 6 Jun 1995 22:40:28 -0500 Date: Tue, 6 Jun 1995 22:40:28 -0500 (CDT) From: "Paul 'Shag' Walmsley" X-Sender: ccshag@sgi17.phlab.missouri.edu To: jed@llnl.gov Cc: mbone Subject: Re: EUnet Cu-SeeMe Policy - missing something In-Reply-To: <9506070010.AA17075@ocfmail.ocf.llnl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995 jed@llnl.gov wrote: > multimedia (the MBone tools, etc.). I guess Usenet news > distribution might qualify as a non-UDP "multicast" application, > but it is not (yet) making use of the MBone infrastructure to > my knowledge. This is somewhat off the topic, but is anyone working on multicast NNTP? - Paul "Shag" Walmsley "Praise and blame alike mean nothing." -- Virginia Woolf From list-mgr@ISI.EDU Tue Jun 6 20:05:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 21:12:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 21:05:50 -0700 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 21:05:49 -0700 Received: from [132.236.236.94] (CU-DIALUP-0320.CIT.CORNELL.EDU [132.236.236.94]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id AAA04972; Wed, 7 Jun 1995 00:05:36 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 Jun 1995 00:05:49 -0400 To: Steve Deering From: Scott W Brim Subject: Re: PIM configuration FAQ? Cc: mbone At 17:17 06/06/95, Steve Deering wrote: >Yep. A kludge we need to do to keep the MBone alive while the non-kludges >are being designed and debugged. Especially, please, non-kludge up how protocols should interact with each other, instead of trying to create the Universal Protocol. ...Scott -- "Roads? Where we're going we won't need ... roads!" -- Dr. Emmett L. Brown From list-mgr@ISI.EDU Sun Jun 7 06:15:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 23:29:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 23:24:29 -0700 Received: from flop.mcom.com by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 6 Jun 1995 23:24:28 -0700 Received: (from news@localhost) by flop.mcom.com (8.6.9/8.6.9) id XAA13627; Tue, 6 Jun 1995 23:15:10 -0700 To: mbone Path: neon.netscape.com!dmose From: dmose@neon.netscape.com (Dan Mosedale) Newsgroups: mcom.list.mbone Subject: multicast news propagate (was Re: EUnet Cu-SeeMe Policy - missing something) Date: 7 Jun 1995 06:15:09 GMT Organization: Netscape Communications Corporation Lines: 19 Message-Id: <3r3g5d$d9p@flop.mcom.com> References: <9506070010.AA17075@ocfmail.ocf.llnl.gov> Nntp-Posting-Host: neon.netscape.com ccshag@cclabs.missouri.edu (Paul 'Shag' Walmsley) writes: > On Tue, 6 Jun 1995 jed@llnl.gov wrote: > > > multimedia (the MBone tools, etc.). I guess Usenet news > > distribution might qualify as a non-UDP "multicast" application, > > but it is not (yet) making use of the MBone infrastructure to > > my knowledge. > > This is somewhat off the topic, but is anyone working on multicast NNTP? > ftp.uu.net:/networking/news/muse has a PostScript Usenix paper and code. -- Dan Mosedale Systems Exorcist dmose@netscape.com Netscape Communications Corp. From list-mgr@ISI.EDU Wed Jun 7 11:46:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 00:48:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 00:46:15 -0700 Received: from ruin.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 00:46:12 -0700 Received: by ruin.informatik.uni-Bremen.de (8.6.10/20.9.94cl) id JAA06636 Wed, 7 Jun 1995 09:46:07 +0200 Date: Wed, 7 Jun 1995 09:46:07 +0200 From: Carsten Bormann Message-Id: <199506070746.JAA06636@ruin.informatik.uni-Bremen.de> To: mbone Cc: dmose@neon.netscape.com, ccshag@cclabs.missouri.edu, jo@cs.tu-berlin.de, nilss@cs.tu-berlin.de, torsten@prz.tu-berlin.de In-Reply-To: <3r3g5d$d9p@flop.mcom.com> (dmose@neon.netscape.com) Subject: Re: multicast news propagate (was Re: EUnet Cu-SeeMe Policy - missing something) > > This is somewhat off the topic, but is anyone working on multicast NNTP? > > ftp.uu.net:/networking/news/muse has a PostScript Usenix paper and > code. While MUSE (distribution of news articles as UDP datagrams) was an interesting experiment, we believe that Netnews multicasting would benefit from a scalable error-controlled transport protocol such as MTP-2. We are in the process of assessing the utility of MTP-2 for news distribution, and we may very well come up with a prototype for this in the next few months (after the MTP-2 alpha release). Ob-mbone: Would distributing Netnews be considered appropriate use of the Mbone? I would try to make use of MTP-2's rate limiting functionality; 64 kbit/s should suffice for a global newsfeed. Gruesse, Carsten From list-mgr@ISI.EDU Wed Jun 7 09:59:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 01:05:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 00:59:53 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 00:59:51 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 7 Jun 1995 00:59:47 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Jun 1995 08:59:31 +0100 To: Per Gregers Bilse Cc: mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 95 16:31:18 +0100." <199506061431.AA06074@jotun.EU.net> Date: Wed, 07 Jun 95 08:59:26 +0100 Message-Id: <748.802511966@cs.ucl.ac.uk> From: Jon Crowcroft >This is extremely difficult. Not least because even if you >have pure volume charge, 95% of the traffic gets dropped on the >provider side of the connection. You can't send a bill for several >hundred kbits of traffic to a dial-up modem user. look - this is balderdash access fro mdial up is limited to the dial up link speed - if you have n dial up customers, and don't engineer your net for at least 1% of n, you are not doing things right also note that you don't udnerstand TCP if youi think TCP gives a far share of service....t is not fair to people with different RTTs sharing the same bottleneck link >What is being addressed is the threat of incidents of serious >congestion, caused largely by a single, very ill-behaved >application. an application that NEEDS a minimum data rate (as does TCP for example, as i pointed out before), is NOT badly behaved.... >One thing "you" (the generic "you") want to look for in a service >provider is some indication that they stay on top of things, and do >at least something to make sure your connection is reliable and can >be said to generally work. That includes laying down some general >rules, which is generally a sign of a civilized society or some such >thing. You will not want to be connected to a provider that does >little else than collect your money. the Internet service is IP - you cannot dictate end user protocols to people - you will _always_ get got by something....even if its only a big sites DNS traffic....or multi-tcp connection HTTP clients like netscape....the SYN/SYNACK packets between different TCP connections are not subject to slow start! if someone sets up a netscape for 100 connections, you will get 100 separate well behaved TCPs at once - but itll still be 100 packets in a burst... if you want to dicate good behaviour, you need to run an admission test for traffic - c.f. RSVP and cisco priority queues or similar it is NOT up to customers to provide traffic control....it just aint a good idea as daniel karrenberg said though, adaptive applications are a good idea, but that doesn't help you with the _bare necessity_ bandwidth requirement for anythign that is interactive, and especially itnerative audio and/or video (which does nbelong on mbone:-) by the way, i don't udnerstand why yo uthink people are attacking EUNet - i have no axe to grind about any provider .....i have an attitude problem that says "the subscriber is always right" cheers jon From list-mgr@ISI.EDU Wed Jun 7 12:09:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 01:16:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 01:09:50 -0700 Received: from eunet.EU.net (ns2.EU.net) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 01:09:49 -0700 Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id KAA01795; Wed, 7 Jun 1995 10:09:47 +0200 Received: by jotun.EU.net id AA08522 (5.67a/IDA-1.5); Wed, 7 Jun 1995 10:09:47 +0200 Message-Id: <199506070809.AA08522@jotun.EU.net> From: Per Gregers Bilse Date: Wed, 7 Jun 1995 10:09:46 +0200 In-Reply-To: <95Jun6.151039pdt.75270@digit.parc.xerox.com> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Steve Deering Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone On Jun 6, 15:10, Steve Deering wrote: > > On congested international links, CU-SEEME is > > a large-scale denial-of-service attack with a pretty > > user-interface. > > Same could be said about WWW browsers, only more so. Are you ready to ban > those too? WWW browsers and WWW bandwidth consumption is fundamentally different from CU-SeeMe; the difference is largely one of TCP vs UDP. Note that nobody is talking about banning these applications; rather, that the issue be discussed first. What started this thread was complaints received from users of a POP in Antwerpen. One particular user was constantly running CU-SeeMe, taking "home" well above 100 kbit steady-state traffic. No disrespect, but Antwerpen is a smallish place in the North West corner of Belgium and there simply wasn't infrastructure in place to support up to a couple hundred kilobits of essentially ill-behaved traffic. "Get more bandwidth" some will say; sure, but who is supposed to pay for it? There are few technical means and practically no contractual means whereby you can charge a dial-up user for several hundred kilobits of international traffic. We can go and try to change that, but as previously noted this cannot take place "overnight". And if we do it, use of CU-SeeMe would cease instantly. Why? Well, why is it that we should be able to provide N kbits transatlantic bandwidth at significantly lower cost than one or two ISDN calls? We have to buy our bandwidth; we will have some better economies than your favourite telco, but the biggest budget line is still international bandwidth. Supporting CU-SeeMe users in Europe, taking home video from the US, essentially costs the same as them making one or two telephone calls to the US. Generally, the comments on this list have come from people whose points of reference is a development lab with campus fibre, and maybe some generously provisioned T3s. This is also the environment where CU-SeeMe was developed. This environment has practically nothing in common with the global production Internet and I would like people to bear this in mind. -- === ___ === Per G. Bilse, Mgr Network Operations Ctr === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Wed Jun 7 10:12:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 01:20:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 01:15:48 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 01:15:47 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 7 Jun 1995 01:15:28 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Jun 1995 09:12:50 +0100 To: Sean Doran Cc: bilse@eu.net, mbone, J.Crowcroft@cs.ucl.ac.uk Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Tue, 06 Jun 95 12:49:52 EDT." <95Jun6.125000-0400_edt.20696+340@chops.icp.net> Date: Wed, 07 Jun 95 09:12:41 +0100 Message-Id: <864.802512761@cs.ucl.ac.uk> From: Jon Crowcroft >Ob.MBONE: if anyone is actively looking at testing PIM in >the near future (you know who you are likely to be) on a big >backbone with lots of DVMRP in place, I'd love it if you'd >drop me a note... Sean, we have abandoned testing PIM on the European 34Mbps backbone as it cannot interwork with DVMRP clouds using the pruning mechanism since cisco didn't implement that bit of DVMRP in their PIM/DVMRP stub... sorry - can't help advice: pressure cisco to fix the DVMRP stub...talk to dino... jon From list-mgr@ISI.EDU Wed Jun 7 12:24:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 01:26:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 01:24:56 -0700 Received: from eunet.EU.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 01:24:55 -0700 Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id KAA02620; Wed, 7 Jun 1995 10:24:54 +0200 Received: by jotun.EU.net id AA08557 (5.67a/IDA-1.5); Wed, 7 Jun 1995 10:24:53 +0200 Message-Id: <199506070824.AA08557@jotun.EU.net> From: Per Gregers Bilse Date: Wed, 7 Jun 1995 10:24:53 +0200 In-Reply-To: <748.802511966@cs.ucl.ac.uk> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Jon Crowcroft Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone On Jun 7, 8:59, Jon Crowcroft wrote: > >This is extremely difficult. Not least because even if you > >have pure volume charge, 95% of the traffic gets dropped on the > >provider side of the connection. You can't send a bill for several > >hundred kbits of traffic to a dial-up modem user. > > look - this is balderdash > > access fro mdial up is limited to the dial up link speed - if you have No, it is not. That is exactly the problem. This is what happens: Source ---- n*80 kbits/sec ------ T/S --- 14.4k --- user There will be 80kbits (default) sent per open window. Nearly everything gets dropped on the floor in the terminal server. And we as a service provider end up carrying around huge amounts of data, only to eventually throw it out, with little or no way of covering our costs. > people - you will _always_ get got by something....even if its only a > big sites DNS traffic....or multi-tcp connection HTTP clients like > netscape....the SYN/SYNACK packets between different TCP connections are not subject to slow start! if someone sets up a netscape for 100 connections, > you will get 100 separate well behaved TCPs at once - but itll still > be 100 packets in a burst... This presents no problem whatsoever, compared to CU-SeeMe. A DNS loop at full speed is unpleasant, but still doesn't come anywhere near close. > by the way, i don't udnerstand why yo uthink people are attacking > EUNet - i have no axe to grind about any provider .....i have an > attitude problem that says "the subscriber is always right" The general tone of the first messages from you and Graeme Wood suggested this; my apologies if I'm wrong. Generally, please note that what we're trying to address is an unpleasant problem; there is no philosophy, no speculation, religion, or anything else like that at play -- only an unpleasant problem, which is why we're spending time on it. -- === ___ === Per G. Bilse, Mgr Network Operations Ctr === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Wed Jun 7 12:47:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 01:53:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 01:47:41 -0700 Received: from eunet.EU.net (ns2.EU.net) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 01:47:39 -0700 Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id KAA03668; Wed, 7 Jun 1995 10:47:38 +0200 Received: by jotun.EU.net id AA08664 (5.67a/IDA-1.5); Wed, 7 Jun 1995 10:47:37 +0200 Message-Id: <199506070847.AA08664@jotun.EU.net> From: Per Gregers Bilse Date: Wed, 7 Jun 1995 10:47:37 +0200 In-Reply-To: <9506070010.AA17075@ocfmail.ocf.llnl.gov> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: EUnet Cu-SeeMe Policy - missing something Cc: mbone On Jun 6, 17:10, James E. [Jed] Donnelley wrote: > On a separate but related topic - in all the discussion about > the relative merits or demerits of audio/video in terms of value, I > would hope that the value of multicast in more general terms as a > bandwidth saving mechanism is not lost. The issue, at least from our side, is not related to any perceived value of A/V data vs other data -- we couldn't care less. Rather, it is mostly a network engineering and operational problem caused by one particular application. > I do believe that a "TCP" multicast is technically practical that > would eliminate the UDP vs. TCP aspect of this discussion > (at the cost of some overhead that perhaps the real time traffic > could not accept). I described such a scheme in my paper at CU-SeeMe traffic isn't terribly multicast'ed anyway, so simply using unicast TCP (with proper rate adaption in the application) would be a major win over over a hailstorm of UDP packets. This issue has been discussed extensively on the CU-SeeMe list -- believe it or not, but there's a large number of CU-SeeMe users who are in complete agreement with our concerns -- and somebody did some real comparisons of UDP vs TCP for delivery. These test not stand up to an in-depth lab inspection, but were on the other hand done in the exact setting where by far the vast majority of CU-SeeMe traffic takes place. On May 5, 14:29, Sean Foderaro wrote: > To: > Subject: Re: Melting the Internet? > > I've now run some tests on the real-time large bandwidth performance > of TCP and UDP. > > I sent 10,000 128 byte packets from one machine to another and > measured the time it took for each packet to arrive. In the case > of UDP I measured how many packets were dropped. (From the user's > perspective the TCP protocol never drops any packets). > > > > In the tables below there are the following entries: > packets loss - 10,000 packets were sent, this is how many > didn't make it. > > time to receive - number of seconds between the first packet > received and the last one. > > avg packet delay - avg number of seconds between the time a packet > was sent and it was received The value is rounded down > to the nearest integer. > > max packet delay - the worse packet delay (in seconds) for all the > packets received. > > net transmission rate - the number of packets received divided by > the number of seconds to receive them. > > error adj rate - the net transmission rate adjusted for packet loss. > If you receive 1000 packets/second but 50% of the > packets originally sent you were lost, then roughly > speaking the sender would have to send each packet > twice in order for you to see it. So 1000 * .50 = > an "error adj rate" of 500 packets / second. > This is a measure of information flow rather than > just data flow (which in the net transmission rate). > > real time performance - how I'd describe the real-time performance > of the link based mainly on the Average packet delay. > > In the examples below Machine A is always sending to Machine B. > > Machine A ------------ Machine B > 16mhz sun4 10mbps 50mhz sun4 > > UDP TCP > packets loss 7 (.07%) 0 > time to receive 8 6 > avg packet delay > max packet delay 1 1 > net transmission rate 1249 1666 > error adj rate 1236 1666 > real time performance great great > > note: here the two protocols works identically since the receiver > can keep up with the transmitter. The somewhat slower time > for UDP may be due to the fact that I've got to select() > before I recvfrom() since the packet I'm waiting for may > have been dropped and I don't want to hang forever. > > > > Machine A ------------- Machine B > 50mhz sun4 10mbps 16mhz sun4 > > UDP TCP > packets loss 6668 (67%) 0 > time to receive 5 5 > avg packet delay 0 0 > max packet delay 1 1 > net transmission rate 666 2000 > error adj rate 444 2000 > real time performance great great > > Note: here the receiver can't keep up. With UDP packets are dropped. > TCP clearly superior. > > > Machine A ------------- Machine X -------------- Machine B > 16mhz sun 10mbps 486/33 115kbps 486/33 > Linux Linux > > > UDP TCP > packets loss 6 0 > time to receive 139 112 > avg packet delay 65 0 > max packet delay 132 1 > net transmission rate 72 89 > error adj rate 72 89 > real time performance horrible great > > Note: Friendly machine X buffers all the UDP packets and slowly > delivers them to Machine B, by which time they are way way > out of date. TCP clearly superior. > > > Machine A ------ 5 hops --- Netblazer --------- 1 hop------- Machine B > sparc II 10-?? mbps 38kbps 10mbps 16mhz sun > > In this scenario we go from a site at UC Berkeley, out onto the > internet and then into my machine though a Netblazer run by UUnet. > > > UDP TCP > packets loss 9602 (96%) 0 > time to receive 20 497 > avg packet delay 8 0 > max packet delay 15 8 > net transmission rate 20 20 > error adj rate 0.8 20 > real time performance bad good > > Note: Overall UDP and TCP both manage to get the same number of > packets through the net. The difference is for UDP the > odds of a packet sent using it getting through is 4% so they > must be retransmitted numerous times in order to > ensure they they make it. The result is that the information > flow is almost nil. The packet delays with UDP are bad as well. > TCP, however, senses the congestion through all of these hops so that > when a TCP packet is permitted to be sent, it is delivered > almost immediately (the average packet delay is less than > a second). TCP is clearly superior.. > > Machine A -------- 19 hops -------------------- Machine B > sparc II 10-??mbps 10-?? mbps sparc 10 > > A machine at UC Berkeley is talking to a machine at Penn State, > both with good internet connectivity. > > UDP TCP > packets loss 5556 0 > time to receive 6 63 > avg packet delay 0 0 > max packet delay 1 2 > net transmission rate 740 158 > error adj rate 328 158 > real time performance great great > > Note; Finally some good news for UDP fans. Both protocols > have excellent real-time performance. UDP gets data sent > faster but loses more than half the packets. > This is, I believe, the target environment for CU-SeeMe. > > > > Conclusions: > In situations where massive amounts of data must be sent > from a faster network to a slower network (or, on the same > network, from a faster machine to a slower machine) then > TCP should be used. > > With TCP you can ask the operating system "Is it ok to send > data now?" and if it says ok then the data you send will be > delivered in a timely fashion (personally I was amazed to see > how well this worked). With UDP all you can do is send the data > and cross your fingers. With TCP you can tell when the data pipe > is clogged and go off and do other useful work. > > TCP offers real-time performance as good as and often much better > than UDP in all situations tested. Over long hauls TCP's data rate > is less than UDP's, however this is mitigated by the fact that > a UDP implementation needs to send extra information on a back channel > in order to deal with the packet loss problem (and, optionally, flow > control to be network-friendly). > > > I wasn't benchmarking CU-SeeMe so it would be improper for me to > claim that this information would apply to CU-SeeMe. > > [If you want to get a copy of my test code, send me email. > It's not pretty but it compiles on Sunos 4.1.3 (gcc) and Linux > and could be made to work on SVR4-like platforms.] > > > > > > >-- End of excerpt from Sean Foderaro -- === ___ === Per G. Bilse, Mgr Network Operations Ctr === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Wed Jun 7 11:15:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 02:16:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 02:16:31 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 02:16:30 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 7 Jun 1995 02:16:15 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Jun 1995 10:15:30 +0100 To: mbone Subject: Re: EUnet Cu-SeeMe Policy - missing something In-Reply-To: Your message of "Wed, 07 Jun 95 10:47:37 +0100." <199506070847.AA08664@jotun.EU.net> Date: Wed, 07 Jun 95 10:15:21 +0100 Message-Id: <1468.802516521@cs.ucl.ac.uk> From: Jon Crowcroft this discussion is clearly being conducted by groups of people with different timespans to their concerns for those with a medium to long term view, can i susgest they subscribe to int-serv or attend the int-serv EG at IETF, which is addressing a lot of these problems.... for example: >The issue, at least from our side, is not related to any perceived >value of A/V data vs other data -- we couldn't care less. Rather, >it is mostly a network engineering and operational problem caused >by one particular application. if a provider were to offer _minimum_ bandwidth to certain classes of traffic, they could charge more to subscribers using that class....this is a basic tenet of the medium term way that one will support anything other than TCP (elastic traffic) TCP is NOT suitable for CU-SeeMe (or any of the mbone applications) since the retransmits cause high and variable delays in delivery, whereas many of the applications actually cope with misorderd and lossy delivery thus _saving bandwidth. TCP is NOT suitable for multicast due to the ACK implosion you get from recipients every time you send a packet - UDP and Multicast _SAVES_ you bandwidth...for these applications again.... however, if a audio/video application persists in the presence of extreme loss (where extreme is usually reasonable defined around 5%), it is obvious that the user is either telepathic, or has gone away....so again, adaptive applications, as well as minimal bandwth guarantees are the order of the day... as to maximum bandwidths, can i sugges that people look at their POP architectures again - the MBone (at least in the UK) enforces a maximum bandwidth limit to all traffic due the rate limiter steve deering has implemtned... cheers jon From list-mgr@ISI.EDU Wed Jun 7 11:18:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 02:20:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 02:19:20 -0700 Received: from mail.physics.ox.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 02:19:17 -0700 Received: from av1.physics.ox.ac.uk by mail.physics.ox.ac.uk with SMTP (5.67b/IDA-1.5-UK-t for ) id AA13001; Wed, 7 Jun 1995 10:18:44 +0100 Date: Wed, 7 Jun 1995 10:18:36 +0100 (BST) From: John Macallister To: mbone Cc: MACALLSTR@v1.ph.ox.ac.uk Message-Id: <950607101836.3080027e@v1.ph.ox.ac.uk> Subject: subscribe subscribe From list-mgr@ISI.EDU Wed Jun 7 17:43:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 06:45:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 06:43:13 -0700 Received: from mailgate.ericsson.se by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 06:43:09 -0700 Received: from eua.ericsson.se (eua.ericsson.se [134.138.132.16]) by mailgate.ericsson.se (8.6.11/1.0) with SMTP id PAA26224 for ; Wed, 7 Jun 1995 15:43:05 +0200 Received: from ms.eua.ericsson.se by eua.ericsson.se (4.1/EUA-2.1) id AA11356; Wed, 7 Jun 95 15:43:03 +0200 Received: from euas78c16.eua.ericsson.se by ms.eua.ericsson.se (4.1/MS-2.1) id AA22407; Wed, 7 Jun 95 15:43:02 +0200 From: Jakob.Ellerstedt@eua.ericsson.se (Jakob Ellerstedt) Received: by euas78c16.eua.ericsson.se (5.x/client-1.3) id AA22380; Wed, 7 Jun 1995 15:43:01 +0200 Date: Wed, 7 Jun 1995 15:43:01 +0200 Message-Id: <9506071343.AA22380@euas78c16.eua.ericsson.se> To: mbone Subject: Unsubscribe X-Sun-Charset: US-ASCII Unsubscribe From list-mgr@ISI.EDU Wed Jun 7 06:15:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 07:22:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 07:21:35 -0700 Received: from photon.magnus.acs.ohio-state.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 07:21:33 -0700 Received: by photon.magnus.acs.ohio-state.edu (8.6.10/4.940426) id KAA19050; Wed, 7 Jun 1995 10:15:50 -0400 Date: Wed, 7 Jun 1995 10:15:50 -0400 From: Harpal Chohan Message-Id: <199506071415.KAA19050@photon.magnus.acs.ohio-state.edu> To: B.Anderson@lut.ac.uk, will@info.ic.gc.ca Subject: Re: cu-seeme and the Mbone Cc: CU-SEEME-L@cornell.edu, dschluss@engin.umich.edu, mbone +The latest version (3.01 ?) of Cornell University's CU-SeeMe reflector Version 3b3 as far as I know. +will 'listen' for packets (audio and video) on a specified multicast +address and then reflect them in a unicast manner to any connected +CU-SeeMe clients. So it does exactly what you both want. It's all in the +reflector README. However, the video on that multicast address from an mbone session most likely will not be in CuSeeMe format. I believe the original poster was suggesting a Kluge where he was displaying the non-cuseeme format video on the screen, and then using screen grab with another transmitter to feed it in CuSeeMe format into the reflector. Does anyone have a better way of doing this, or are there any plans for the reflector to handle the conversion? -h From list-mgr@ISI.EDU Wed Jun 7 07:24:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 08:51:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 08:35:58 -0700 Received: from jeeves.va.pubnix.com by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 08:35:56 -0700 Received: from arrow.va.pubnix.com by jeeves.va.pubnix.com with ESMTP id LAA29917; Wed, 7 Jun 1995 11:24:59 -0400 Received: from localhost by arrow.va.pubnix.com with SMTP id LAA16233; Wed, 7 Jun 1995 11:24:59 -0400 Message-Id: To: Carsten Bormann Cc: mbone, dmose@neon.netscape.com, ccshag@cclabs.missouri.edu, jo@cs.tu-berlin.de, nilss@cs.tu-berlin.de, torsten@prz.tu-berlin.de Subject: Re: multicast news propagate (was Re: EUnet Cu-SeeMe Policy - missing something) In-Reply-To: Your message of "Wed, 07 Jun 1995 09:46:07 +0200." <199506070746.JAA06636@ruin.informatik.uni-Bremen.de> Date: Wed, 07 Jun 1995 11:24:59 -0400 From: "Kurt J. Lidl" >> > This is somewhat off the topic, but is anyone working on multicast NNTP? >> >> ftp.uu.net:/networking/news/muse has a PostScript Usenix paper and >> code. > >While MUSE (distribution of news articles as UDP datagrams) was an >interesting experiment, we believe that Netnews multicasting would >benefit from a scalable error-controlled transport protocol such as >MTP-2. We are in the process of assessing the utility of MTP-2 for >news distribution, and we may very well come up with a prototype for >this in the next few months (after the MTP-2 alpha release). That's not quite the same conclusion that the authors of the paper came to (I know, I wrote the paper). Building on top a reliable transport doesn't buy you much, in that no machine will be on the net 100% of the time. When it is down, it *still* will miss out on the multicast news during that time period. You still need another "news recovery" mechanism for those missing blocks of news. The major conclusions we came to were that we needed faster RSA signing and compression of the articles, so we could send out mini-batches of articles, say 3 or 4 at a time, and only have to RSA sign the entire lot of them, rather than each individual article getting signed. -Kurt From list-mgr@ISI.EDU Tue Jun 6 19:58:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 08:59:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 08:59:25 -0700 Received: from pm054-05.dialip.mich.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 08:59:22 -0700 Received: (from jauderho@localhost) by pm054-05.dialip.mich.net (8.6.11/8.6.9) id XAA06439; Tue, 6 Jun 1995 23:58:33 -0400 Date: Tue, 6 Jun 1995 23:58:33 -0400 (EDT) From: Jauder Ho X-Sender: jauderho@pm054-05.dialip.mich.net To: mbone Cc: mcitsp@umich.edu Subject: nv Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have gotten nv to run on a linux box v1.2.8 with the following patch diff -u --recursive --new-file nv-orig/src/Makefile nv/src/Makefile --- nv-orig/src/Makefile Tue Jul 19 04:09:05 1994 +++ nv/src/Makefile Mon Dec 19 19:42:36 1994 @@ -73,6 +73,14 @@ #CFLAGS = -g3 -O2 -DCPV_DECODE -DVIDEOLIVE -DX11GRAB $(INCS) #CPVOBJ = ../cpv/cpv_decode-hp.o +# +# Uncomment and edit these lines for Linux +# Note 1.1.73 or later is required for Multicast to work +# +INCS = -I/usr/X11/include -I/usr/include/tcl +NVLIBS = -L/usr/local/lib -ltk -ltcl -L/usr/X11/lib -lX11 -lm -lXext +CFLAGS = -ansi -O2 -DLITTLE_BITFIELDS -DX11GRAB $(INCS) + OBJS = nv.o nv_init.o nv_decode.o nv_encode.o nv_getmulti.o nv_transform.o \ $(CPVOBJ) cellb_decode.o cellb_encode.o cellb_tables.o \ cuseeme_decode.o cuseeme_encode.o ibmvca_grab.o indigo_grab.o \ hope this helps! From list-mgr@ISI.EDU Wed Jun 7 02:15:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 09:17:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 09:17:32 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 09:17:31 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14595(1)>; Wed, 7 Jun 1995 09:15:41 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 7 Jun 1995 09:15:21 -0700 To: Carsten Bormann Cc: mbone, dmose@neon.netscape.com, ccshag@cclabs.missouri.edu, jo@cs.tu-berlin.de, nilss@cs.tu-berlin.de, torsten@prz.tu-berlin.de, deering@parc.xerox.com Subject: Re: multicast news propagate In-Reply-To: cabo's message of Wed, 07 Jun 95 00:46:07 -0800. <199506070746.JAA06636@ruin.informatik.uni-Bremen.de> Date: Wed, 7 Jun 1995 09:15:12 PDT Sender: Steve Deering From: Steve Deering Message-Id: <95Jun7.091521pdt.75270@digit.parc.xerox.com> > Would distributing Netnews be considered appropriate use of the Mbone? Certainly, if it reduces the amount of unicast carriage of the same news over the same links. Steve From list-mgr@ISI.EDU Wed Jun 7 09:22:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 10:24:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 10:23:01 -0700 Received: from mail02.mail.aol.com by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 10:23:00 -0700 Received: by mail02.mail.aol.com (1.37.109.11/16.2) id AA240465779; Wed, 7 Jun 1995 13:22:59 -0400 Date: Wed, 7 Jun 1995 13:22:59 -0400 From: JDaly0817@aol.com Message-Id: <950607132258_64268360@aol.com> To: mbone Subject: unsubscribe unsubscribe From list-mgr@ISI.EDU Wed Jun 7 21:39:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 10:46:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 10:41:22 -0700 Received: from ruin.informatik.uni-bremen.de by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 10:41:13 -0700 Received: by ruin.informatik.uni-Bremen.de (8.6.10/20.9.94cl) id TAA08406 Wed, 7 Jun 1995 19:39:36 +0200 Date: Wed, 7 Jun 1995 19:39:36 +0200 From: Carsten Bormann Message-Id: <199506071739.TAA08406@ruin.informatik.uni-Bremen.de> To: lidl@va.pubnix.com Cc: mbone, dmose@neon.netscape.com, ccshag@cclabs.missouri.edu, jo@cs.tu-berlin.de, nilss@cs.tu-berlin.de, torsten@prz.tu-berlin.de In-Reply-To: (lidl@va.pubnix.com) Subject: Re: multicast news propagate (was Re: EUnet Cu-SeeMe Policy - missing something) > That's not quite the same conclusion that the authors of the paper > came to (I know, I wrote the paper). Building on top a reliable > transport doesn't buy you much, in that no machine will be on the > net 100% of the time. When it is down, it *still* will miss out > on the multicast news during that time period. You still need another > "news recovery" mechanism for those missing blocks of news. I share the conclusion that a "backup" transfer method is needed (while I haven't worked out all the details, I envision that we would continue to use the conventional NNTP network as this backup). A transport that is "reliable" in the sense of covering extended outages is of surprisingly little use in large groups, anyway. I don't share the view that error control would not be useful (particularly if it can be made scalable). The larger your articles (or mini-batches), the lower the probability that all packets of it will arrive. I'm not particularly keen on a distribution method where a random 10 % of the articles arrive a day after the other 90 %. > The major conclusions we came to were that we needed faster RSA signing > and compression of the articles, so we could send out mini-batches of > articles, say 3 or 4 at a time, and only have to RSA sign the entire > lot of them, rather than each individual article getting signed. With MTP-2, we may actually be able to avoid the use of RSA signing for authentication of each article; keyed MD5 could be all we need per message (again, the details aren't all worked out yet). Gruesse, Carsten From list-mgr@ISI.EDU Wed Jun 7 04:01:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 11:02:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 11:01:52 -0700 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 11:01:51 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA25963; Wed, 7 Jun 95 11:01:48 PDT Message-Id: <9506071801.AA25963@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 Jun 1995 11:01:51 -0700 To: mbone From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: EUnet, Cu-SeeMe, MBone, and "multicast TCP" - a proposal regarding Jon Crowcroft's Wed, 07 Jun 95 10:15:21 +0100 comments: >TCP is NOT suitable for CU-SeeMe (or any of the mbone applications) >since the retransmits cause high and variable delays in delivery, >whereas many of the applications actually cope with misorderd and >lossy delivery thus _saving bandwidth. > >TCP is NOT suitable for multicast due to the ACK implosion you get >from recipients every time you send a packet - UDP and Multicast _SAVES_ >you bandwidth...for these applications again.... I think this depends on what one means by TCP in the context of multicast. I think perhaps Jon is imagining using TCP end-end protocol mechanisms on top of IP multicast. In this case I agree completely with the comments above. I don't think it makes sense to use TCP in this way. However, I believe that it would be rather straight forward to use TCP in a "hopwise" manner (i.e. node to node) between mrouted daemons. There are a number of ways to do this. I described one in the paper referenced before: http://www-atp.llnl.gov/atp/papers/HRM/HRM.html Let me mention a slightly different one here that would be more suited toward realtime multimedia communication. What about just replacing the tunnels between mrouteds with TCP connections? Just to clarify a little here, with this approach I imagine the existing UDP packets to be used as is, but just layered on top of TCP connection between the nodes. Each mrouted would be responsible for receiving such packets from each of it's neighbors as quickly as it could (subject to congestion on the line from other TCP etc. traffic). It would then take any packets received and queue them immediately for output on the TCP connections for the appropriate outgoing tunnels. If packets piled up on any outgoing tunnel due to flow control, TCP retransmissions (e.g. due to congestion) or any other reason, the mrouted would throw away some packets. There is a policy here, but it could simply be to throw out the latest packets. Of course more sophisticated priorities could be implemented. Such a scheme would certainly introduce more latency into multicast applications. I am not clear just how much additional latency would be added. Perhaps folks could comment. What is not clear to me is how the time penalty of waiting for TCP acks and TCP processing between tunnel ends would compare with the overheadt of processing the current UDP packets. I think it also relevant to note that some amount of bundling would automatically occur (e.g. as with telnet character transmission) so that as tunnels became congested, larger TCP packets would be sent (up to and beyond the point at which multicast "packets" would be thrown away). It seems to me that such a scheme would certainly go a long way toward eliminating the concerns of the carriers about the "rogue" nature of some current multicast schemes. Whether effective experimentation or "production" of realtime multimedia could be done over such an infrastructure I am not clear about. --Jed http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Wed Jun 7 11:53:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 12:59:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 12:54:19 -0700 Received: from titan.sprintlink.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 12:54:17 -0700 Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id PAA08980; Wed, 7 Jun 1995 15:53:53 -0400 Date: Wed, 7 Jun 1995 15:53:53 -0400 From: Vadim Antonov Message-Id: <199506071953.PAA08980@titan.sprintlink.net> To: J.Crowcroft@cs.ucl.ac.uk, bilse@eu.net Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone Jon Crowcroft wrote: >by the way, i don't udnerstand why yo uthink people are attacking >EUNet - i have no axe to grind about any provider .....i have an >attitude problem that says "the subscriber is always right" Even if he comes to you with a gun and politely asks for free ride? --vadim From list-mgr@ISI.EDU Wed Jun 7 08:17:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 13:17:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 13:17:14 -0700 Received: from mailhost.lanl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 13:17:13 -0700 Received: from wrangler.lanl.gov by mailhost.lanl.gov (8.6.11/1.2) id OAA02396; Wed, 7 Jun 1995 14:17:12 -0600 Received: from sienna.lanl.gov.cdiv-net (sienna.lanl.gov [128.165.113.213]) by wrangler.lanl.gov (8.6.12/8.6.12) with SMTP id OAA24384 for ; Wed, 7 Jun 1995 14:17:11 -0600 Date: Wed, 7 Jun 1995 14:17:11 -0600 From: Andy Martinez Message-Id: <199506072017.OAA24384@wrangler.lanl.gov> To: mbone Subject: unsubscribe unsubscribe From list-mgr@ISI.EDU Wed Jun 7 12:16:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 13:27:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 13:16:53 -0700 Received: from cerc.wvu.edu (cathedral.cerc.wvu.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 13:16:52 -0700 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA09684; Wed, 7 Jun 95 16:16:50 EDT Received: by elk (5.0//ident-1.0) id AA00486; Wed, 7 Jun 1995 16:16:48 -0400 Date: Wed, 7 Jun 1995 16:16:46 -0400 (EDT) From: "Todd L. Montgomery" Subject: Re: EUnet, Cu-SeeMe, MBone, and "multicast TCP" - a proposal To: jed@llnl.gov Cc: mbone In-Reply-To: <9506071801.AA25963@ocfmail.ocf.llnl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1018 Hopwise-reliability will become a mute point as multicast routing becomes integrated into commercial routers. By making multicast hopwise reliable, the real issue of "is my data arriving" is _NOT_ addressed. Only something can be said that "if the mrouter did not drop the data (which can not be assured under heavy load) the data will be sent across the link reliably". Then the problem becomes: 1 - Did the kernel drop the data? (on the receiver or sender) 2 - Did congestion cause _arbitrary_ delays in link transmission? This is quite possible under normal operation. Try running spray to some server running mrouted sometime.... Now consider that this path (from host to mrouter) is not reliable.... Multicast NNTP, IMO, also needs more than reliable multicast, whether this be something high performance like RMP, or lower performance like MTP-2 is another issue. (Probably the best solution for Multicast NNTP in reliability would be a straight NACK policy with Application Layer Framing). -- Todd From list-mgr@ISI.EDU Wed Jun 7 12:44:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 13:44:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 13:44:15 -0700 Received: from davinci.gmu.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 13:44:14 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id QAA06307; Wed, 7 Jun 1995 16:44:14 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199506072044.QAA06307@davinci.gmu.edu> Subject: Not a bug report To: mbone Date: Wed, 7 Jun 1995 16:44:14 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 912 When the Linux version of the vat program was put out, there was a note telling users that it was not fully functional due to an incomplete multicast implementation in Linux's kernel. The note mentioned that it had to do with the loop function. I am now looking at the Winsock stack that comes with Windows 95 and it says that it is fully compliant with the 1.2 Multicast release except for the implementation of IP_MULTICAST_LOOP, which it does not support. Is this the same problem that Linux has? Whether or not it is the same problem, what problems will the non-compliance by Microsoft (with regards to the implementation of this function) cause for any theoretical uses of the mbone in a Windows environment? Michael -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Wed Jun 7 07:07:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 14:09:03 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 14:08:03 -0700 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 14:08:02 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA29716; Wed, 7 Jun 95 14:07:50 PDT Message-Id: <9506072107.AA29716@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 Jun 1995 14:07:53 -0700 To: Todd L. Montgomery From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: EUnet, Cu-SeeMe, MBone, and "multicast TCP" - a proposal Cc: mbone >Hopwise-reliability will become a mute point as multicast routing >becomes integrated into commercial routers. Likely true. This point is further addressed in my paper: http://www-atp.llnl.gov/atp/papers/HRM/HRM.html in section 5 - "Whither Internet Multicasting? " I believe that to some extent this depends on how the load of real time (e.g. multimedia) multicast is accepted by the suppliers of the network infrastructure. This is exactly the issue that I believe we are discussing here - i.e. EUnet. >By making multicast hopwise reliable, the real issue of "is my data >arriving" is _NOT_ addressed. It is not surprising that there is some confusion about exactly what "the" issue is - given the limited bandwidth of e-mail and perhaps my poor efforts at clarification. What you seem to be referring to as "the" issue is ene-to-end reliable delivery of the data - namely the issue being addressed by RMP and other efforts (research?) at multicast transport. There is a compendium of material on such efforts put together by Jon Knight that I often refer to on this topic at: http://hill.lut.ac.uk/DS-Archive/MTP.html This topic is one that I addressed also in the above noted paper (included in the above compendium along with an earlier note that I sent out to this MBONE list) in the context of NON real time multicast transport. However, in my previous message I was NOT addressing the issue of Multicast Transport in this context. I was addressing a more restrictive issue of simply making unreliable multicast as it currently exists over MBone "better" behaved from the viewpoint of the infrastructure providers. I believe that using TCP tunnels for the current MBONE would help to provide such better behavior at the cost of increased latency in delivery (and substantial coding work). I agree that the weight of multicast opinion is that multicast will ultimately be handled by low level routers (for IP packets or perhaps ATM cells). It is just not so clear to me that this is the obviously right way to go. In the spirit of discourse I have now posted two very different "hopwise" proposals to this list, one that is end-to-end reliable (previously posted to this list and published in the proceedings of the WWW'95 conference) and one that is not (in the previous message that you replied to). --Jed From list-mgr@ISI.EDU Wed Jun 7 13:31:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 14:32:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 14:31:34 -0700 Received: from cerc.wvu.edu (cathedral.cerc.wvu.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 14:31:33 -0700 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA11426; Wed, 7 Jun 95 17:31:31 EDT Received: by elk (5.0//ident-1.0) id AA00496; Wed, 7 Jun 1995 17:31:30 -0400 Date: Wed, 7 Jun 1995 17:31:29 -0400 (EDT) From: "Todd L. Montgomery" Subject: Re: EUnet, Cu-SeeMe, MBone, and "multicast TCP" - a proposal To: jed@llnl.gov Cc: mbone In-Reply-To: <9506072107.AA29716@ocfmail.ocf.llnl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2642 On Wed, 7 Jun 1995 jed@llnl.gov wrote: > >By making multicast hopwise reliable, the real issue of "is my data > >arriving" is _NOT_ addressed. > > It is not surprising that there is some confusion about exactly > what "the" issue is - given the limited bandwidth of e-mail > and perhaps my poor efforts at clarification. > > What you seem to be referring to as "the" issue is ene-to-end > reliable delivery of the data - namely the issue being addressed > by RMP and other efforts (research?) at multicast transport. I had (I guess mistakenly) thought that the issue that HRM was trying to address was providing end-to-end reliability. So, now I know... > However, in my previous message I was NOT addressing the > issue of Multicast Transport in this context. I was addressing > a more restrictive issue of simply making unreliable multicast > as it currently exists over MBone "better" behaved from the > viewpoint of the infrastructure providers. I believe that > using TCP tunnels for the current MBONE would help to > provide such better behavior at the cost of increased > latency in delivery (and substantial coding work). The actual coding would not be that bad. However, the problems of fault-tolerance would be more difficult to manage. Also an mrouter that used TCP would have a good bit more overhead, thereby causing more incoming packets (from the network on the multicast interface) to be dropped, reducing overall reliability over some topologies. Most of this observation has come to me while doing RMP testing and performance. Mrouters drop large amounts of packets before they even get to put them over the link. This occurs until flow control backs-off and/or packet size decreases to allow better chances that buffers don't overflow. At least this is what I have observed... > I agree that the weight of multicast opinion is that multicast > will ultimately be handled by low level routers (for IP packets or > perhaps ATM cells). It is just not so clear to me that this > is the obviously right way to go. In the spirit of discourse > I have now posted two very different "hopwise" proposals > to this list, one that is end-to-end reliable (previously posted > to this list and published in the proceedings of the WWW'95 > conference) and one that is not (in the previous message that > you replied to). I apologize for mixing those two. I think the low level routers are precisely the right areas to address this. With RSVP and other reservation techniques coupled with better multicast routing integration, the MBone will get more reliable (not end-to-end reliable, but best-effort reliable). -- Todd From list-mgr@ISI.EDU Wed Jun 7 08:35:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 15:36:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 15:35:35 -0700 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 15:35:35 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA01520; Wed, 7 Jun 95 15:35:31 PDT Message-Id: <9506072235.AA01520@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 Jun 1995 15:35:35 -0700 To: mbone From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: EUnet, Cu-SeeMe, MBone, and "multicast TCP" - a proposal On Wed, 7 Jun 1995 17:31:29 -0400 (EDT) tmont@cerc.wvu.edu wrote: >I had (I guess mistakenly) thought that the issue that HRM was trying to >address was providing end-to-end reliability. So, now I know... I think you understood this issue by the end of your message, but to be clear, HRM - Hopwise Reliable Multicast as described in the note and paper - DOES address itself to end-to-end reliability. It is functionally (though not implementationally) comparable to many of the other multicast transport protocol efforts like RMP. In the proposal that I sent earlier today (is it still today?) I was suggesting something else - let's call it Hopwise Unreliable Multicast, HUM. In Hopwise Reliable Multicast (HRM) a spanning tree of TCP connections is set up for every multicast group. In this scheme (TCP) flow control and error control (i.e. retransmissions and acknowledgements) slow transmission ultimately to the speed of the slowest or most congested link. For HRM to be useful over broadcast technologies like Ethernet, FDDI, possible ATM or whatever where hardware multicast or broadcast is available, it would require a hopwise reliable multicast protocol to span such a hop. The application in my paper was essentially for LAN to LAN transport or non real time data and didn't require such hardware multicast support. In Hopwise Unreliable Multicast (HUM...) the TCP connections are set up between mrouteds on the MBONE exactly where the tunnels are today. The equivalent of UDP packets are sent over these TCP tunnels just as UDP packets are today. These multicast packets are thrown away if congestion occurs in the mroute deamon. This scheme does not provide any more reliability - in fact as Todd noted, it might well be less reliable, but I believe that it would make the current multimedia applications (should I say experiments?) running over the today's MBONE version of IP multicast "better behaved" with regard to other TCP traffic as some carriers (EUnet) might wish. Remaining comments sent privately. --Jed http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Wed Jun 7 04:05:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 17:05:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 17:04:30 -0700 Received: from pm056-10.dialip.mich.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 17:04:28 -0700 Received: (from jauderho@localhost) by pm056-10.dialip.mich.net (8.6.11/8.6.9) id IAA07005; Wed, 7 Jun 1995 08:05:55 -0400 Date: Wed, 7 Jun 1995 08:05:54 -0400 (EDT) From: Jauder Ho X-Sender: jauderho@pm056-10.dialip.mich.net To: frederick@parc.xerox.com Cc: mbone Subject: nv Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-to: jauderho@umich.edu I managed to get nv compiled on my machine (linux v1.2.8) this morning. And I was able to get cuseeme streams... everything was fine and dandy... I have just returned from work and tried running nv again and the window comes up fine. HOWEVER I am no longer able to do anything to the window... the cursor will highlight the menus but I can't access them and hence I can't do anything at all. I have tried recompiling to no avail. Can anyone tell me what is wrong? thanks.... --Jauder From list-mgr@ISI.EDU Wed Jun 7 10:10:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 17:11:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 17:10:52 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 17:10:51 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14447(5)>; Wed, 7 Jun 1995 17:10:43 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 7 Jun 1995 17:10:31 -0700 To: mbone Cc: max@guest.apple.com (Mark Q. Maxham), Scott W Brim , Per Gregers Bilse , Vadim Antonov , deering@parc.xerox.com Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Date: Wed, 7 Jun 1995 17:10:26 PDT Sender: Steve Deering From: Steve Deering Message-Id: <95Jun7.171031pdt.75270@digit.parc.xerox.com> > From: max@guest.apple.com (Mark Q. Maxham) > > While it's true that Apple has been dragging its feet about supporting UDP > multicast, IMHO you can't lay the bulk of the blame there. The vast > majority of CUSM users don't have immediate access to the MBone (meaning a > multicast-capable router on their subnet). I speak from experience. Probably this is naive on my part, but if the Cornell folks had had multicast support on their Macs when they were developing CU-SeeMe they might have followed the good examples of the developers of the MBone tools who said: you can use our tools point-to-point using unicast, but for multiparty use, you must use IP multicast. I believe it was the refusal of those developers to hack up "reflectors" for each of their aplications that provided the incentive for people to go through the effort of getting MBone access. If they had all gone the CU-SeeMe route, we would now have vat reflector nets and nv reflector nets and ivs reflector nets and ..., the MBone would not have come into existence, and the chance of ever doing efficient multicast delivery would have been greatly reduced, if not eliminated. > From: Per Gregers Bilse > > WWW browsers and WWW bandwidth consumption is fundamentally different > from CU-SeeMe; the difference is largely one of TCP vs UDP. No, I think the fundamental difference is that humans can't click on links as fast as audio devices can generate sound samples, but as the number of clicking humans continues to grow exponentially, that fundamental difference will very soon go away. (As I understand it -- please correct me if I'm wrong -- each click starts a new TCP connection, and those SYN packets are *not* flow controlled.) > Note that nobody is talking about banning these applications; rather, > that the issue be discussed first. The EUnet GB policy note did not read like an invitation to discussion. > Generally, the comments on this list have come from people whose > points of reference is a development lab with campus fibre, and > maybe some generously provisioned T3s. This is also the environment > where CU-SeeMe was developed. This environment has practically > nothing in common with the global production Internet and I would > like people to bear this in mind. I can't speak for others, but my own "point of reference" is a very heterogeneous Internet with a wide range of available bandwidths, and I believe that will always be the case. My suggestion that you deploy fair queueing (as soon as you can get it from your router vendor(s)) was an alternative to administrative restrictions on using A/V applications, which would prevent those applications from driving out the other users of your links. If there isn't enough bandwidth to northern Belgium to support CU-SeeMe sharing with other users, so be it -- they'll stop using CU-SeeMe during those times when others are also using the link and go back to using an ASCII chat program instead, until you or some other provider can supply the desired bandwidth at an affordable price. > There will be 80kbits (default) sent per open window. Nearly > everything gets dropped on the floor in the terminal server. How does this jibe with Scott Brim's claim that Cu-SeeMe does perform reasonable back-off in the face of congestion? Is it maybe just a version problem, and you need to ask your users to upgrade to the latest version of CU-SeeMe? > And we as a service provider end up carrying around huge amounts of data, > only to eventually throw it out, with little or no way of covering > our costs. By "costs" are you referring to the dissatisfaction of your other customers, or do you actually save money when fewer bits are flowing over your links? E.g., does your cross-atlantic service change you per bit or something, or are you using X.25 circuits with per-bit or per-packet charges? I'm not trying to make a point, just curious. > The issue, at least from our side, is not related to any perceived > value of A/V data vs other data -- we couldn't care less. It's my fault for bringing up the "value" issue, which indeed is a tangent from the EUnet GB policy issue. There have been other folks in the provider community who have argued in favor of discrimination against A/V or MBone traffic in favor of "traditional", "production" traffic such as email, FTP, and telnet. This thread seemed to have that same flavor, but I see that that was a mistaken inference on my part. > CU-SeeMe traffic isn't terribly multicast'ed anyway, ... Well when it is multicasted, it is multicasted terribly. :-) > ...somebody did some real comparisons of UDP vs TCP for delivery. From what I could tell from the message you forwarded, the comparison was irrelevent. It did not model the traffic generation distribution of CU-SeeMe, the jitter sensitivity of CU-SeeMe, or the congestion algorithm that is employed by CU-SeeMe, any which might change the conclusion. Besides, TCP won't work for multicast audio or video (at least not end-to end TCP to groups with more than a small number of members, and probably not at all), and just solving the unicast case is not sufficient. Your clarifications of EUnet's position have been very helpful, Per. I hope you can appreciate that the original policy note that started all this took a much more extreme and drastic position than you have outlined. It seemed to be outlawing indefinitely the use (without permission) of all UDP-based audio and video applications, claiming that they violated the fundamental design of the Internet. If instead your policy is to temporarily ban the use of (old versions of?) CU-SeeMe until bandwidth sharing mechanisms can be deployed in your routers and/or more bandwidth provided, that sounds quite reasonable to me. > From: Vadim Antonov > > >i have an attitude problem that says "the subscriber is always right" > > Even if he comes to you with a gun and politely asks for free ride? Is this an example of the "exaggerations and manipulative hyperbole" to which Scott was referring? Steve From list-mgr@ISI.EDU Wed Jun 7 10:19:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 17:20:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 17:19:46 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 17:19:46 -0700 Received: from grus.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA01306; Wed, 7 Jun 95 17:19:23 PDT Date: Wed, 7 Jun 1995 17:19:22 -0700 (PDT) From: Michael Macedonia To: mbone net Cc: rem-conf , Mimi Zohar Subject: Porting to AIX Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mimi at IBM would really like to port the mbone tools to Aix and get more info on the sd api. Emails to the authors have been to no avail. Could someone please assist Mimi, who truly wants to bring enlightenment and multicast to big blue? - Mike Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From list-mgr@ISI.EDU Fri Jun 9 01:06:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 18:08:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 18:08:13 -0700 Received: from truth.waikato.ac.nz by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 18:08:08 -0700 Message-Id: <199506080108.AA08177@venera.isi.edu> Date: Thu, 8 Jun 95 13:06 +1200 From: Hamish Marson Subject: RE: Porting to AIX To: macedoni@cs.nps.navy.mil, mbone X-Vms-To: IN%"macedoni@cs.nps.navy.mil" Whoever does sd etc seems to be ignoring any requests for tool ports to IBM's. I don't know whether this is becasue they have a blindspot, were payed by microsoft, work overload, or just genuinely hate AIX. Anyway, I got some email back once, but while I was asking about AIX, I got back a note saying I could now get the Linux version.... Real useful.... ANyone else ever hear from these people at all? Know them? Do they exist? Are they real people or just some figment of our collective imaginations? H From list-mgr@ISI.EDU Wed Jun 7 17:17:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 18:16:49 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 18:16:22 -0700 Received: from clark.dgim.doc.ca by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 18:16:21 -0700 Received: from info.ic.gc.ca by clark.dgim.doc.ca (4.1/SMI-4.1.tee) id AA20869; Wed, 7 Jun 95 21:16:16 EDT Received: by info.ic.gc.ca (4.1/SMI-4.1) id AA18368; Wed, 7 Jun 95 21:17:02 EDT Date: Wed, 7 Jun 1995 21:17:01 -0400 (EDT) From: "William F. Maton" To: Jauder Ho Cc: frederick@parc.xerox.com, mbone Subject: Re: nv In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 7 Jun 1995, Jauder Ho wrote: > Reply-to: jauderho@umich.edu > > > I managed to get nv compiled on my machine (linux v1.2.8) this > morning. And I was able to get cuseeme streams... everything was fine and > dandy... I have just returned from work and tried running nv again and the > window comes up fine. HOWEVER I am no longer able to do anything to the > window... the cursor will highlight the menus but I can't access them and > hence I can't do anything at all. I have tried recompiling to no avail. Hmmmm....I had a similar problem.....looked a lot like to me that nv was demanding just far too much CPU time for the machine to appropriate time to other apps....would this be a correct hypothesis? > Can anyone tell me what is wrong? thanks.... > > --Jauder > > William F. Maton From list-mgr@ISI.EDU Wed Jun 7 12:14:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 19:15:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 19:14:37 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 19:14:36 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14524(3)>; Wed, 7 Jun 1995 19:14:22 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 7 Jun 1995 19:14:11 -0700 To: mbone Cc: max@guest.apple.com (Mark Q. Maxham), Scott W Brim , Per Gregers Bilse , Vadim Antonov , deering@parc.xerox.com Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: deering's message of Wed, 07 Jun 95 17:10:26 -0800. <95Jun7.171031pdt.75270@digit.parc.xerox.com> Date: Wed, 7 Jun 1995 19:14:02 PDT Sender: Steve Deering From: Steve Deering Message-Id: <95Jun7.191411pdt.75270@digit.parc.xerox.com> I wrote: > No, I think the fundamental difference is that humans can't click on links > as fast as audio devices can generate sound samples, but as the number of > clicking humans continues to grow exponentially, that fundamental difference > will very soon go away. I can see how that might be read as predicting that *per-human* clicking speed will very soon exceed audio sampling rates. That's not what I meant. :-) Steve From list-mgr@ISI.EDU Wed Jun 7 18:56:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 19:56:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 19:56:30 -0700 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 7 Jun 1995 19:56:30 -0700 Received: from [132.236.236.200] (CU-DIALUP-0630.CIT.CORNELL.EDU [132.236.236.200]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id WAA12630; Wed, 7 Jun 1995 22:56:22 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 Jun 1995 22:56:35 -0400 To: Steve Deering From: Scott W Brim Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone Perhaps you didn't see the recent announcement of a web browser which anticipates what you're going to do next and pre-follows links from the page you're on. There goes the Internet :-) >> No, I think the fundamental difference is that humans can't click on links >> as fast as audio devices can generate sound samples, but as the number of >> clicking humans continues to grow exponentially, that fundamental difference >> will very soon go away. From list-mgr@ISI.EDU Thu Jun 8 11:12:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 00:16:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 00:15:31 -0700 Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 00:15:25 -0700 Received: from zamin.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Thu, 8 Jun 1995 09:12:15 +0200 Received: by zamin.fokus.gmd.de (5.x/SMI-SVR4) id AA11494; Thu, 8 Jun 1995 09:12:12 +0200 Date: Thu, 8 Jun 1995 09:12:12 +0200 From: salehi@fokus.gmd.de (Majid Salehi) Message-Id: <9506080712.AA11494@zamin.fokus.gmd.de> To: mbone Subject: unsubscribe X-Sun-Charset: US-ASCII unsubscribe From list-mgr@ISI.EDU Thu Jun 8 11:18:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 02:26:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 02:21:04 -0700 Received: from berklix.ripe.net by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 02:21:02 -0700 Received: from berklix.ripe.net (geertj@localhost.ripe.net [127.0.0.1]) by berklix.ripe.net (8.6.9/8.6.9) with ESMTP id JAA00144; Thu, 8 Jun 1995 09:18:46 +0200 Message-Id: <199506080718.JAA00144@berklix.ripe.net> To: Steve Deering Cc: mbone, max@guest.apple.com (Mark Q. Maxham), Scott W Brim , Per Gregers Bilse , Vadim Antonov From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: Cu-SeeMe, TCP and UDP In-Reply-To: Your message of "Wed, 07 Jun 1995 17:10:26 PDT." <95Jun7.171031pdt.75270@digit.parc.xerox.com> Date: Thu, 08 Jun 1995 09:18:45 +0200 Sender: geertj@berklix.ripe.net On Wed, 7 Jun 1995 17:10:26 PDT Per wrote: > > WWW browsers and WWW bandwidth consumption is fundamentally different > > from CU-SeeMe; the difference is largely one of TCP vs UDP. > > Note that nobody is talking about banning these applications; rather, > > that the issue be discussed first. As cu-seeme is point-to-point, I think one can use Karn's slowstart mechanism (i.e. start with a low delay-bandwith product and throttle up) instead of starting with 80kb/s and throttling down. All that is needed are frequent, but low-bandwith 'acks' so one can calculate SRTT and drop rate, which is possible for point-to-point links. From this discussion I understand that 'acks' are already part of the protocol. It would make these apps behave like regular TCP, and remove the bad name it currently has because what it does to NOC network monitors. It is not that long ago that pre-BSD TCP's would grab all bandwith on slow links; the work of Phil Karn and Jon Nagle fixed that. This would fix the unicast UDP 'hail' problem; mrouted bandwith limitation limits the damage in case of mcast apps; anyone a better idea? > My suggestion that you deploy fair queueing > (as soon as you can get it from your router vendor(s)) That is problematic. Normally, packets are *not* processed by the CPU but handled by hardware; queueing requires that the router CPU is involved, and a beefed-up macintosh CPU will have severe problems switching T3 or anything like that... Geert Jan From list-mgr@ISI.EDU Thu Jun 8 11:41:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 02:43:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 02:42:06 -0700 Received: from gizmo.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 02:42:03 -0700 Received: from localhost (martin@localhost) by gizmo.lut.ac.uk (8.7.Beta.2/8.6.9) with SMTP id KAA19203 for ; Thu, 8 Jun 1995 10:41:51 +0100 Message-Id: <199506080941.KAA19203@gizmo.lut.ac.uk> X-Mailer: exmh version 1.6.1 5/23/95 To: mbone X-Uri: Subject: SunSolve Early Notifier Report (fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Jun 1995 10:41:51 +0100 From: Martin Hamilton FYI, this just landed in my mailbox ... ------- Forwarded Message From: SunSolve Early Notifier Date: Thu, 8 Jun 1995 05:37:38 +0100 Message-Id: <199506080437.FAA23501@online.sunsolve.sun.co.uk> To: martin@mrrl.lut.ac.uk Subject: SunSolve Early Notifier Report [snip] SECTION 2: IMPORTANT NEW PATCHES TOPIC: Sun4m audio patch for SPARCstation 5 PATCH #: 102387-01 APPLIES TO: Sun4m systems running Solaris 1.1.2 This patch fixes known bugs with the audio chip and driver on Sun4m systems (SPARCstation 5 in particular). NOTE: Please make sure to use the new Sun Microphone (SunMic 2) on the SS5. The older, standard SunMic does not work properly on the SS5. Bugs fixed by this patch: 1164836 vat (audio conferencing tool) does not work on SPARCstation 5. 1183393 Can't Resume after Gaintool Pause on AudioTool file open. 1182380 Sample count incorrectly set on cs4231 audio chip. 1187814 When accessing the audio driver, the SS5 panics. [snip] ------- End of Forwarded Message From list-mgr@ISI.EDU Thu Jun 8 12:33:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 03:44:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 03:42:14 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 03:42:00 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 8 Jun 1995 03:37:43 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Jun 1995 11:33:18 +0100 To: Geert Jan de Groot Cc: Steve Deering , mbone, max@guest.apple.com (Mark Q. Maxham), Scott W Brim , Per Gregers Bilse , Vadim Antonov Subject: Re: Cu-SeeMe, TCP and UDP In-Reply-To: Your message of "Thu, 08 Jun 95 09:18:45 +0100." <199506080718.JAA00144@berklix.ripe.net> Date: Thu, 08 Jun 95 11:33:08 +0100 Message-Id: <1151.802607588@cs.ucl.ac.uk> From: Jon Crowcroft >As cu-seeme is point-to-point, I think one can use >Karn's slowstart mechanism (i.e. start with a low delay-bandwith product >and throttle up) instead of starting with 80kb/s and throttling down. see acm sigcomm 94 for a paper about how to do this for multicast video applications by turletti, bolot and wakeman....it aint hard... >CPU is involved, and a beefed-up macintosh CPU will have severe >problems switching T3 or anything like that... this is Router Vendor mythology - that they can't do T3 on a standard processor - i used to support 4 10Mbps port on an LSI 11, and 10 2Mbps ports on a 68000 - it is reasoanbly easy if you have reasonable serial line cards that aren't totally stupid (i.e. do the right level of framingh support), and have another processor for routing work.....in fact , a decent multiple processor+bus architecture from a good workstation vendor near you would almost certianly be a better investment that a lot of clever xylinx programming...- the main problem router vendor people have is short term bean counters, not technology....imho jon p.s. the usual slowstart author cited is van jacobson (of the mbone application fame); see acm sigcomm88 From list-mgr@ISI.EDU Thu Jun 8 15:39:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 04:43:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 04:39:56 -0700 Received: from eunet.EU.net by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 04:39:42 -0700 Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id NAA23117; Thu, 8 Jun 1995 13:39:41 +0200 Received: by jotun.EU.net id AA12399 (5.67a/IDA-1.5); Thu, 8 Jun 1995 13:39:39 +0200 Message-Id: <199506081139.AA12399@jotun.EU.net> From: Per Gregers Bilse Date: Thu, 8 Jun 1995 13:39:39 +0200 In-Reply-To: <95Jun7.171031pdt.75270@digit.parc.xerox.com> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Steve Deering Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone On Jun 7, 17:10, Steve Deering wrote: > > WWW browsers and WWW bandwidth consumption is fundamentally different > > from CU-SeeMe; the difference is largely one of TCP vs UDP. > > No, I think the fundamental difference is that humans can't click on links > as fast as audio devices can generate sound samples, but as the number of > clicking humans continues to grow exponentially, that fundamental difference > will very soon go away. (As I understand it -- please correct me if I'm > wrong -- each click starts a new TCP connection, and those SYN packets are > *not* flow controlled.) True, but at 20pps (80kbit, 512 byte packets) per open window, the uncontrolled load presented to the network is orders of magnitude greater than that presented by a starting TCP connection. It is this magnitude problem that's the real humdinger; fundamentally it's all just IP packets, but that isn't the interesting part ("humans are collections of atoms"). > > Note that nobody is talking about banning these applications; rather, > > that the issue be discussed first. > > The EUnet GB policy note did not read like an invitation to discussion. I don't think it was meant as an open invitation either. Your point of reference is also not that of a service provider dealing with some thousand customers. There was a time when one knew all ones customers personally, but that's history. > My suggestion that you deploy > fair queueing (as soon as you can get it from your router vendor(s)) was > an alternative to administrative restrictions on using A/V applications, Advanced control mechanisms for large volumes of traffic will not become available for a long time. The CPU power (or, more appropriately, "smart silicon") to do it simply isn't available. Apart from that, I consider it very appropriate to lay down some, essentially, "traffic rules". Life is full of what you call administrative restrictions (you can drink, you can drive, but you can't do both; you can go to a shopping mall, you can fire machine guns, but you can't do both; etc) and I don't see anything sinister in placing some responsibility in the hands of the people who might do it. > during those times when others are also using the link and go back to using > an ASCII chat program instead, until you or some other provider can supply > the desired bandwidth at an affordable price. Just a side-note: many people in the US have no idea what international (and European) bandwidth costs. It's on the order of 10-14 times more than bandwidth inside the US. Our US capacity is currently 4Mbit, going to 6Mbit in a couple of months; and we obviously have sizeable bandwidth throughout Europe. If we went to the US and bought bandwidth for the same amount of money as we spend in Europe, we would have a nicely meshed T3 network, with a minimum of 2*T1 into every POP (~250 of them). And if we had that, we wouldn't have a problem with an application like CU-SeeMe -- yet. What you're seeing is simply that we're feeling the crunch much earlier than US providers. Which doesn't mean that they're immune: On May 20, 22:57, Sam Churchill wrote: > To: > Subject: Cornell problems May 12th? > > I just subscribed to this list so pardon if I mention old news...My local > (Portland OR) provider (Teleport) had a problem with the Cornell site > Friday, May 12th. Seems though there was too much data for their routers to > handle and it screwed things up a bit. I was using CU (receive only,no > sound) at the time. > > Anyone else have problems on this date or was it me or my provider? > > I have used CuSeeME maybe a dozen times with no problem. I've got a > Connectix (golfball) camera hooked to my Mac but I haven't taken the time > to understand more than basic functions. Am using a 68030 33Mhz Powerbook > Here are Joey's (complete) notes: > ............................................. > > Date: Fri, 12 May 1995 11:51:36 -0700 > From: Joe Pruett > To: samc@teleport.com > Subject: usage on may 12 around 11:30 > > what were you doing? you had a whole lot of udp traffic coming from a site > at cornell to your machine. whatever it was, it was causing all kinds > of trouble for one of our routers. please don't do it again. > ............................................. > Date: Fri, 12 May 1995 20:39:38 -0700 (PDT) > From: Joe Pruett > To: Sam Churchill > Subject: Re: usage on may 12 around 11:30 > MIME-Version: 1.0 > > the problem is that there is no higher level flow control on the data > stream, so it was sending huge amounts of data to us, most of which we > were dumping on the floor since only so much will fit through a modem > connection. i'm not sure why dropping the data was causing a huge load, > but it certainly was. you might want to see if the server you connect to > has any kind of options to control data pacing. > ............................................. > > Those were the notes I got from my provider. I've been avoiding CU ever > since. Could I have done something on my setup to screw THEM up??? > > Any comments welcome! Let's repeat that question: > Could I have done something on my setup to screw THEM up??? Yes. > > There will be 80kbits (default) sent per open window. Nearly > > everything gets dropped on the floor in the terminal server. > > How does this jibe with Scott Brim's claim that Cu-SeeMe does perform > reasonable back-off in the face of congestion? Is it maybe just a version > problem, and you need to ask your users to upgrade to the latest version > of CU-SeeMe? The developers have had plans to do better end-to-end rate limiting / flow control in "the next version", but I don't know if it's available yet. I'll believe it when I see it; moreover, it is *not* enough just to throttle down until you detect no packet loss on your own data stream. If your stream is just a little more aggressive than the average TCP stream, you will push out TCP traffic until you have the bandwidth you want. > > And we as a service provider end up carrying around huge amounts of data, > > only to eventually throw it out, with little or no way of covering > > our costs. > > By "costs" are you referring to the dissatisfaction of your other customers, > or do you actually save money when fewer bits are flowing over your links? Ultimately, those two are the same,-) but you are (correctly) interested in the real-world difference. The answer is dissatisfaction and/or the need to upgrade links to avoid dissatisfaction. > Besides, TCP won't work for multicast audio or video (at least not end-to > end TCP to groups with more than a small number of members, and probably > not at all), and just solving the unicast case is not sufficient. In the case of CU-SeeMe, using TCP (or closely emulating TCP, but maybe without reliable delivery) would solve the problem we have. The discussion on this list has focused somewhat on multicasting, but CU-SeeMe (which is -the- problem) is ill-behaved, high volume, unicast. > > >i have an attitude problem that says "the subscriber is always right" > > > > Even if he comes to you with a gun and politely asks for free ride? > > Is this an example of the "exaggerations and manipulative hyperbole" to > which Scott was referring? I think "the subscriber is always right" and "I have a right to use..." and "it isn't my responsibility", etc, fall into that category. Unless one believes in holy cows, obviously. I don't think anybody really objects to a rule that says "passengers are not allowed to hijack the plane." :-) -- === ___ === Per G. Bilse, Mgr Network Operations Ctr === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Thu Jun 8 15:50:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 04:51:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 04:50:36 -0700 Received: from eunet.EU.net (ns2.EU.net) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 04:50:32 -0700 Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id NAA23624; Thu, 8 Jun 1995 13:50:30 +0200 Received: by jotun.EU.net id AA12442 (5.67a/IDA-1.5); Thu, 8 Jun 1995 13:50:29 +0200 Message-Id: <199506081150.AA12442@jotun.EU.net> From: Per Gregers Bilse Date: Thu, 8 Jun 1995 13:50:29 +0200 In-Reply-To: <1151.802607588@cs.ucl.ac.uk> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Jon Crowcroft Subject: Re: Cu-SeeMe, TCP and UDP Cc: mbone On Jun 8, 11:33, Jon Crowcroft wrote: > i used to support 4 10Mbps port on an LSI 11, and 10 2Mbps ports on a > 68000 - it is reasoanbly easy if you have reasonable serial line cards > that aren't totally stupid (i.e. do the right level of framingh > support), and have another processor for routing work.....in fact , a Sure; that's what routers do today as well. But that totally excludes the more advanced traffic control mechanisms that were being discussed in this context, which require processing several orders of magnitude greater than moving some memory or a couple of pointers around. -- === ___ === Per G. Bilse, Mgr Network Operations Ctr === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Thu Jun 8 14:17:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 05:18:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 05:18:35 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 05:18:34 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 8 Jun 1995 05:18:32 -0700 Received: from fido.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Jun 1995 13:18:06 +0100 To: Per Gregers Bilse Cc: mbone Subject: Re: Cu-SeeMe, TCP and UDP In-Reply-To: Your message of "Thu, 08 Jun 95 13:50:29 +0100." <199506081150.AA12442@jotun.EU.net> Date: Thu, 08 Jun 95 13:17:58 +0100 Message-Id: <9005.802613878@cs.ucl.ac.uk> From: Jon Crowcroft >On Jun 8, 11:33, Jon Crowcroft wrote: >> i used to support 4 10Mbps port on an LSI 11, and 10 2Mbps ports on a >> 68000 - it is reasoanbly easy if you have reasonable serial line cards >> that aren't totally stupid (i.e. do the right level of framingh >> support), and have another processor for routing work.....in fact , a > >Sure; that's what routers do today as well. But that totally >excludes the more advanced traffic control mechanisms that were being >discussed in this context, which require processing several orders >of magnitude greater than moving some memory or a couple of pointers >around. this too is mythology - a calendar queue structure is Order Constant, and classiier on incoming packets to put them in the right queue is order Log of the number of different classes (not the number of flows, and can be computed at about 100 instructions over 10,000 different classes (which is a ludicrously large number, given we just want to classify ftp, telnet, audio, and a few flavours of video) jon From list-mgr@ISI.EDU Thu Jun 8 07:17:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 08:19:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 08:17:38 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 08:17:36 -0700 Received: by chops.icp.net id <20697>; Thu, 8 Jun 1995 11:17:19 -0400 From: Sean Doran To: J.Crowcroft@cs.ucl.ac.uk, smd@icp.net Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: bilse@eu.net, mbone Message-Id: <95Jun8.111719-0400_edt.20697+5@chops.icp.net> Date: Thu, 8 Jun 1995 11:17:07 -0400 >we have abandoned testing PIM on the European 34Mbps backbone Hm, this conflicts with some information I have received in email. Perhaps we are thinking of different "European 34Mbps backbone"s. Sean. P.S.: >advice: pressure cisco to fix the DVMRP stub...talk to dino... Would you mind terribly if I nominate you to the IAB? From list-mgr@ISI.EDU Thu Jun 8 08:12:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 09:13:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 09:12:32 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 09:12:30 -0700 Received: by chops.icp.net id <20696>; Thu, 8 Jun 1995 12:12:19 -0400 From: Sean Doran To: bilse@eu.net, deering@parc.xerox.com Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone Message-Id: <95Jun8.121219-0400_edt.20696+6@chops.icp.net> Date: Thu, 8 Jun 1995 12:12:18 -0400 I would like to reiterate, magnify and clarify my colleague's comments, and add some MBONE-relevance: Generally, the comments on this list have come from people whose points of reference is a development lab with campus fibre, and maybe some generously provisioned T3s. This is also the environment where CU-SeeMe was developed. This environment has practically nothing in common with the global production Internet In short, there are some otherwise intelligent people here who are ignorant with respect to several key operational issues. Rather than admit their ignorance, or perhaps not speak on issues about which they are not fully versed, they draw upon their generally ample historical experience and attempt to extrapolate reality from that. Unfortunately that doesn't work in practice, and with respect to those theorists who have earned their laurels, those laurels are not going to persuade operators of whatever size that pigs can fly. Now, with respect to some general concerns: 1/ "You are trying to play net.cop with certain types of traffic, based on your own value judgements" No. Sprint has no policy with respect to traffic other than that it must not interfere with the normal use of the Internet by others. AFAIK, the only restrictions on Sprint traffic is with respect to ICM in that a portion of the traffic between the U.S. and an ICM connectee must be in support of R&E traffic (similar to the old NSFNET backbone service's AUP), pro rated to the amount of funding the NSF provides. This is policed by ICM connectees, and not by Sprint. That does not apply to the unfunded portions of ICM links, the unfunded ICM links or any SprintLink connection. Consequently, you can use Sprint's facilities to do anything you like so long as you don't make the Internet generally unusable to others. Call it telco mentality. 2/ "You have a problem with UDP" No. I have a problem with unfriendlily large UDP floods, as they have a tendency to push TCP traffic (and less aggressive UDP traffic) out of the way whenever there is congestion of any sort. This makes the Internet generally unusuable to large groups of people in some situations, notably when using transatlantic E1s. 3/ "You have a problem with research protocols, or MBONE" No, I encourage the former; it's in character with ICM, and is also encouraged by the NSF and various of the ICM connectees. We do quite a bit of playing in a production setting with the cooperation of all parties. We offer MBONE to all our SprintLink customers, and have encouraged its use with the understanding that the MBONE is fundamentally experimental, and that one needs to be careful to be friendly to the MBONE and the Internet when using it. Moreover, generally speaking, Sprint would love for all customers (and folks downstream from them) to be able to use the MBONE -- there are simply some scaling details to get out of the way first, and those are dealt with here in this list regularly. 4/ "You discriminate against CU-SEEME" No, and doing so is not trivial. What we will do is talk with anyone who is actively using applications of any sort which act as denial-of-service attacks, and make the bad side-effects clear. In cases where this does not stop the denials-of-service, we will do essentially what EUNET does, and resort to using the customer service agreement as necessary to stop the misbehaviour. Generally, this has not been necessary. 5/ "The problem is with Cisco or with company X's network design or ..." The problem is that the Internet grows at roughly 15%/month, and R&E sites are now a minority consumer group, and can no longer expect to be able to break production networks at will, or have a network redesigned to fit its various needs when that runs contrary to those of other customer groups, who generally want working, cost-effective connectivity. Of course, if you are Jon Crowcroft or someone of that Ilk you are ABSOLUTELY correct that the solutions to all these issues are trivial and that people are just flocking away from providers like EUNET and SprintLink towards those numerous providers who have designed their networks according to your Master Plan. 6/ "You're an asshole, Sean." I know that. Hey, Vixie, if you're reading this, you owe me another button. Hopefully this will tend to reassure those folks with valid concerns, and seriously piss-off those people who are just unhappy with reality. Sean. From list-mgr@ISI.EDU Thu Jun 8 18:10:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 09:17:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 09:12:44 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 09:12:43 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 8 Jun 1995 09:12:34 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Jun 1995 17:10:25 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Sean Doran Cc: J.Crowcroft@cs.ucl.ac.uk, bilse@eu.net, mbone Subject: PIM in Europe (was Re: EUnet GB policy on Cu-SeeMe and similar applications) In-Reply-To: Your message of "Thu, 08 Jun 95 11:17:07 EDT." <95Jun8.111719-0400_edt.20697+5@chops.icp.net> Date: Thu, 08 Jun 95 17:10:22 +0100 Message-Id: <14260.802627822@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >>we have abandoned testing PIM on the European 34Mbps backbone > >Hm, this conflicts with some information I have received >in email. Perhaps we are thinking of different "European >34Mbps backbone"s. There are several issues here. We'd prefer to use PIM in ciscos, but the first requirement is to test the ATM backbone, and not to provide a high bandwidth service. DVMRP is the simplest to set up and get working given the need to interconnect with the existing Mbone at many points. Given the problems with getting the backbone to support unicast properly, we didn't want more complexity than necessary at this point. So far I haven't seen any description of how a PIM backbone (probably with no leaf sites) can interconnect multiple parts of the DVMRP Mbone without causing blackholes and also how this would affect the DVMRP metrics between different sites interconnected by both a PIM route and a DVMRP route. The current PIM spec is incomplete on these issues. Mark From list-mgr@ISI.EDU Thu Jun 8 21:14:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 10:19:49 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 10:19:05 -0700 Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 10:19:03 -0700 Message-Id: <199506081719.AA05115@venera.isi.edu> Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Thu, 8 Jun 1995 19:15:37 +0200 X-Mailer: exmh version 1.6.1 5/23/95 To: Jon Crowcroft Cc: Per Gregers Bilse , mbone From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Re: Cu-SeeMe, TCP and UDP In-Reply-To: Your message of "Thu, 08 Jun 1995 13:17:58 BST." <9005.802613878@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Jun 1995 19:14:52 +0200 Sender: schulzrinne@fokus.gmd.de > > > >On Jun 8, 11:33, Jon Crowcroft wrote: > >> i used to support 4 10Mbps port on an LSI 11, and 10 2Mbps ports on a > >> 68000 - it is reasoanbly easy if you have reasonable serial line cards > >> that aren't totally stupid (i.e. do the right level of framingh > >> support), and have another processor for routing work.....in fact , a > > > >Sure; that's what routers do today as well. But that totally > >excludes the more advanced traffic control mechanisms that were being > >discussed in this context, which require processing several orders > >of magnitude greater than moving some memory or a couple of pointers > >around. > > this too is mythology - a calendar queue structure is Order Constant, and > classiier on incoming packets to put them in the right queue is order > Log of the number of different classes (not the number of flows, and > can be computed at about 100 instructions over 10,000 different > classes (which is a ludicrously large number, given we just want to > classify ftp, telnet, audio, and a few flavours of video) ATM adapters currently police and shape hundreds of individual VP/VCs. I assume that those that voted for ABR service in the ATM Forum have hopes of actually implementing it on 16x155 Mb/s and up switches, again for hundreds, if not thousands of connections. (DEC and GBC, I believe, already have flow-controlled VCs in their switches.) Fore switches maintain thousands of individual output queues. Etc. Thus, either doing this for IP is so much harder (and then the IP community has a real problem) or it's mostly a question of (relative) customer demand. Henning From list-mgr@ISI.EDU Thu Jun 8 03:34:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 10:34:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 10:34:10 -0700 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 10:34:09 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA11685; Thu, 8 Jun 95 10:33:59 PDT Message-Id: <9506081733.AA11685@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Jun 1995 10:34:02 -0700 To: Todd Montgomery From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: End to end VS. hop by hop Cc: mbone, rmp-discuss@aurora.jhuapl.edu, all@mbone.llnl.gov Here I am focusing on Multicast transport - RMP vs. HRM. So... regarding: Jed>> Forgetting real time issues for >> the moment, it seems to me quite unwise to try to deal with >> congestion and error control for reliable multicast on an end-to-end >> basis as RMP and other protocols are developing when the >> information about what is going on with the congestion, flow, and >> errors is most directly visible at the forwarding nodes. HRM >> makes perfect sense to me in this regard. > Todd>I have to disagree. RMP uses a modified version of Van's TCP flow >an congestion control work. Detection of congestion is seen at the >receiver as dropped packets. And the sender may also see congestion >as expired timers. Adaptively, the system recovers from these drops by >adjusting sending rate. I think we do strongly disagree on this (in a friendly way :-). I certainly wish we were in the same room with a chalkboard... MBone and whiteboard are, alas unavailable to me at the moment (whether they should be used or not :-), so let me try with the tools available -> I ask you to consider: http://www-atp.llnl.gov/atp/papers/HRM/HRM-fig1.gif I believe it is clear even in such a simple topology how poorly end to end adaptation deals with dropped packets due to bursty traffic in the network when compared to a hop by hop approach. Remember that I am dealing with non real time transport. A simple case -> things are steady state and A is multicasting to C and to E (for example). E is on a slow line so A has learned about this by expired timers or by being notified by E about lost packets. A has slowed down to E's rate and things are steady for the moment. Now F sends a burst to E. How does A find out about this? Of course eventually it hears from E about the problem as E reports lost packets (or A has timers expire?). It probably hears after: 1. Many of A's packets in flight from A to B and B to D have been dropped, and 2. After the burst from F has stopped and A can (could) actually go back to it's original transmission rate. Even after A slows down its transmission (perhaps inappropriately), when it does retransmit the packets lost on the way to E, it must wastefully send them again at least over A to B and over B to D in addition to where they were actually lost over D to E. I also believe that with RMP and such schemes it will send them needlessly over B to C and any other such links where they have already been successfully transmitted due to the mechanisms in IP multicast (please correct me if I am wrong about this, this issue is not very important to the discussion). In an HRM scenario the TCP transmission from D to E much more quickly "notices" the congestion at D (or on the line from D to E). While it retries locally (with lower latency), data on this multicast group from B to D will back up and may eventually fill a flow control window. This may in turn fill the flow control window (assuming things don't get cleared up soon enough) in B for A and A will slow (temporarily stop) its transmission. Result -> with HRM no data is needlessly transmitted on the lines from A to B or from B to D only to be dropped at D. The losses are "minimized" on the line from D to E. Data is also not needlessly retransmitted over these lines (or over B to C). Remember again that in this scheme we are not dealing with real time traffic. The intent is to, for example, mirror software or WWW pages or usenet material or... The data must get (Multicast Transport) to all nodes correctly even if at the rate of the slowest. Also remember that I am not dealing with the hardware multicast or broadcast case (where a "hopwise" multicast or broadcast transport seems to me entirely appropriate). Now consider a real situation like world-wide multicast including a transmitter in Germany and a receiver in Korea (one of my favorite cases from personal experience...). Twenty or so hops, line bandwidths all over the map, bursty traffic in and out from all sides, long end to end latencies... I hope you get the picture. The rather short section 4.3 in the paper briefly discusses this situation also from a slightly different viewpoint. Isn't it clear?! Todd>This kind of thinking has been the norm (at >least to my knowledge) in the commercial community. Router >manufacturers are leery to deal with mandating flow control at >the nodes. (Beyond dropping packets). > >I am not saying that it is right. In fact, I think they need to start >dealing with things like Fair Queuing to eleviate some of their >nearsighted views of traffic.... Well, I believe it is NOT right. Actually I think it is not "them" but "us" that has the problem. I believe it basically traces back to a somewhat mindless adherence to the OSI layered model - you know, transport level vs. network level. I believe that this example demonstrates that this model is simply inappropriate for this (and perhaps other) real world scenario(s). As much as there is that I don't like about ATM (chronicled elsewhere), this is one area where I think it is closer to having a working model. At least by having virtual circuits (be they unicast or multicast) known about in all the switches (routers) one has the opportunity to deal with congestion on a local (hopwise) basis where the immediate knowledge of the situation is directly available. Getting that knowledge to be able to effectively "back up" (I like the old Timenet "back pressure" terminology) the circuit to the source seems to require buffering and protocols that ATM is currently not prepared to deal with, but in principle I believe it can. In principle I believe that RMP or any other Multicast Transport protocol built over IP multicast effectively CANNOT. Whew! Sorry for getting going on this, but it does seem quite clear to me, so I feel that something has to give in my understanding or yours. I hope we can get there. I don't like being stuck away from the "main stream." Jed>> If you can clarify the error of my ways in this regard or point >> me to some salient points, I would be delighted to follow up >> on this. Todd>The big point I can think of is that, taking the control out of >adjusting sending rates from the application and placing it in the nodes >would likely cause a lot of headaches to application developers because >they would have to figure out how to get the flow information from the >nodes. Off the top of my head, this appears really hard to do well. >Backflow needs to exist to the sender so that it can adjust to congestion >and faults in a fluid way. I believe this is not hard with HRM. The sending application knows nothing about the state of the nodes. All it sees is a TCP window across it's first tunnel (even that indirectly). With HRM a sender need adjust to flow control, congestion control, and errors only on it's line(s - independently) to its next node. It does so with tried and true TCP - that is all. There is a very fundamental dichotomy here - "end to end" vs. "hop by hop." I believe that this dichotomy is worth discussing in some context, but perhaps e-mail to these lists is not the appropriate place? Jon Crowcroft once suggested: Jon> an 'outrageous opinions' session at the upcoming >SIGCOMM in Cambridge Mass This was actually in response to another even more controversial idea of mine regarding an alternative to ATM (sigh!), but perhaps a meeting like this (even if this one is past? - I'll check) might be a place to discuss "end to end vs. hopwise multicast"? I should probably quit while I am ahead (? a feeling anyway), but it is difficult to resist the observation that much of the above argument is independent of the multicast case. Multicast certainly makes the case stronger, but even for unicast the argument for local detection of congestion and "back pressure" seems quite clear to me. With that I definitely will quit... --Jed http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Thu Jun 8 03:33:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 10:34:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 10:33:32 -0700 Received: from mail.ucsd.edu (ucsd.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 10:33:31 -0700 Received: from [132.239.21.192] by mail.ucsd.edu; id KAA12080 sendmail 8.6.12/UCSD-2.2-sun via SMTP Thu, 8 Jun 1995 10:33:16 -0700 X-Sender: rbohn@popmail.ucsd.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Jun 1995 10:33:21 -0700 To: Steve Deering From: Rbohn@UCSD.edu (Roger Bohn) Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone, max@guest.apple.com (Mark Q. Maxham), Scott W Brim , Per Gregers Bilse , Vadim Antonov , Nieman@fas.harvard.edu A technical question from a non-technical lurker. Economics rears its ugly head. If you are going to implement fair queuing on a router, with a large computational overhead, why not go the next step and implement something which gives users more control over their fate? Although Steve Deering objects to service providers associating "value" with different traffic, it is something that _users_ do all the time in the way we run our lives. And for any service provider who wants to increase profits so they can grow the network, there is a lot of economic value in being able to sell different classes of service to different users, over the same network. Is fair queueing somehow much easier to implement than other approaches to rationing for congestion control? It has the virtue of being easy to explain to people, but what else? Put this another way: There are certainly people and situations for which the value of CuSee-Me from the U.S. to Europe is very high, e.g. it saves them the price of a plane ticket. There are many other situations (even for the same people) where the value is mainly for novelty. Under a "treat everyone and every packet the same" approach, these users get the same quality of service (crummy, most of the time), no matter what their urgency. There is no social theory of value that I know of in which that makes sense (not even Marxism :-) Nonetheless, for technical reasons that's what we currently have on the Internet. My conclusion: Dealing with problems like the one raised by EUNet will, at least in the long run, involve making multiple service qualities available to users. ---------------------------- At 5:10 PM 6/7/95, Steve Deering wrote: >I can't speak for others, but my own "point of reference" is a very >heterogeneous Internet with a wide range of available bandwidths, and >I believe that will always be the case. My suggestion that you deploy >fair queueing (as soon as you can get it from your router vendor(s)) was >an alternative to administrative restrictions on using A/V applications, >which would prevent those applications from driving out the other users of >your links. If there isn't enough bandwidth to northern Belgium to support >CU-SeeMe sharing with other users, so be it -- they'll stop using CU-SeeMe >during those times when others are also using the link and go back to using >an ASCII chat program instead, until you or some other provider can supply >the desired bandwidth at an affordable price. > ............ >By "costs" are you referring to the dissatisfaction of your other customers, >or do you actually save money when fewer bits are flowing over your links? >E.g., does your cross-atlantic service change you per bit or something, >or are you using X.25 circuits with per-bit or per-packet charges? I'm >not trying to make a point, just curious. An interesting question. > >> The issue, at least from our side, is not related to any perceived >> value of A/V data vs other data -- we couldn't care less. > >It's my fault for bringing up the "value" issue, which indeed is a tangent >from the EUnet GB policy issue. There have been other folks in the provider >community who have argued in favor of discrimination against A/V or MBone >traffic in favor of "traditional", "production" traffic such as email, FTP, >and telnet. This thread seemed to have that same flavor, but I see that >that was a mistaken inference on my part. ******************************************************************* *Roger Bohn Rbohn@UCSD.edu * *Graduate School of International Relations and Pacific Studies * *University of California, San Diego 92093-0519 * ******************************************************************* From list-mgr@ISI.EDU Thu Jun 8 02:12:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 11:07:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 11:07:18 -0700 Received: from relay1.UU.NET by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 11:07:15 -0700 Received: from sco.sco.COM by relay1.UU.NET with SMTP id QQytgq04995; Thu, 8 Jun 1995 14:05:14 -0400 Received: from tehama.pdev.sco.COM by sco.sco.COM id af12268; Thu, 8 Jun 95 11:00:35 PDT Received: from basil.pdev.sco.COM by tehama.sco.com id aa06273; 8 Jun 95 9:12 PDT From: shawnm@sco.COM To: macedoni@cs.nps.navy.mil, mbone Subject: Porting to AIX (& SCO) Cc: rem-conf@es.net, zohar@watson.ibm.com X-Mailer: ScoMail 3.0.Bb Mime-Version: 1.0 Date: Thu, 8 Jun 1995 9:12:45 -0700 (PDT) Message-Id: <9506080913.aa07241@basil.sco.com> I have been offering to do a port to SCO for the past year and have also offerred to send them a free development system so they could do the port, since they don't seem to want to release source in any way. I never even got a "No, thank you. We're not interested" response. I am always willing to give people who develop software available on the net, more than the benefit of the doubt when communicating through email. I know that i still get mail for software that i wrote and made available 4 years ago. But I am sure they don't get that many offers from system vendors like IBM and SCO to make their work available on these platforms. Shawn From: Michael Macedonia Mimi at IBM would really like to port the mbone tools to Aix and get more info on the sd api. Emails to the authors have been to no avail. Could someone please assist Mimi, who truly wants to bring enlightenment and multicast to big blue? - Mike Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From list-mgr@ISI.EDU Thu Jun 8 09:57:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 11:20:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 11:15:22 -0700 Received: from amsaa-cleo.arl.mil by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 11:15:21 -0700 Received: by AMSAA-CLEO.ARL.MIL id aa09398; 8 Jun 95 14:08 EDT Date: Thu, 8 Jun 95 13:57:43 EDT From: "Wallace E. Hughes Jr., AMSAA/CID/SIMB, phone:410-278-5336" To: mbone Subject: unsubscribe Message-Id: <9506081357.aa08319@AMSAA-CLEO.ARL.MIL> unsubscribe From list-mgr@ISI.EDU Thu Jun 8 05:04:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 12:16:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 12:11:11 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 12:11:10 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id MAA17497; Thu, 8 Jun 1995 12:04:22 -0700 Date: Thu, 8 Jun 1995 12:04:22 -0700 From: Tony Li Message-Id: <199506081904.MAA17497@greatdane.cisco.com> To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Cc: Steve Deering , mbone, Geert Jan de Groot , max@guest.apple.com (Mark Q. Maxham), Scott W Brim , Per Gregers Bilse , Vadim Antonov >CPU is involved, and a beefed-up macintosh CPU will have severe >problems switching T3 or anything like that... this is Router Vendor mythology - that they can't do T3 on a standard processor - No, this is Router Vendor Critic mythology. First, a cisco 7000 can clearly do T3 while fast switching (see Bradner testing). Second the AMD 2901 _is_ a standard processor. Tony From list-mgr@ISI.EDU Thu Jun 8 11:38:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 12:45:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 12:38:47 -0700 Received: from rama.poly.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 12:37:42 -0700 Received: by rama.poly.edu (4.1/SMI-4.1) id AA13340; Thu, 8 Jun 95 15:38:40 EDT Date: Thu, 8 Jun 1995 15:38:39 -0400 (EDT) From: Charlie To: mbone Subject: MBone Probs... Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Not sure where to send this question, but I was hoping you could help out... We're running a SparcStation 10 with Solaris 2.3 here... I've managed to download and compile vat, sd, nv, and wb... In addition, I've managed to get mrouted compiled... Unfortunately, when I try to run it, it gives me an error...: debug level 3 mrouted version 2.2 installing le0 (128.238.10.34 on subnet 128.238.10) as vif #0 installing le1 (128.238.14.1 on subnet 128.238.14) as vif #1 Bus Error (core dumped) I was wondering what I'm doing wrong... Can anyone give me any advice as to what I should do to remedy the situation...?? Thanks a lot... Alex Hernandez... | Alex Hernandez | "While lying in bed, I think about life and I | | Polytechnic University | think about death and neither one particularly | | Mechanical Engineering | appeals to me..." -The Smiths | | aherna01@rama.poly.edu | HOME PAGE - http://www.poly.edu:1800/alex.html | From list-mgr@ISI.EDU Fri Jun 9 00:11:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 13:11:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 13:11:18 -0700 Received: from eunet.EU.net by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 13:11:16 -0700 Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id WAA20226; Thu, 8 Jun 1995 22:11:07 +0200 Received: by jotun.EU.net id AA14038 (5.67a/IDA-1.5); Thu, 8 Jun 1995 22:11:06 +0200 Message-Id: <199506082011.AA14038@jotun.EU.net> From: Per Gregers Bilse Date: Thu, 8 Jun 1995 22:11:06 +0200 In-Reply-To: Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Rbohn@UCSD.edu (Roger Bohn) Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone On Jun 8, 10:33, Roger Bohn wrote: > A technical question from a non-technical lurker. Economics rears its ugly > head. I think this should be taken to com-priv,-) with a new 'Subject:' line. But I'm happy to see you here and I'd like to ask the Mboners to bear with the following -- it is pretty fundamental to keeping the Internet healthy. > If you are going to implement fair queuing on a router, with a large > computational overhead, why not go the next step and implement something > which gives users more control over their fate? This is similar to the 'go-faster' button that gets discussed from time to time. Apart from the technical difficulties, it implies a change to some form of metered service; all experience so far suggests that customers dislike this as much as the providers do. However, what you want already exists in practice, cleverly disguised as a purchase of a connection with higher bandwidth, or a special agreement. In the heat of the discussion, a couple of important sections in the note from EUnet GB were overlooked by most people. Here they are again: "Unless otherwise agreed in a service agreement, EUnet provides international bandwidth on an as-available basis, and User Organisation's bandwidth and other resource consumption must be commensurate with the type of service taken" What this basically means is that somebody with a high speed connection are of course free to use much more (international) bandwidth than somebody with a low speed connection. Because: It is apparent even from the pricing of Internet services worldwide, that users paying a fixed annual fee for eg a modem access, will at best slowly bankrupt Internet providers if they take full modem speed constant international bandwidth when connected. At worst they will cause Providers networks to very quickly become unusable by most users. When pricing Internet services and provisioning infrastructure, we, like everybody else, make a number of assumptions about customer's usage profiles; the most fundamental assumption is that customers do not consume anywhere near their full access speed in (international) bandwidth. This is why eg a 64k Internet connection doesn't cost anywhere near the same as a 64k leased international line. And this is why an application like CU-SeeMe is economically disastruous, both for us and everybody else: we assume that a modem user will use a smallish number of kbits on average. But when they turn on CU-SeeMe (current version) they use n*80 kbit (one 'n' for each open window). Even with improved flow control, the assumptions are still broken. This problem is felt much more by somebody like us since we buy lots of international capacity, including (obviously) to the US; while service providers in the US generally don't buy international capacity at all. The only solution to this is to introduce metered services, which everybody agrees nobody wants. Sigh and 1/2 :-) -- === ___ === Per G. Bilse, Mgr Network Operations Ctr === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Thu Jun 8 13:36:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 14:33:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 14:33:30 -0700 Received: from ftp.com (wd40.ftp.com) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 14:33:27 -0700 Received: from ftp.com by ftp.com ; Thu, 8 Jun 1995 17:33:26 -0400 Received: from mailserv-C.ftp.com by ftp.com ; Thu, 8 Jun 1995 17:33:26 -0400 Received: from chip.slingshot.ftp.com by mailserv-C.ftp.com (5.0/SMI-SVR4) id AA29657; Thu, 8 Jun 95 17:36:42 EDT Date: Thu, 8 Jun 95 17:36:42 EDT Message-Id: <9506082136.AA29657@mailserv-C.ftp.com> To: bilse@eu.net Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications From: chip@ftp.com (Chip Sparling) Organization: FTP Software, Inc. Reply-To: chip@ftp.com Cc: mbone Sender: chip@mailserv-C.ftp.com Repository: mailserv-C.ftp.com, [message accepted at Thu Jun 8 17:36:32 1995] Originating-Client: slingshot.ftp.com Content-Length: 1200 >Generally, the comments on this list have come from people whose >points of reference is a development lab with campus fibre, and >maybe some generously provisioned T3s. This is also the environment >where CU-SeeMe was developed. This environment has practically >nothing in common with the global production Internet and I would >like people to bear this in mind. Of the commercial video conferencing packages (about 30 of them), most are designed for ISDN. This is good and bad, they are familiar with bandwidth limitations, but they're accustomed to using the whole pipe (and expect it to be steady). I have encouraged all of them to add native IP support, with IP Multicast in mind. Some are here now and more are coming and some may care more about the performance of their application than the usability of your net. It won't be long before every new pc comes equipped with a camera and people are going to be using them. chip PS I'd be more worried about the game developers, they're used to running over NetBIOS or SPX/IPX on a LAN using lots of broadcasts, they're coming too. I've also told alot of them about IP and what multicast gives them, they are very interested. From list-mgr@ISI.EDU Fri Jun 9 18:42:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 15:43:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 15:42:42 -0700 Received: from mail.mel.aone.net.au by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 15:42:40 -0700 Received: from ipx.office.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by mail.mel.aone.net.au (8.6.11/8.6.11) with ESMTP id IAA00478; Fri, 9 Jun 1995 08:42:37 +1000 Received: from ipx.office.bne.aone.net.au (ggm@ipx.office.bne.aone.net.au [203.12.179.65]) by ipx.office.bne.aone.net.au (8.6.11/8.6.12) with ESMTP id IAA17587; Fri, 9 Jun 1995 08:42:22 +1000 To: Per Gregers Bilse Cc: Rbohn@ucsd.edu (Roger Bohn), mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Thu, 08 Jun 1995 22:11:06 +0200." <199506082011.AA14038@jotun.EU.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <17581.802651340.1@ipx.office.bne.aone.net.au> Date: Fri, 09 Jun 1995 08:42:20 +1000 Message-Id: <17583.802651340@ipx.office.bne.aone.net.au> From: George Michaelson > If you are going to implement fair queuing on a router, with a large > computational overhead, why not go the next step and implement something > which gives users more control over their fate? This is similar to the 'go-faster' button that gets discussed from time to time. Apart from the technical difficulties, it implies a change to some form of metered service; all experience so far suggests that customers dislike this as much as the providers do. I've heard Van loosely describe a method of data accounting in the router which seemed no more computationally expensive than priority queuing like CBQ, which is already needed to support the more "loss-intolerant" uses of IP. Whilst not disagreeing that facing up to the real cost of dialogue proves painful, I don't think thats sufficient reason to ignore the issue. Real world solutions often seem to work well in the network, witness the apparent triumph of proof by example over design by committee. Before asserting that cost models and mechanisms like chargeback for priority can't work, or are too expensive, I'd want to see some proof. Given IPv6 which already provides for better methods of verifying sender and recipient address, and stuff like flow-id, Why is it going to be so "expensive" to credit in-router money, and decrement as part of the priority scheduling and output? Hey, if I can get a 10% rebate by agreeing to go down the bottom of the queue, I'll wear the 20% lossrate if TCP gets me (albiet slower) end-end reliability. MBONE is way cool. I don't think recognizing a slightly increased cost of bits to do some b.w. reservation or priority hurts the idea at all, and would probably have useful effect in minimising one-on-one wastage. -George From list-mgr@ISI.EDU Thu Jun 8 09:51:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 16:56:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 16:51:28 -0700 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 16:51:27 -0700 Received: from by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AB17743; Thu, 8 Jun 95 16:51:11 PDT Message-Id: <9506082351.AB17743@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Jun 1995 16:51:12 -0700 To: Henning Schulzrinne From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: Cu-SeeMe, TCP, UDP, ATM and the future of the Network Cc: mbone >ATM adapters currently police and shape hundreds of individual VP/VCs. >I assume that those that voted for ABR service in the ATM Forum have >hopes of actually implementing it on 16x155 Mb/s and up switches, again >for hundreds, if not thousands of connections. (DEC and GBC, I believe, >already have flow-controlled VCs in their switches.) Fore switches >maintain thousands of individual output queues. Etc. Thus, either doing >this for IP is so much harder (and then the IP community has a real >problem) or it's mostly a question of (relative) customer demand. I believe there is some content in my recent message to Todd Montgomery: >Date: Thu, 8 Jun 1995 10:34:04 -0700 >To:Todd Montgomery >From:jed@llnl.gov (James E. [Jed] Donnelley) >Subject:End to end VS. hop by hop error control - long> >CC: mbone@isi.edu that ties into this point. It also relates to the extensive online discussion that I had, mostly with Jon Crowcroft, relating to a proposal that I made as an alternative to ATM that I called Just In Time Switching. I can dig up that old argument (that I think your were involved in some at one point) if you are interested. I am so discouraged with what seems to me a rather mindless charging ahead in ATM forum and related bodies that rather than try to inject even the most minor redirection in front of that steam engine (heading who knows where) that I have directed my energies toward a small company working on it's own switching technologies for communications over lines owned by power companies. May as well contribute something somewhere. I am an old ARPA network technical liason from way back. I, like some of the other "old timers" still participating technically in the communications area, remember the days when decisions about technical approaches were debated in a working equivalent of the IETF. It seems to me (perhaps with rose colored glasses) that alternative strategies were more effectively aired and weighed in those days. I wonder what it is about today's communication marketplace that makes it appear to me to be careening out of control? It seems to me in much worse shape than, for example, the early aviation market, the early telephone market, or even the communication market in the early 1980s (the X.25 era). Of course I am aware of many of the forces at work, but I certainly feel powerless to help. I am not optimistic about the relatively near term future of the GII. I can easily imagine a scenario where in 3-5 years time we will all be wondering, "How did we let this happen?" This is particularly true of ATM technology. The most promising thinking in this regard I saw from Northern Telecom (now Nortel), where they described a network of 40 gbit/sec (aggregate) ATM switches surrounding a passive optical core using virtual paths to avoid cell switching in the core. I can imagine such an approach working when we get to the levels of communication needed for what I call "individual video" (i.e. high quality "MBone" sourcing for everyone), but it is a bit of a stretch. I cannot imagine ATM cell switching working throughout such a future network. This says to me that what I call ATM's "overbooking" value (i.e. saying it will provide more circuits at a given QOS than the underlying links can provide and depending on traffic variation down from the guarantees to get by) is overrated in the large. My view is that it is also overrated in the small and that for likely future technologies we would be better off with the equivalent of SONET or SDH technology with fast dynamic "real" circuit setup (on the order of one packet round trip time). While this is certainly a controversial viewpoint, I believe that any realistic debate has been silenced on any non mainstream thinking for about 2-3 years. Namely since the early Fore papers adopting the carrier (Bellcore) technology (ATM) in the computer network arena. I saw excitement like this once before when X.25 was championed by the carriers and also adopted by some computer networking folks. I believe that synergy turned out rather badly. I noticed that Germany has just recently recovered from X.25 some time while I was there last year and is now racing to embrace ATM before it is shown to be effective. There is much more energy and market force in the current ATM thrust, but the lack of effective debate and consideration of alternatives seems similar to me. Even those that question aspects of the technical approach are saying things like, "It doesn't matter if it is good technology, given enough money and effort it can be made to fly." I am not sure this is true in general though it may be in the case of ATM. What I wonder though is why we are in this situation? In the mean time we have the tremendous potential of the Web pushing up the demand for bandwidth at the same time folks are starting to put Internet telephones, and soon Internet picture phones on the network. Doesn't it seem that some sort of crunch is in the offing? --Jed http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Thu Jun 8 10:54:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 17:55:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 17:54:14 -0700 Received: from mail.ucsd.edu (ucsd.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 17:54:14 -0700 Received: from [132.239.21.192] by mail.ucsd.edu; id RAA08334 sendmail 8.6.12/UCSD-2.2-sun via SMTP Thu, 8 Jun 1995 17:53:51 -0700 X-Sender: rbohn@popmail.ucsd.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Jun 1995 17:54:03 -0700 To: George Michaelson From: Rbohn@UCSD.edu (Roger Bohn) Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: Per Gregers Bilse , mbone PB said: > This is similar to the 'go-faster' button that gets discussed from > time to time. Apart from the technical difficulties, it implies a > change to some form of metered service; all experience so far > suggests that customers dislike this as much as the providers do. > GM then said (lots omitted): >Before asserting that cost models and mechanisms like chargeback for priority >can't work, or are too expensive, I'd want to see some proof. Given IPv6 >which already provides for better methods of verifying sender and recipient >address, and stuff like flow-id, Why is it going to be so "expensive" to >credit in-router money, and decrement as part of the priority scheduling >and output? > Also, it's possible to have priorities without having money directly involved. We have suggested a quota-based systsem for dealing with this. You give your customers a ration of "quota points" for traffic from the U.S., and they specify their own priority level on traffic. Lowest priority is not charged against their quota; highest priority is charged heavily. In EUnet's case, they could explicitly say the quota is charged on packets arriving from the U.S., whether or not the packet ever arrives at the end-user. If you want "fairness", give every customer the same quota. More likely, big users would pay for quotas (in advance) at the same time they pay for pipe capacity. People who don't deal much with the U.S. don't pay extra and don't end up subsidizing those who do. [I realize that this shades over into real pricing, depending on how it is implemented, but it's not metered service in the traditional sense.] ******************************************************************* *Roger Bohn Rbohn@UCSD.edu * *Graduate School of International Relations and Pacific Studies * *University of California, San Diego 92093-0519 * ******************************************************************* From list-mgr@ISI.EDU Fri Jun 9 22:06:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 19:12:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 19:07:19 -0700 Received: from mail.mel.aone.net.au by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 8 Jun 1995 19:07:17 -0700 Received: from ipx.office.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by mail.mel.aone.net.au (8.6.11/8.6.11) with ESMTP id MAA01271; Fri, 9 Jun 1995 12:07:14 +1000 Received: from ipx.office.bne.aone.net.au (ggm@ipx.office.bne.aone.net.au [203.12.179.65]) by ipx.office.bne.aone.net.au (8.6.11/8.6.12) with ESMTP id MAA17936; Fri, 9 Jun 1995 12:06:59 +1000 To: Rbohn@ucsd.edu (Roger Bohn) Cc: Per Gregers Bilse , mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Thu, 08 Jun 1995 17:54:03 MST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <17929.802663617.1@ipx.office.bne.aone.net.au> Date: Fri, 09 Jun 1995 12:06:57 +1000 Message-Id: <17931.802663617@ipx.office.bne.aone.net.au> From: George Michaelson Also, it's possible to have priorities without having money directly involved. Again, to paraphrase my understanding of what Van was saying, having real money hit the desk was *part* of congestion control, albiet over a longer timebase than just one context of IP packet exchanges. Too many people think there is no cost attached to the bits on the wire because they don't attend the meetings where accountants scream because the IP costs just doubled again, inside one financial years budgetary limit. The per-bit cost might be infinitessimally small, but once you collect a terabyte of them, it actually does have a dollar cost. Perhaps if some of the 500kbps black-square TV emitters actually saw the pricepoint for sending that signal to the wide horizon, they'd learn to re-scope the TTL a bit faster.. Obviously this is a reactionary move. But at the cost of a couple of painful lessons, it might help people to re-assess their impact on shared infrastructure, and that too is part of scaling networks. I would expect cost of delivery to lie well within existing pricepoints for this kind of framework to fly: lets not start flinging the $million sums Federal bodies spend to provision T3 links around, if we really just mean the price on the ethernet for Lance Berc to send MBONE for 1 hour of some thrash-rock band... -George From list-mgr@ISI.EDU Fri Jun 9 09:38:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 00:44:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 00:39:53 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 00:39:51 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 9 Jun 1995 00:39:44 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 9 Jun 1995 08:38:34 +0100 To: Tony Li Cc: Steve Deering , mbone, Geert Jan de Groot , max@guest.apple.com (Mark Q. Maxham), Scott W Brim , Per Gregers Bilse , Vadim Antonov In-Reply-To: Your message of "Thu, 08 Jun 95 12:04:22 PDT." <199506081904.MAA17497@greatdane.cisco.com> Date: Fri, 09 Jun 95 08:38:30 +0100 Message-Id: <738.802683510@cs.ucl.ac.uk> From: Jon Crowcroft > > >CPU is involved, and a beefed-up macintosh CPU will have severe > >problems switching T3 or anything like that... > > this is Router Vendor mythology - that they can't do T3 on a standard > processor - > >No, this is Router Vendor Critic mythology. First, a cisco 7000 can >clearly do T3 while fast switching (see Bradner testing). Second the >AMD 2901 _is_ a standard processor. Tony so all we need now is to replace all the PoP routers in the world with cisco 7000s......and use your prioprity queueing mechanisms.... excellent... jon oh why didn't i buy cisco shares back in the 80s? From list-mgr@ISI.EDU Thu Jun 8 18:00:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 01:05:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 01:03:14 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 01:03:13 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA22259; Fri, 9 Jun 1995 01:00:30 -0700 Date: Fri, 9 Jun 1995 01:00:30 -0700 From: Tony Li Message-Id: <199506090800.BAA22259@greatdane.cisco.com> To: J.Crowcroft@cs.ucl.ac.uk Cc: deering@parc.xerox.com, mbone, GeertJan.deGroot@ripe.net, max@guest.apple.com, swb1@cornell.edu, bilse@eu.net, avg@sprint.net In-Reply-To: <738.802683510@cs.ucl.ac.uk> (message from Jon Crowcroft on Fri, 09 Jun 95 08:38:30 +0100) so all we need now is to replace all the PoP routers in the world with cisco 7000s...... Correct, until you said and use your priority queueing mechanisms.... ummm... There are other architectural problems with the 7000 other than just brute CPU power that make fancy-assed queueing at backbone rates infeasible. Before someone flames us again for not keeping up with the research community, please note that hindsight is 20/20. If we had known in 1988 that we needed to do CSZ, things might well have been different. oh why didn't i buy cisco shares back in the 80s? Because cisco didn't go public until Feb. 1990. ;-) Tony From list-mgr@ISI.EDU Fri Jun 9 10:16:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 01:25:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 01:19:18 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 01:19:17 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 9 Jun 1995 01:19:10 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 9 Jun 1995 09:17:08 +0100 To: George Michaelson Cc: mbone Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications In-Reply-To: Your message of "Fri, 09 Jun 95 12:06:57 +0900." <17931.802663617@ipx.office.bne.aone.net.au> Date: Fri, 09 Jun 95 09:16:59 +0100 Message-Id: <1055.802685819@cs.ucl.ac.uk> From: Jon Crowcroft >Too many people think there is no cost attached to the bits on the wire >because they don't attend the meetings where accountants scream because >the IP costs just doubled again, inside one financial years budgetary limit. a brief history of timeliness is mabe called for... the question of the mbone and other related traffic is not bit counting, but bitrate and jitter bitrate is what costs the providers to put in the ground (although the amount of raw fiber at least i nthe UK truly avaialble is actually massivley more than the prices would have you believe - there is also the question of simply deploying tail circuits, routers and switches) jitter costs you control algorithms and buffering to deploy... as van says (and tyhe CBQ and CSZ code implement), it is feasible to distinguish the traffic types in real time in decent router platforms, and then forwars - the only problem is when the system is congested if a source is adaptive (e.g. tcp, or IVS or recent NFS implementations), then there is no reason to incur any usage charge.....it will only increase the recurrent costs of the provider, and decrease the number of subscribers they get if a source is constant rate, then at congestion time, it causes all the adaptive applications to back off this is not necessarily a problem, unless one of two things happen i) the sum of constant rate traffic exceeds the providers backbone provision or ii) the sum of cosntant rate traffic is such that the remaining bandwidth is insufficient for any adaptive to proceed effectively (i.e. below 1 packet per RTT per adaptive application, i believe) at this point, you need to "adapt" the constant rate applications how to do this? easy, you adapt them collectively by reducing the number of them, or by increasing the avbailable bandwidth provided. in the short term ,this is done by charging for flows that need a minimum rate during congested periods (note, you only _need_ to do it when the net is congested, but you might have a bean counter who says do it at other times too - it depends on your business policy, not anythign technical). you then use the mony from this charge to increase your backbone bandwidth in the medium/longterm, so again, you get more subscribers...... there are a couple of important pieces of technology here - 1 is packet accounting, and the other is source authentication....without them, it will be hard to proive a bill is valid in court.... cheers jon From list-mgr@ISI.EDU Fri Jun 9 10:28:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 01:34:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 01:29:34 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 01:29:34 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 9 Jun 1995 01:29:32 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 9 Jun 1995 09:28:51 +0100 To: mbone Subject: Formal Apology to EUnet GB Date: Fri, 09 Jun 95 09:28:39 +0100 Message-Id: <1093.802686519@cs.ucl.ac.uk> From: Jon Crowcroft I have agreed to apologise to EUnet for a number of points in the initial message I sent on the mbone list, since they are misleading, and have been quoted out of context elsewhere (without my permission, note). If they are still being quoted, then I disclaim them. specifically, in the comments here, there are 4 points which were totally wrong about EUnet, and I completely withdraw. >the provider below (i'm not going to name them, but they are a UK >provider who underprovisions their backbone) would have you ban DNS >and SNMP by their arguments (actually, TCP based DNS and SNMP might >not be a nbad idea, but thats another story) EUnet do not "underprovision" their backbone in any sense that any good Internet provider does. Their message makes clear that they do distinguish "well behaved" UDP based applications from poor ones. >they are threatening their subscribers with this, and they are WRONG >- their subscreibers (I know one group is) wil lmove to other >providers who have properly provisoned backbones... Their message is clearly not a threat to a subscriber. My point is hyperbole, and should be ignored. >tyhe problem they allude to is simply one that requires either a >decent backbone, or without one the advent of RSVP....or else a POP >architecture (e.g. the BT and Pipex Internet services both have) that >protects the net... Since I had misinterpreted who the message was from, I could not be referring to the EUnet PoP architecture, which I do not know about (I cited the BT and Pipex ones as they are often discussed publicly). I believe the EUNet PoP is as good as any good Internet provider's. It is a pity that the long discussion that ensued which contained many useful technical points, contninued to have the same subject line, and I apologise again to EUnet, and make it clear that there was no intention to associate the incorrect points above with the technical points made later. Jon Crowcroft From list-mgr@ISI.EDU Fri Jun 9 14:20:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 05:22:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 05:21:36 -0700 Received: from tamdhu.dcs.st-andrews.ac.uk (tamdhu.dcs.st-and.ac.uk) by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 05:21:33 -0700 Received: from bushmills.dcs.st-and.ac.uk by tamdhu.dcs.st-andrews.ac.uk (4.1/SMI-4.1) id AA08441; Fri, 9 Jun 95 13:21:41 BST Message-Id: <9506091221.AA08441@tamdhu.dcs.st-andrews.ac.uk> To: Jon Crowcroft Cc: mbone Subject: UDP spamming. Was Re: EUnet GB policy on Cu-SeeMe ... In-Reply-To: Your message of "Fri, 09 Jun 1995 09:16:59 BST." <1055.802685819@cs.ucl.ac.uk> Date: Fri, 09 Jun 1995 13:20:31 +0100 From: "Paul Harrington" Jon> the short term ,this is done by charging for flows that need a Jon> minimum rate during congested periods (note, you only _need_ to Jon> do it when the net is congested, but you might have a bean This is what I was attempting to suggest in my mail message from a few days back. However, from the responses which I got, there appears to be a fairly big difference of opinion between service providers and researchers as to whether it is 'possible'. To paraphrase _very_ heavily, NOC people say 'the routers would fall over', researchers say 'we have known how to do this stuff since the late 80s'. Is it that one party wants something that it can run _now_ on its 7000 or whatever, and that the other party has demonstrated a proof of concept? As someone on the sidelines not knowing a great deal of detail about protocols nor router design, it is not clear how difficult a task it would be to incorporate CBQ or one of its friends into high-performance production routers. The only thing that I think everyone agrees on is that -- to use the classic phrase -- "something needs to be done".... While I can understand the concern from ISPs about sustained packet attacks from applications like Cu-SeeMe, I think that the service agreement is a bit of a blunt instrument to apply to the problem. So ... any concrete suggestions for what can be deployed within the next six months? pjjH Paul Harrington, phrrngtn@dcs.st-andrews.ac.uk +44 1334 463261 Division of Computer Science, St Andrews University, Scotland KY16 9SS From list-mgr@ISI.EDU Fri Jun 9 08:41:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 09:43:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 09:43:02 -0700 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 09:43:01 -0700 Received: from [132.236.199.54] (PHANTOM.CIT.CORNELL.EDU [132.236.199.54]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id MAA20646 for ; Fri, 9 Jun 1995 12:42:58 -0400 X-Sender: rc19@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Jun 1995 12:41:40 -0400 To: mbone From: R.Cogger@cornell.edu (Richard Cogger) Subject: Re: EUnet GB policy on Cu-SeeMe ... Folks, Sorry to be late into this discussion, but I hadn't been reading the mbone list (would have expected something like this to show up on rem-conf, but oh well...). I won't try to comment on all of the issues, but I would like to supply clear info about where CU-SeeMe is and where it's going in the near future. Btw, several of the participants in the discussion seemed to be well clued in to most of all of the following, but as others were not, here goes: 1. CU-SeeMe never sends video or audio to anyone who is not requesting it. It never sends a particular video stream unless the receiver has a window open for it. 2. By default, current versions do not open windows automatically when someone new joins a conference-- but of course, users may change this preference item so windows do open automatically. 3. There is a limit of 8 windows. Yes that can be quite a lot of bandwidth, but it's not completely unlimited. 4. Reflector operators can configure a limit on sending rate. Anyone sending more will get booted off. There are also extensive facilities for limiting who and how many folks can use a particular reflector. 5. Senders adapt the sending rate based on loss reports from receivers. The adaptation operates between a min and max set by the user, default 10 and 80 kbps, respectively. Currently, it adapts quite fast, taking no more than a 10 or 15 seconds to go down to the min. When the reported loss is over 5% it goes down, when it is under 5% it goes up. Yes, this is probably not responsive enough for many congestion cases. We will improve it, but there is a more serious problem. 6. Senders adapt acording to the aggregate loss of all receivers reporting. This means that someone hooking into a busy reflector with a modem and opening even 3 or 4 windows will be asking for a flood to his slip server and will then report, say, 95% loss. But that may be only a small % in the aggregate if other participants have good, uncongested, high-bandwidth paths. Having a sender try to adapt to many receivers with different path-sizes is also an intrinsic problem for multicast conferences, of course. Almost ready to release (but probably not going out for a few weeks more, unhappily) are new versions of both the reflector and the end-system application. The application will be able to specify max and min values for a receive cap, which the reflector will honor, adapting the stream to each participant (by dropping video packets) based on receiver reports. We're using receiver loss reports, but we're looking at using also delay increases to get a faster response, as with tcp. Reflector operators will be able to configure limits on allowable values for participant receive cap limits. We will also look at some sort of slow-start. Altogether, these changes should come pretty close to the suggestion someone made of tcp without re-transmission. These additions should completely solve the problem of a modem user wastefully sucking in much more than the slip-server can push down the modem link. Of course, it may not be a complete solution to keep someone from overusing congested international links. In general, I think we can provide controls that allow users to be as polite to other streams as they wish. Also, we will add controls to the reflector so that reflector operators can enforce any level of politeness they wish on participants using their reflector; but there is no such enforcement availble for a 2-party direct hookup. Perhaps we should not give users the option of being impolite; I would be happy to hear opinions on this issue. (Of course, as we release source code in the near future, capable users will be able to bypass whatever we do.) In the larger view of things, we certainly do need some help from the network switching elements if real-time and other traffic are going to both get what they need. As the bandwidth of network links increases, the situation (when congestion occurs) only gets worse. To ensure that links can be fully utilized with tcp traffic, you need buffering at routers/switches more or less equal to a roundtrip bw-delay product to avoid packet drops (and wasteful resends). But with real-time traffic, you want a router to either forward a packet soon or drop it right away, not queue it behind a great heap of ftp traffic. Note that, as others have pointed out, this is not a tcp/udp issue: you can use udp for non-realtime traffic, and echoplex telnet is tcp with a realtime requirement. Even a relatively simple two- or three-class queueing implementation, widely deployed, would be a great advance. Any suggestions for technical or other things we can do to make CU-SeeMe a good citizen (even when in the hands of non-techies) would be appreciated. By the way, if it becomes necessary for anyone to filter CU-SeeMe traffic, everything to/from an end-system is on UDP port 7648, and inter-reflector traffic will be on 7649, 50, and 51. -Dick Cogger From list-mgr@ISI.EDU Fri Jun 9 10:28:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 11:30:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 11:29:55 -0700 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 11:29:54 -0700 Received: from [132.236.199.54] (PHANTOM.CIT.CORNELL.EDU [132.236.199.54]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id OAA05033; Fri, 9 Jun 1995 14:29:46 -0400 X-Sender: rc19@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Jun 1995 14:28:27 -0400 To: Geert Jan de Groot From: R.Cogger@cornell.edu (Richard Cogger) Subject: Re: EUnet GB policy on Cu-SeeMe ... Cc: mbone >On Fri, 9 Jun 1995 12:41:40 -0400 Richard Cogger wrote: >> 5. Senders adapt the sending rate based on loss reports from receivers. >> The adaptation operates between a min and max set by the user, default 10 >> and 80 kbps, respectively. Currently, it adapts quite fast, taking no more >> than a 10 or 15 seconds to go down to the min. When the reported loss is >> over 5% it goes down, when it is under 5% it goes up. Yes, this is >> probably not responsive enough for many congestion cases. We will improve >> it, but there is a more serious problem. > >Why don't you start with 10kbps and throttle _up_ instead of down? >That is a one-line change, and might make many NOCpeople happy.. > >Geert Jan OK, we'll do it. (It will start at the Min, default value 10.) For two-party connections, it should be effective; but for connecting to a multiparty conference, senders will already have worked up to their levels, so it won't help much. Also, I'm not sure how quickly folks will pick up a new version with just that change. It is easy enough to do, though, so we'll get it out in a couple of days. -Dick From list-mgr@ISI.EDU Fri Jun 9 11:31:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 12:32:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 12:31:58 -0700 Received: from runningman.rs.itd.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 12:31:57 -0700 Received: from hendrix.itn.med.umich.edu by runningman.rs.itd.umich.edu (8.6.9/2.25) with SMTP id PAA19732; Fri, 9 Jun 1995 15:31:56 -0400 Date: Fri, 9 Jun 1995 15:31:50 -0400 (EDT) From: Jauder Ho Subject: IP_ADD_MEMBERSHIP: Cannot assign requested address To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I was trying to get multicasting to work and I recompiled the kernel with multicasting turned on but it gives me the error above. any clues? please e-mail me directly as I am not subscribe to this list. thanks... --Jauder ==================================================================== Jauder Ho http://spwww.mcit.med.umich.edu/~jauderho/ Special Projects jauderho@med.umich.edu Medical Center Information Technology (MCIT) University of Michigan Medical Center, B1911 CFOB 1414 Catherine Street, Ann Arbor, MI 48109-0704 (313) 936-4897 ==================================================================== From list-mgr@ISI.EDU Fri Jun 9 07:56:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 14:57:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 14:56:15 -0700 Received: from mail.ucsd.edu (ucsd.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 14:56:13 -0700 Received: from [132.239.21.192] by mail.ucsd.edu; id OAA09490 sendmail 8.6.12/UCSD-2.2-sun via SMTP Fri, 9 Jun 1995 14:56:09 -0700 X-Sender: rbohn@popmail.ucsd.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Jun 1995 14:56:13 -0700 To: R.Cogger@cornell.edu (Richard Cogger) From: Rbohn@UCSD.edu (Roger Bohn) Subject: Re: EUnet GB policy on Cu-SeeMe ... Cc: mbone Two additional suggestions for Cu-SeeMe and making it more polite: 1. Be sure that when the image does not change, the refresh rate gets VERY low-- the minimum needed to keep the connection alive. 2. Provide some feedback to the human operator of the transmitter. At present, even a well-intentioned user cannot tell whether they are causing (or experiencing) congestion on their transmission. It sounds from your message that, at least in the case of reflectors, there is feedback from receivers about what's happening. Why can't that feedback be displayed in a graphical format, either in its own window, or on the existing control panel. For example shades of gray, or a light which goes from green to red, depending on how long the lags are. At 9:41 AM 6/9/95, Richard Cogger wrote: > >In general, I think we can provide controls that allow users to be as >polite to other streams as they wish. Also, we will add controls to the >reflector so that reflector operators can enforce any level of politeness >they wish on participants using their reflector; but there is no such >enforcement availble for a 2-party direct hookup. Perhaps we should not >give users the option of being impolite; I would be happy to hear opinions >on this issue. (Of course, as we release source code in the near future, >capable users will be able to bypass whatever we do.) > >In the larger view of things, we certainly do need some help from the >network switching elements if real-time and other traffic are going to both >get what they need. As the bandwidth of network links increases, the >situation (when congestion occurs) only gets worse. To ensure that links >can be fully utilized with tcp traffic, you need buffering at >routers/switches more or less equal to a roundtrip bw-delay product to >avoid packet drops (and wasteful resends). But with real-time traffic, you >want a router to either forward a packet soon or drop it right away, not >queue it behind a great heap of ftp traffic. Note that, as others have >pointed out, this is not a tcp/udp issue: you can use udp for non-realtime >traffic, and echoplex telnet is tcp with a realtime requirement. Even a >relatively simple two- or three-class queueing implementation, widely >deployed, would be a great advance. > >Any suggestions for technical or other things we can do to make CU-SeeMe a >good citizen (even when in the hands of non-techies) would be appreciated. >By the way, if it becomes necessary for anyone to filter CU-SeeMe traffic, >everything to/from an end-system is on UDP port 7648, and inter-reflector >traffic will be on 7649, 50, and 51. From list-mgr@ISI.EDU Fri Jun 9 14:28:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 15:27:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 15:27:05 -0700 Received: from trystero.radio.com by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 9 Jun 1995 15:27:04 -0700 Received: (carl@localhost) by trystero.radio.com (8.6.12/940816.06ccg) id SAA20811 for mbone@isi.edu; Fri, 9 Jun 1995 18:28:56 -0400 From: Carl Malamud Message-Id: <199506092228.SAA20811@trystero.radio.com> Subject: U.S. Congressional Hearing: Economy in the 21st Century ( To: mbone Date: Fri, 9 Jun 1995 18:28:55 -0400 (EDT) Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3213 The Joint Economic Committee of the U.S. Congress will be holding special hearings on Monday, June 12 on the subject of "The Economy in the 21st Century." Senator Connie Mack of Florida has requested the public to comment before and during the hearing using electronic mail at jec@town.hall.org. Senator Mack will select some of the questions received via the Internet and ask them to the witnesses. On-line information about the hearing is available on the World Wide Web at: http://town.hall.org/places/jec You may send your electronic mail starting now to: jec@town.hall.org Audio from the hearings will be available starting at 9:30 ET, 6/12 on our IMS: House feed at: n=3426678340 3426678340 789231042 s=IMS: U.S. House i=U.S. House of Representatives at http://town.hall.org/radio/live.html o=carl@also.radio.com c=224.2.245.77 127 0 0 m=audio 37352 32820 a=fmt:gsm Senator Mack's message regarding the hearings follow: Joint Economic Committee Chairman's Opening Remarks Monday, June 12, 1995 A 21st Century Hearing on the 21st Century Economy America and the world are entering a new era. Already we are witnessing unparalleled change in the global economy, in technology and communications, in business and industry, and in Communities and families. Industrial Age government is obsolete -- government in the Knowledge Age must become dramatically smarter, smaller, and simpler. With the right changes in government, the technologies of today will lead to a new world of opportunity and growth tomorrow. Government must be redesigned, and its policies reformed, to maximize freedom for entrepreneurs and to build new avenues for individual creativity and prosperity. We have invited Paul Johnson, Alvin Toffler, Joel Kotkin, Steve Forbes, Congressman Bob Walker, Robert Genetski, Jerry Jasinowski, Frederic Pryor, Brenda French and Marc Holtzman to give their perspective on the economy in the 21st Century and make policy recommendations on the role of government in the Knowledge Age. This will be the first Congressional hearing to make full use of interactive video teleconference technology. It will link Members of Congress, witnesses, and citizens in a discussion to be broadcast on cable television and put on-line on the Internet. Members of the Committee will assemble in the hearing room in the Dirksen Building in Washington, D.C. Witnesses will testify from Capitol Hill and from remote locations around the nation and from Europe via an interactive audio/video network. The television and on-line audience will be able to follow the proceedings in real time and submit questions to the Joint Economic Committee via the Internet Multicasting Service. In short, this will be a 21st Century-style hearing on the 21st Century Economy. It is sure to be a bold exploration of what the American and global eocnomy will look like in the 21st Century and how opportunity and prosperity can be expanded for all Americans. It also promises to be an innovative step toward what will be a more accessible and participatory democracy in the 21st Century. ============ END OF REMARKS =============================== From list-mgr@ISI.EDU Sat Jun 10 16:39:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 07:41:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 07:40:52 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 07:40:52 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Sat, 10 Jun 1995 07:40:49 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 10 Jun 1995 15:39:50 +0100 To: R.Cogger@cornell.edu (Richard Cogger) Cc: mbone Subject: Re: EUnet GB policy on Cu-SeeMe ... In-Reply-To: Your message of "Fri, 09 Jun 95 14:28:27 EDT." Date: Sat, 10 Jun 95 15:39:44 +0100 Message-Id: <6430.802795184@cs.ucl.ac.uk> From: Jon Crowcroft >OK, we'll do it. (It will start at the Min, default value 10.) For >two-party connections, it should be effective; but for connecting to a >multiparty conference, senders will already have worked up to their levels, >so it won't help much. Also, I'm not sure how quickly folks will pick up a >new version with just that change. It is easy enough to do, though, so >we'll get it out in a couple of days. Dick surely a reflector could treat each fanout spearately, and new receivers joing to a reflector get a throttle up (slow start) same as pomint to point? jon From list-mgr@ISI.EDU Sat Jun 10 16:58:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 08:01:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 07:59:45 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 07:59:35 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Sat, 10 Jun 1995 07:58:53 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 10 Jun 1995 15:58:10 +0100 To: Paul Harrington Cc: mbone Subject: Re: UDP spamming. Was Re: EUnet GB policy on Cu-SeeMe ... In-Reply-To: Your message of "Fri, 09 Jun 95 13:20:31 BST." <9506091221.AA08441@tamdhu.dcs.st-andrews.ac.uk> Date: Sat, 10 Jun 95 15:58:06 +0100 Message-Id: <6775.802796286@cs.ucl.ac.uk> From: Jon Crowcroft >So ... any concrete suggestions for what can be deployed within the >next six months? Paul once upon a time, we could put out a change to TCP (Van's for example) or a new idea like multicast, and it would be in a few 100 sites in weeks, and 95% of the "open" bits of the internet in months and products within the year....[the closed biuts of the internet are a closed book....sometiems they have >10 year write off for kernel code:-] nowadays, "deployment" is a dirty word.... if the "market penetration" of later versions of mrouted are anything to go by, it will be a decade before we have anything like cbq or csz in rotuers out there (remember, its no use unless its i nthe bottleneck - the rate limiting in the mbone virtual/tunnel routers only stops us overloading them, it doesn't stop them overloading us...!) cheers jon From list-mgr@ISI.EDU Sat Jun 10 20:54:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 09:59:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 09:54:48 -0700 Received: from eunet.EU.net by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 09:54:42 -0700 Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id SAA02174; Sat, 10 Jun 1995 18:54:35 +0200 Received: by jotun.EU.net id AA19955 (5.67a/IDA-1.5); Sat, 10 Jun 1995 18:54:34 +0200 Message-Id: <199506101654.AA19955@jotun.EU.net> From: Per Gregers Bilse Date: Sat, 10 Jun 1995 18:54:34 +0200 In-Reply-To: <9506091221.AA08441@tamdhu.dcs.st-andrews.ac.uk> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: "Paul Harrington" Subject: Re: UDP spamming. Was Re: EUnet GB policy on Cu-SeeMe ... Cc: mbone, dj@Britain.EU.net, koen@Belgium.EU.net On Jun 9, 13:20, "Paul Harrington" wrote: > While I can understand the concern from ISPs > about sustained packet attacks from applications like Cu-SeeMe, I > think that the service agreement is a bit of a blunt instrument to > apply to the problem. There are no other options and it isn't even particularly blunt. I have to smile (friendly) a little,-) ... have you never seen this: Unacceptable Use 9. JANET may not be used for any of the following: [...] 9.7. deliberate activities with any of the following characteristics: wasting staff effort or networked resources, including time on end systems accessible via JANET and the effort of staff involved in the support of those systems; corrupting or destroying other users' data; violating the privacy of other users; disrupting the work of other users; using JANET in a way that denies service to other users (for example, deliberate or reckless overloading of access links or of switching equipment); continuing to use an item of networking software or hardware after UKERNA has requested that use cease because it is causing disruption to the correct functioning of JANET; [...] Compliance [...] 16. It is preferable for misuse to be prevented by a combination of responsible attitudes to the use of JANET resources on the part of users and appropriate disciplinary measures taken by their Organisations. I don't think you or anybody else really disagree with the above. What you have seen is that we were (among) the first to notice the effects of CU-SeeMe and say "hey, hey, wait a minute". We noticed, mostly because we monitor load on our core infrastructure very carefully (among other things, with real time graphical displays); and we got hit because international and European bandwidth is an order of magnitude tighter than US domestic bandwidth. It also doesn't help to have a sizeable number of dial-up hobby users, which is by far the largest majority of current CU-SeeMe users. > So ... any concrete suggestions for what can be deployed within the > next six months? Whether people believe it or not, the machinery to deploy tight policing and protection of Internet resources on a large scale doesn't exist, and controlling/solving problems after they have surfaced is never as good as not having the problems in the first place. If one visits an oil refinery, one is not allowed to smoke; arguing that they should just install better firefighting equipment will attract sarcastic comments. Just as I'm sitting here typing (no joke, no 'effect', this is happening right now), a display over on the left goes red; here's why: Source Destination Packets Kbytes -------------------------------------------------------------------------- *axon.kent.edu dialup22.brussels.eunet.be 119040 30922 K This is for 5 minutes; the traffic from axon.kent.edu averages 400pps and 825kbits/sec. I have no idea if this is (point-to-point) CU-SeeMe or some other funny application, but I don't think it's a deliberate denial-of-service attack on dialup22.brussels.eunet.be; this is something turned on by dialup22.brussels.eunet.be themselves, whoever they may be -- chances are they had no idea whatsoever what they were doing. The note from EUnet GB should also be seen in that light: it is not a scientific reference work, it's a technical and administrative note intended to be understood by people who don't know how to cancel a mailing list subscription ("unsubscribe"). What is clearly needed is for CU-SeeMe and similar applications to be much more Internet friendly and I'm encouraged by Richard Cogger's notes, but not exactly overjoyed. And I find it truly remarkable, for lack of a better word, when I hear people say "this isn't my responsibility". -- === ___ === Per G. Bilse, Mgr Network Operations Ctr === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Sat Jun 10 12:00:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 13:02:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 13:02:26 -0700 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 13:02:25 -0700 Received: from [132.236.199.54] (PHANTOM.CIT.CORNELL.EDU [132.236.199.54]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id QAA16964; Sat, 10 Jun 1995 16:02:12 -0400 X-Sender: rc19@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 10 Jun 1995 16:00:53 -0400 To: Jon Crowcroft From: R.Cogger@cornell.edu (Richard Cogger) Subject: Re: EUnet GB policy on Cu-SeeMe ... Cc: mbone At 10:39 AM 6/10/95, Jon Crowcroft wrote: > >OK, we'll do it. (It will start at the Min, default value 10.) For > >two-party connections, it should be effective; but for connecting to a > >multiparty conference, senders will already have worked up to their levels, > >so it won't help much. Also, I'm not sure how quickly folks will pick up a > >new version with just that change. It is easy enough to do, though, so > >we'll get it out in a couple of days. > >Dick > >surely a reflector could treat each fanout spearately, and new >receivers joing to a reflector get a throttle up (slow start) same as >pomint to point? > > jon Jon, Yes of course. I was replying to the request for a quick one-line change. The work on the reflector to have it treat each receiver individually is mostly done, at least for its first version, and we can put slow start into that as well, but the whole package will be a few more weeks to finish and get out. -Dick From list-mgr@ISI.EDU Sat Jun 10 12:40:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 13:42:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 13:42:24 -0700 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 13:42:23 -0700 Received: from [132.236.199.54] (PHANTOM.CIT.CORNELL.EDU [132.236.199.54]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id QAA18505; Sat, 10 Jun 1995 16:42:18 -0400 X-Sender: rc19@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 10 Jun 1995 16:40:59 -0400 To: brutzman@cs.nps.navy.mil (Don Brutzman) From: R.Cogger@cornell.edu (Richard Cogger) Subject: Re: EUnet GB policy on Cu-SeeMe ... Cc: mbone >I was disappointed to not see anything in your message about >multicast. It leaves the impression that you will continue to make >CU-SeeME a dangerous tool that consumes excessive bandwidth with each >successive user, requiring labor-intensive reflectors that are >unlikely to be well matched to the bandwith capacity of actual links. > There are a lot of issues involved in going to multicast, but when we can, we will. Apple's mcast code (part of their OpenTransport package) is supposed to be out soon (in a solid version), perform reasonably sometime after that, and be in most folks hands, perhaps by early '96. A more serious problem is the following: How soon do you estimate that a typical non-techie Internet user will be able to just use IP mcast, without having to consult with a network admin, etc. to get access to the mbone? What fraction of current Internet users would you estimate have access to the mbone? What fraction in a year? Of course, I agree that mcast is the way to go for anything approaching a "broadcast" of some event. Setting up cascades of reflectors is not a satisfactory approach. However, a 2-party conference clearly won't benefit from mcast (excuse me for stating the obvious) and it's not so obvious that a 3- or 4-party conference benefits that much. In fact, the ability of a reflector to operate with application-level knowledge of codings, receiver preferences, and such, customizing streams to each recipient is a significant advantage. Presently, I believe, if you join an mbone conference which has, say 6 senders, you will receive all 6 video streams, even if you only open windows for 2 of them, and you will receive each stream at the full bandwidth (minus dropped packets) the sender sends it. Of course, future developments will provide source-specific pruning, layered encodings, and so on. For conferences of modest size, we'll get there sooner with a reflector arcitecture. But please don't mark me down as being anti-multicast. Actually, I think the best results are ultimately going to come from a combination of topology-aware multicast routing with application-aware relay points, such as reflectors. >Making CU-SeeMe MBone-compatible will greatly reduce bandwidth >problems, will allow Macs to send/receive programs on the MBone, and will >avoid reflector difficulties. I am worried that CU-SeeMe will break >the frame relay cloud we have set up for schools in our two counties, >where average school access is 128 Kbps. > We would also have to implement the encodings, and at least a good part of the currently deployed Mac (and Windows) fleet lacks the oomph to handle it. I'm not sure which reflector difficulties you have in mind; but we would also forego reflector opportunities. But like I said, we are going to do it when and as it becomes feasable, but I expect we will keep on with the reflector too. Do you expect to be able to handle multi-party mbone conferencing on this frame-relay cloud? I don't think you can do very successful multiparty conferencing on a network of that capacity (unless maybe if you dedicate it for a single conference) with either carefully engineered mbone tunnels or with a carefully engineered reflector net. I can't guess which way you could have a least unsatisfactory result, but I doubt the difference will be large. -Dick From list-mgr@ISI.EDU Mon Jun 12 00:42:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 21:39:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 21:37:21 -0700 Received: from godzilla.zeta.org.au by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 21:37:07 -0700 Received: from [192.0.2.1] (godzilla.zeta.org.au [203.2.228.34]) by godzilla.zeta.org.au (8.6.9/8.6.9) with SMTP id OAA29040 for ; Sun, 11 Jun 1995 14:32:42 +1000 X-Sender: garrison@godzilla.zeta.org.au Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 11 Jun 1995 14:42:38 +1000 To: mbone From: garrison@zeta.org.au (Charlie Garrison) Subject: unsubscribe unsubscribe From list-mgr@ISI.EDU Mon Jun 12 00:56:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 21:58:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 21:56:49 -0700 Received: from mail.mel.aone.net.au by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 21:56:47 -0700 Received: from ipx.office.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by mail.mel.aone.net.au (8.6.11/8.6.11) with ESMTP id OAA06624; Sun, 11 Jun 1995 14:56:44 +1000 Received: from ipx.office.bne.aone.net.au (ggm@ipx.office.bne.aone.net.au [203.12.179.65]) by ipx.office.bne.aone.net.au (8.6.11/8.6.12) with ESMTP id OAA28236; Sun, 11 Jun 1995 14:56:29 +1000 To: R.Cogger@cornell.edu (Richard Cogger) Cc: brutzman@cs.nps.navy.mil (Don Brutzman), mbone Subject: Re: EUnet GB policy on Cu-SeeMe ... In-Reply-To: Your message of "Sat, 10 Jun 1995 16:40:59 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <28230.802846587.1@ipx.office.bne.aone.net.au> Date: Sun, 11 Jun 1995 14:56:28 +1000 Message-Id: <28232.802846588@ipx.office.bne.aone.net.au> From: George Michaelson How soon do you estimate that a typical non-techie Internet user will be able to just use IP mcast, without having to consult with a network admin, etc. to get access to the mbone? What fraction of current Internet users would you estimate have access to the mbone? What fraction in a year? Easy! just get NIC assigned handles for the 3-4 defined multicast addresses for A-V usage and emit multicast at a low ttl. It'll give them nice stuff on the local ether and THEN they can get a tunnel into the real glue. I don't see this as any harder than plugging people together using explicit unicast sets. Wire in a nice name like chat.local.multicast.net at ttl < 32 and it'll fly... -George From list-mgr@ISI.EDU Sun Jun 11 05:09:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 06:07:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 06:06:10 -0700 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 06:06:08 -0700 Received: from [132.236.155.33] (CU-DIALUP-0719.CIT.CORNELL.EDU [132.236.155.33]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id JAA17348; Sun, 11 Jun 1995 09:06:03 -0400 X-Sender: rc19@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 11 Jun 1995 09:09:18 -0400 To: Rbohn@UCSD.edu (Roger Bohn) From: "Dick Cogger" (Richard Cogger) Subject: Re: EUnet GB policy on Cu-SeeMe ... Cc: mbone >Two additional suggestions for Cu-SeeMe and making it more polite: > >1. Be sure that when the image does not change, the refresh rate gets VERY >low-- the minimum needed to keep the connection alive. > Well, it already is quite low, if the image really doesn't change. But we can probably make it lower; will check on it. However, a big problem sometimes is a slightly noisy source, ether the camera, or something about the scene. For example, I had a camera pointed at another screen (just happened to be in the frame) which was running a screensaver of a starfield--almost totally black. But apparently, the tube emits some sort of IR or something which the camera caught and the change detection algorithm interpreted as 40Kbps of scene change. Probably what we need to do is continual backoff of the aging rate. >2. Provide some feedback to the human operator of the transmitter. At >present, even a well-intentioned user cannot tell whether they are causing >(or experiencing) congestion on their transmission. It sounds from your >message that, at least in the case of reflectors, there is feedback from >receivers about what's happening. Why can't that feedback be displayed in >a graphical format, either in its own window, or on the existing control >panel. For example shades of gray, or a light which goes from green to >red, depending on how long the lags are. Actually, you *can* monitor congestion fairly well. You can readily see when the send cap runs down, which would be an indication of aggregate loss greater than 5% currently, it is displayed under your local window. Also, there is a stats panel available under each remote window that shows loss % for both send and recv to/from that user. We can look at improving things to have, for example, an indication of non-trivial loss on the window somewhere without having to pop the panel. The new version with receive cap will show total receive bw and current value of cap set by the reflector adapting to loss/delay. We could also show a receiver how much the reflector has to throw away to accommodate their path, but the deterioration of the picture(s) will probably show that. -Dick -Dick From list-mgr@ISI.EDU Sun Jun 11 19:04:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 08:07:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 08:04:46 -0700 Received: from eunet.EU.net (ns2.EU.net) by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 08:04:36 -0700 Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id RAA16283; Sun, 11 Jun 1995 17:04:31 +0200 Received: by jotun.EU.net id AA21674 (5.67a/IDA-1.5); Sun, 11 Jun 1995 17:04:30 +0200 Message-Id: <199506111504.AA21674@jotun.EU.net> From: Per Gregers Bilse Date: Sun, 11 Jun 1995 17:04:29 +0200 In-Reply-To: <9506082136.AA29657@mailserv-C.ftp.com> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: chip@ftp.com Subject: Re: EUnet GB policy on Cu-SeeMe and similar applications Cc: mbone On Jun 8, 17:36, Chip Sparling wrote: > PS I'd be more worried about the game developers, they're used to > running over NetBIOS or SPX/IPX on a LAN using lots of broadcasts, > they're coming too. Yep; early versions of networked 'Doom' even wrecked LANs. But BTW, I have to include this snippet from the FAQ for Internet Voice Chat (yet another voice-over-Internet application): I use FTP Software's PC/TCP version 3.0, and I'm getting "Operation would block" errors when I try to send voice data. What can I do a) You need to obtain a special kernel patch from FTP Software. Send email to support@ftp.com requesting the PC/TCP 3.0 kernel with "slow start" disabled. This reads like the 'host requirements' in reverse; can you shed some light on it? I don't see any reason to disable slow start, except maybe to try to make broken applications work (but that hardly qualifies). (I don't see this as a big problem, BTW, the packet burst will never leave the customer side of the network connection; but, in turn, this fact makes the 'fix' even less meaningful.) -- === ___ === Per G. Bilse, Mgr Network Operations Ctr === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Sun Jun 11 20:34:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 09:35:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 09:34:50 -0700 Received: from eunet.EU.net by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 09:34:18 -0700 Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id SAA19361; Sun, 11 Jun 1995 18:34:17 +0200 Received: by jotun.EU.net id AA21853 (5.67a/IDA-1.5); Sun, 11 Jun 1995 18:34:16 +0200 Message-Id: <199506111634.AA21853@jotun.EU.net> From: Per Gregers Bilse Date: Sun, 11 Jun 1995 18:34:16 +0200 In-Reply-To: Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: "Dick Cogger" (Richard Cogger) Subject: Re: EUnet GB policy on Cu-SeeMe ... Cc: mbone On Jun 11, 9:09, "Dick Cogger"Richard Cogger wrote: > >receivers about what's happening. Why can't that feedback be displayed in > >a graphical format, either in its own window, or on the existing control > >panel. For example shades of gray, or a light which goes from green to > >red, depending on how long the lags are. > > Actually, you *can* monitor congestion fairly well. You can readily see > when the send cap runs down, which would be an indication of aggregate loss > greater than 5% currently, it is displayed under your local window. Also, I'm still not happy with 5% loss being considered optimum, but I think you know that. But the facts that users actually can monitor what's going on, and we still have an unpleasant problem, clearly suggests that rate adaption and congestion control should not be in the users hands. They will happily (whether through ignorance or carelesness doesn't matter) ignore it. You need to make it impossible for users to request more data than their connection can handle and this control needs to be in the application itself. If somebody actually goes and hacks the source once you release the source code, then they are at least not innocent any longer and we will then be able to deal much more meaningfully with the problem (it will be close to a genuine denial-of-service attack, not an innocent user knowing nothing about what he/she is doing). (I nearly called it a 'bona fide denial-of-service attack' :-) -- === ___ === Per G. Bilse, Mgr Network Operations Ctr === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Sun Jun 11 04:03:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 11:04:27 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 11:03:37 -0700 Received: from hwb.extern.ucsd.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 11:03:33 -0700 Received: by hwb.extern.ucsd.edu id LAA06425; Sun, 11 Jun 1995 11:03:31 -0700 From: hwb@nlanr.net (Hans-Werner Braun) Message-Id: <199506111803.LAA06425@hwb.extern.ucsd.edu> Subject: wanna try audio or video stuff? To: mbone Date: Sun, 11 Jun 95 11:03:31 PDT I am only saw the bits and pieces people forwarded me of this discussion, as I do not regularly cunsult this mailing list. I have to say, though, that most of what I saw appears a little silly to me. The problem is not any specific application (be is cuseeme, nv, vat, maven, or whatever) or network level stuff (like the MBONE), the problem is a lack of understanding what the IMPLEMENTED business and and service and architectural model of the Internet is. Hey, I am not claiming I have the answers, but may be I can present some semi-random thoughts. Viewed from a fairly high level, users of the Internet (not us networking bigots) have no clue (or care) what they are doing *to* the network. Certainly not end-users. Even institutional users may not, e.g., if I buy a T1 from you and pay for the full pipe, I would claim at a first order of approximation that it is none of your business what I do with my fully paid pipe. (Sorry for being a bit provocative, but I am trying to get to some specific points). Now, based on my understanding as a network implementer and network researcher, the *implementened* architecture of the network relies on heavy aggregation. We have done some flow research for a number of years (check http://nlanr.net for some details), and if we measure the simultaneous flows on some network, we can get some idea of the aggregation of traffic. In a test on FIX-West yesterday I used address/port identifiers with a 64 second inactivity timeout to see some flow distribution. It is clear that the traffic was largely ambient, with 40,000 simultaneous flows (on a Saturday, no less!), and a remaining churn of about 500 flows per second (when it cut at 40,000 flows, it was still in a steep increase, so a longer timeout would decrease the churn still, and increase the number of aggregated flows). Well, look at the packet-per-flow percentiles: Min 1.000 05p 1.000 10p 1.000 15p 1.000 20p 1.000 25p 1.000 30p 2.000 35p 2.000 40p 3.000 45p 3.000 50p 4.000 55p 5.000 60p 6.000 65p 7.000 70p 9.000 75p 10.000 80p 13.000 85p 17.000 90p 25.000 95p 58.000 Max 72366.000 bytes per flow: Min 0.000 05p 44.000 10p 59.000 15p 66.000 20p 76.000 25p 109.000 30p 134.000 35p 168.000 40p 222.000 45p 280.000 50p 369.000 55p 447.000 60p 532.000 65p 653.000 70p 842.000 75p 1120.000 80p 1624.000 85p 2632.000 90p 4804.000 95p 13235.203 Max 19990801.000 and duration per flow: Min 0.000 05p 0.000 10p 0.000 15p 0.000 20p 0.000 25p 0.000 30p 0.001 35p 0.003 40p 0.390 45p 0.850 50p 1.399 55p 2.193 60p 3.185 65p 4.293 70p 6.372 75p 9.957 80p 16.955 85p 32.384 90p 62.323 95p 200.552 Max 606.944 for the 246406 flows in an about 10 minute trace quickie. Hmm, at the 90th percentile the transactions consisted of no more then 25 packets (followed by at least 64 seconds of inactivity), and less than 5k bytes. Half of the flows only had 4 packets or less, and less than 400 bytes and did not last more than 1.4 seconds. This is not inconsistent with measurements we did over the years, using varieties of timeouts, measurement granularities, and environments. What we see in Internet transit networks is often ambient traffic, relying on heavy aggregation of essentially microscopic flows (this FIX trace, though, had about four times as many flows as I had seen before in any environment; though I had not checked in a while). I will attach a message I sent to people working with me on the measurements. Please note specifically that 86% of the byte and 92% of the packet traffic was TCP, with 131646 flows causing 86% of all packets. But (!) Port 7648 (CU-SeeMe), contributed >1% of the traffic (20.3 megabytes in the 10 minutes) with only 16 flows, out of a total of 246,406 flows. So, the problem really is that the deployed Internet is optimized for ambient traffic consisting of small-sized heavily-aggregated flows, and perhaps hundreds of new ones per second. Now, letting things loose on the networking substrate that has a high bandwidth*duration product defeats your ability to aggregate, and I think that is what people really tried to express in some form or another. However, while CU-SeeMe may be a convenient victim to pick, the same is true for any number of protocols. Ambientizing 40,000 SNA or CNLP or whatever flows, and then having a few jumbo-flows in between would result in the same thing. So do all the point-to-point a/v flows possible with nv, vat, maven, and so. Some of which do not even need a CU-SeeMe reflector (which I think can be implemented in a hierarchical fashion). None of this is good or bad, of course, it just *is*. The Internet is growing into new service definitions over the years, and people just let it happen, with no real service model. Many of the schemes I am seeing that are being proposed do not appear to scale to in the future many millions of users with thousands of high-end jumbo-flow applications, in 40,000+ simultaneous-flows environments, and for a global scale, where someone suddenly decides to talk nv/vat or so from the US with, say, parents in Russia. And why not? They have nv/vat capable machines, it works to people in other US cities, and the Internet is free to use for end-users and flat priced for full bandwidth by an instituation to its service provider. So, why should the user care (who probably does not know a thing about networking anyway, besides knowing how to type mail and mosaic and nv and vat. If I pay flat, I make the assumption that I can run my link flat out and that it is only MY problem what I do on MY paid for connection. This problem is not going away. Comdemning CU-SeeMe may be the tactical respone and alleviate the problem for the time being. It will not resolve the issue. What is your overall policy? Non-interference with other traffic? Any traffic interferes with other traffic, only a matter of degree, what is your threshold? Say you have a policy of the bandwidth*duration product per flow not being allowed to exceed 3. Then you can measure things against that, but you better communicate that as your service model to your users in advance. Of course, they will say "so what," and use a spread spectrum equivalent, and you are where you started. How long do you think it will take for someone to create a spread spectrum version of CU-SeeMe, switching ports randomly all the time. The budget version of which we see already on MUDs and other apllications, where people just pick random ports, in part to hide that their network use may be recreational and entertainment and not R&E (not good or bad either, just look at the distribution of entertainment books versus science books in a book store for calibration). Personally (spare me the eggs and tomatoes) I believe this is not going to be resolved until there is a defined revenue stream for service providers, based on user requirements, that allows them to upgrade their real estate on demand. And I think the answer to that is accounting. Or at least finding ways to make people accountable for their actions (whether it is being translated to policy, quotas, billing, or whatever). The attitude of "uh, accounting is bad, as it means that I have to pay a nickel for each message I send and receive" is just getting more and more silly (and not only because accounting may not have to translate into billing individual network transactions). Anyways, semi-random thoughts, that's all. Hans-Werner ------------------------------------------------------------------------ Sat Jun 10 21:30:22 1995 Today (Saturday) I ran a 10 minute trace on FIX-West for about ten minutes: %[31]/Data/Traces 13:07: date; tcpdump -w na.trace Sat Jun 10 13:08:09 PDT 1995 tcpdump: Using kernel BPF filter Link header length set to 24 Binary file type: 1 tcpdump: listening on fta0 6964060 packets received by filter 22804 packets dropped by kernel %[32]/Data/Traces 13:18: The loss rate was about 0.32 percent. The number of packets were comparable to what a "netstat -I fta0 1 reported, i.e., about 11,000 packets per second. A similar run yesterday yielded 17,000 to 18,000 packets per second, typically, resulting in alot of packet losses. Looking at the second by second data, the pps percentiles were: Min 9861.000 05p 10753.450 10p 10886.600 15p 10970.200 20p 11065.900 25p 11125.250 30p 11181.400 35p 11254.000 40p 11299.600 45p 11366.000 50p 11429.000 55p 11473.350 60p 11551.100 65p 11612.200 70p 11684.000 75p 11753.500 80p 11841.200 85p 11955.900 90p 12075.800 95p 12469.200 Max 13709.000 the bits per second: Min 19054168.000 05p 20266497.602 10p 20657016.001 15p 20895979.228 20p 21096662.415 25p 21290400.000 30p 21463638.578 35p 21660433.978 40p 21804160.841 45p 21922029.961 50p 22055928.000 55p 22215257.224 60p 22392031.244 65p 22557468.375 70p 22744095.880 75p 22990650.000 80p 23176163.205 85p 23334366.430 90p 23597110.210 95p 24074671.373 Max 25480632.000 with average packet sizes: Min 209.000 05p 227.850 10p 231.000 15p 233.000 20p 234.000 25p 236.000 30p 237.000 35p 238.000 40p 239.000 45p 240.000 50p 241.000 55p 242.000 60p 243.000 65p 244.000 70p 245.000 75p 246.000 80p 247.000 85p 248.000 90p 250.000 95p 253.000 Max 268.000 in bytes. So, the FDDI ring was hovering at about 22Mbps, with a great degree of consistency. The average packet sizes have grown in this example, compared to a few years back (180-200 was common). The next thing I did was turning the trace flow traces, using src_addr/ dst_addr/ip_prot/src_port/dst_port as flow identifiers, and applying a 64 second timeout to them. Note that bidirectional flows were counted separately. Graphing the number of flows in this run cut at about 40,000 flows with still a significant churn remaining. The percentiles of "known flows," measured on a second by second basis was: Min 3175.000 05p 22768.800 10p 38418.900 15p 38525.000 20p 38578.700 25p 38621.000 30p 38683.600 35p 38748.600 40p 38836.900 45p 39077.200 50p 39412.000 55p 39539.200 60p 39619.200 65p 39714.400 70p 39908.600 75p 40407.000 80p 40529.600 85p 40764.200 90p 41061.701 95p 41939.600 Max 42689.000 (3175 was in the first second, when the flows started to build up). Added/new flows per second: Min 292.000 05p 322.800 10p 333.000 15p 340.000 20p 349.000 25p 355.000 30p 360.000 35p 367.000 40p 372.000 45p 376.000 50p 381.000 55p 387.000 60p 393.000 65p 398.000 70p 405.000 75p 415.000 80p 429.000 85p 446.600 90p 491.600 95p 549.000 Max 3175.000 (3175 in the first second), number of deleted flows per second: Min 0.000 05p 0.000 10p 0.000 15p 328.000 20p 339.000 25p 344.000 30p 351.000 35p 356.000 40p 360.900 45p 367.000 50p 371.500 55p 377.000 60p 382.000 65p 389.000 70p 395.700 75p 399.000 80p 404.000 85p 412.600 90p 425.900 95p 445.200 Max 553.000 (the zeroes in the first 64 seconds). A longer timeout would likely result in less churn, but a larger set of "flow state." Haven't tried other timeouts yet. Anyway, next I ran it through a program that collapses timed out flows. The somewhat annotated (with @@) result: SDSC-ANR:MP2PPCOLL on file 'na.trace.pq64' from 0 to 9999999 seconds Total triplets: 246406 @@ number of flows Total packets: 6964060 Total bytes: 1678281205 Total duration: 8560297 Itemized by protocols: Prot Packets Fract Bytes Fract Duration Count ==== ======== ======= ========== ======= ======== ======= 0 713 0.00010 2340983 0.00139 11578 46 1 105088 0.01509 7539472 0.00449 538028 10764 2 21423 0.00308 8269886 0.00493 24089 191 3 3 0.00000 6111 0.00000 0 3 4 145814 0.02094 14673644 0.00874 15075 103 @@ 2% of your traffic was encapsulated IP (likely MBONE). "Count" is the number of flows that had been observed. *Only* 103 flows caused 2% of the packet traffic. 6 5976323 0.85817 1543611908 0.91976 5385162 131646 @@ 86% of the byte and 92% of the packet traffic was TCP. 131646 flows caused 86% of all packets. 7 1 0.00000 0 0.00000 0 1 8 124 0.00002 4488 0.00000 1964 57 17 712846 0.10236 101284211 0.06035 2572709 103526 @@ 10%/6% was UDP traffic. Note that the number of flows is close to the TCP count, though. Likely due to many DNS requests. 37 6 0.00000 240 0.00000 0 6 64 33 0.00000 67584 0.00004 1204 10 72 4 0.00000 6144 0.00000 0 1 83 302 0.00004 56658 0.00003 3443 7 89 1106 0.00016 361564 0.00022 5975 14 93 257 0.00004 27491 0.00002 1050 27 94 1 0.00000 101 0.00000 0 1 140 5 0.00000 7680 0.00000 0 1 232 11 0.00000 23040 0.00001 12 2 Itemized by TCP/UDP ports: Total number of unique port references: 50463 (for TCP) 7844 (for UDP) Port references after <1000 collapse: 9528 (for TCP) 5587 (for UDP) 347 ports used in below 1000 range Find multiple (3) port references for port pairs: Port 3008 is found paired 3518 times. Port 6667 is found paired 1546 times. Port 8001 is found paired 460 times. Port 38616 is found paired 428 times. Port 4000 is found paired 281 times. Port 8080 is found paired 226 times. Port 8000 is found paired 142 times. Port 1025 is found paired 131 times. Port 3464 is found paired 130 times. Port 8002 is found paired 113 times. Port 6666 is found paired 112 times. Port 1280 is found paired 110 times. Port 2222 is found paired 107 times. Port 5563 is found paired 105 times. Port 6665 is found paired 105 times. Port 3000 is found paired 104 times. Port 2003 is found paired 103 times. Port 2608 is found paired 102 times. Port 6551 is found paired 100 times. Port 5190 is found paired 91 times. Port 6000 is found paired 89 times. Port 9999 is found paired 88 times. Port 4320 is found paired 87 times. Port 3916 is found paired 84 times. Port 5555 is found paired 79 times. ===== ====== For 1871 ports and 21131 references @@ prior table debug info for how it tried to collapse often-seen ports. IRC seems popular (6667). Not sure what 3008 is. Collapsing with the added information Detailed information sorted by traffic volume (bytes): Prt SPort DPort kPkts P-Fract kByt B-Fract Size Duratn D-Fract Count C-Fract 6 80 0 1087 0.156 497146 0.296 457 1773053 0.207 39589 0.161 6 20 0 834 0.120 457605 0.273 548 181448 0.021 3870 0.016 6 0 119 423 0.061 173069 0.103 408 119040 0.014 642 0.003 17 53 53 418 0.060 50283 0.030 120 1514857 0.177 83489 0.339 6 0 80 809 0.116 42280 0.025 52 594707 0.069 36995 0.150 6 0 20 518 0.074 35966 0.021 69 139864 0.016 3966 0.016 6 0 25 115 0.017 28638 0.017 247 211725 0.025 7768 0.032 6 0 388 46 0.007 23173 0.014 493 5863 0.001 52 0.000 6 23 0 188 0.027 22277 0.013 118 180657 0.021 1069 0.004 17 7648 7648 75 0.011 20324 0.012 270 6274 0.001 16 0.000 6 119 0 301 0.043 16587 0.010 55 133922 0.016 659 0.003 6 70 0 29 0.004 14264 0.008 479 53934 0.006 1180 0.005 6 0 23 226 0.033 9394 0.006 41 188853 0.022 1115 0.005 6 25 0 99 0.014 5850 0.003 58 137621 0.016 6462 0.026 6 513 0 20 0.003 5038 0.003 241 12282 0.001 171 0.001 6 6667 0 26 0.004 5022 0.003 190 51007 0.006 391 0.002 17 513 513 51 0.007 4662 0.003 89 2291 0.000 284 0.001 6 77 0 3 0.000 3586 0.002 1063 3731 0.000 15 0.000 6 21 0 37 0.005 3468 0.002 93 88511 0.010 2243 0.009 6 1450 1050 4 0.001 2551 0.002 551 520 0.000 1 0.000 6 1451 6000 4 0.001 2473 0.001 569 100 0.000 1 0.000 6 0 21 46 0.007 2194 0.001 47 91136 0.011 2198 0.009 17 0 712 1 0.000 2109 0.001 1152 605 0.000 1 0.000 6 3708 0 4 0.001 2057 0.001 439 224 0.000 1 0.000 6 79 0 7 0.001 2038 0.001 256 5836 0.001 757 0.003 @@ Ok. So >30% of your byte traffic was Web traffic, caused by about 27% of your flows. Next biggest were FTP, NNTP, and DNS. Not sure what UDP port 7648 is (CU-SeeMe???), but >1% of your traffic (20.3 megabytes in the 10 minutes) was caused by only 16 flows (remember, the total was 246,406 flows)!!! Ahem. 5436 remaining port pair references were found Sorted by reference count: Prt SPort DPort kPkts P-Fract kByt B-Fract Size Duratn D-Fract Count C-Fract 17 53 53 418 0.060 50283 0.030 120 1514857 0.177 83489 0.339 6 80 0 1087 0.156 497146 0.296 457 1773053 0.207 39589 0.161 6 0 80 809 0.116 42280 0.025 52 594707 0.069 36995 0.150 6 0 25 115 0.017 28638 0.017 247 211725 0.025 7768 0.032 6 25 0 99 0.014 5850 0.003 58 137621 0.016 6462 0.026 17 123 123 19 0.003 1490 0.001 76 652742 0.076 4625 0.019 6 0 20 518 0.074 35966 0.021 69 139864 0.016 3966 0.016 6 20 0 834 0.120 457605 0.273 548 181448 0.021 3870 0.016 17 0 3008 3 0.000 378 0.000 108 0 0.000 3479 0.014 6 0 113 6 0.001 287 0.000 42 7734 0.001 3430 0.014 17 7001 7003 9 0.001 660 0.000 66 10678 0.001 3427 0.014 6 113 0 5 0.001 248 0.000 43 1412 0.000 2984 0.012 6 21 0 37 0.005 3468 0.002 93 88511 0.010 2243 0.009 6 0 21 46 0.007 2194 0.001 47 91136 0.011 2198 0.009 6 0 70 27 0.004 1171 0.001 42 19723 0.002 1484 0.006 6 70 0 29 0.004 14264 0.008 479 53934 0.006 1180 0.005 6 0 23 226 0.033 9394 0.006 41 188853 0.022 1115 0.005 17 0 53 1 0.000 111 0.000 66 4210 0.000 1110 0.005 17 0 161 13 0.002 1439 0.001 104 128000 0.015 1076 0.004 6 23 0 188 0.027 22277 0.013 118 180657 0.021 1069 0.004 17 53 0 1 0.000 297 0.000 162 2647 0.000 879 0.004 17 161 0 11 0.002 1208 0.001 105 111200 0.013 862 0.003 6 79 0 7 0.001 2038 0.001 256 5836 0.001 757 0.003 6 0 79 6 0.001 257 0.000 40 6381 0.001 757 0.003 6 119 0 301 0.043 16587 0.010 55 133922 0.016 659 0.003 @@ Now, as expected, for flows DNS is the lucky winner, responsible for 34% of the flows. Likely largely single packet lookups. Next one is Web traffic, with 16% of the flows. Sorted by flow frequency and displaying ranks Prt SPort DPort flow pkts byts secs | ave-pkt ave-byt ave-size 17 53 53 1 6 4 2 | 5 602 120 6 80 0 2 1 1 1 | 27 12557 457 6 0 80 3 3 5 4 | 21 1142 52 6 0 25 4 10 7 5 | 14 3686 247 6 25 0 5 11 14 10 | 15 905 59 17 123 123 6 24 43 3 | 4 322 76 6 0 20 7 4 6 9 | 130 9068 69 6 20 0 8 2 2 7 | 215 118244 548 17 0 3008 9 64 161 7930 | 1 108 109 6 0 113 10 36 185 32 | 1 83 43 17 7001 7003 11 30 120 29 | 2 192 67 6 113 0 12 42 203 122 | 1 83 44 6 21 0 13 16 19 16 | 16 1546 93 6 0 21 14 15 22 15 | 21 998 47 6 0 70 15 19 64 22 | 18 789 43 6 70 0 16 18 12 17 | 25 12088 479 6 0 23 17 8 13 6 | 203 8425 42 17 0 53 18 179 322 48 | 1 100 67 17 0 161 19 27 44 12 | 12 1337 104 6 23 0 20 9 9 8 | 176 20839 118 17 53 0 21 159 178 62 | 2 339 163 17 161 0 22 28 62 14 | 13 1402 105 6 79 0 23 31 25 42 | 10 2692 256 6 0 79 24 39 197 38 | 8 339 41 6 119 0 25 7 11 11 | 457 25170 55 @@ Well, this table is sorted by number of flows of a specific type. Looks like the Web popularity may be one of the reasons that the average packet size grew. From list-mgr@ISI.EDU Sun Jun 11 14:08:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 21:08:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 21:08:02 -0700 Received: from hwb.extern.ucsd.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 11 Jun 1995 21:08:00 -0700 Received: by hwb.extern.ucsd.edu id VAA07383; Sun, 11 Jun 1995 21:08:02 -0700 From: hwb@nlanr.net (Hans-Werner Braun) Message-Id: <199506120408.VAA07383@hwb.extern.ucsd.edu> Subject: a/v To: mbone Date: Sun, 11 Jun 95 21:08:02 PDT From: info@ivory.educom.edu (Edupage) ... VOCALTEC UPGRADES INTERNET PHONE SOFTWARE New Jersey-based VocalTec Inc. is introducing a new version of its $99 Internet Phone software that enables full-duplex phone conversations over the Internet. The original version was half-duplex, meaning that both parties couldn't speak at the same time. In addition, the company has agreed that NetCom Online Communications Services Inc. will include Internet Phone with its Netcruiser Internet user interface software. One obstacle still to be overcome is the fact that full-duplex programs don't work with the majority of sound cards currently installed. "Very few Standard sound cards can take advantage of full-duplex yet. This is still more of a hobbyist thing than a standard long-distance thing," says an industry analyst. (Investor's Business Daily 6/2/95 A15) From list-mgr@ISI.EDU Mon Jun 12 04:23:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 05:24:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 05:23:32 -0700 Received: from aspen.uml.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 05:23:27 -0700 Received: by woods.uml.edu (MX V4.1 VAX) id 13275; Mon, 12 Jun 1995 08:23:09 EDT Date: Mon, 12 Jun 1995 08:23:08 EDT From: THACH@woods.uml.edu To: MBONE X-Vmsmail-To: MBONE@ISI.EDU Message-Id: <00991C26.36736EC0.13275@woods.uml.edu> Subject: please unsubscribe Please unsubscribe. From list-mgr@ISI.EDU Mon Jun 12 04:10:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 11:18:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 11:17:15 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 11:17:14 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14554(4)>; Mon, 12 Jun 1995 11:10:48 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Mon, 12 Jun 1995 11:10:32 -0700 X-Mailer: exmh version 1.6 4/21/95 To: Jon Crowcroft Cc: mbone Subject: Re: Upgrading and the MBONE In-Reply-To: Your message of "Sat, 10 Jun 95 07:58:06 PDT." <6775.802796286@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jun 1995 11:10:19 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun12.111032pdt.49859@crevenia.parc.xerox.com> In message <6775.802796286@cs.ucl.ac.uk> Jon Crowcroft wrote: >if the "market penetration" of later versions of mrouted are anything >to go by, it will be a decade... Thanks, Jon, for the wonderful segue! Based upon the MBONE information that UCL's mwatch keeps, nearly 50% of the MBONE is running version 2.x: 413 (29%) 2.2 288 (20%) 3.3 215 (15%) 2.0 135 ( 9%) 3.5 123 ( 8%) 3.4 73 ( 5%) 3.2 50 ( 3%) 1.0 42 ( 3%) 10.2 35 ( 2%) 3.1 19 ( 1%) 10.3 None of these <3.5 routers will survive the transition to heirarchical routing. This, in itself, will be sufficient motivation to upgrade when the time comes. However, I am finding it more and more difficult to debug MBONE problems when they arise without a functioning traceroute. I have built an mrouted 2.3 which just adds multicast traceroute to 2.2 . However, I don't know if I should release it, as I have a feeling that having 2.3 available will prevent people from upgrading to 3.5 . I'd like to ask the people who are still running 2.x on SunOS machines: - What would it take to get you to upgrade to 3.5? - If it would help a lot, I could build a 2.2->3.5 upgrade tree, just like there is a 3.3->3.5 upgrade tree, which means that the upgrade will be one pass instead of two. (Right now, you have to remove the 2.2 patches and then apply the 3.5 patches, which is easy with Steve Casner's updated mcast_install script) - Would you be more willing to upgrade to 2.3, since it only requires a new mrouted? Does anyone else have any suggestions about pushing people to upgrade? I know the UK had wonderful success making sure that everyone ran pruning; anyone want to share some pointers? Any providers want to get in on the discussion? Bill From list-mgr@ISI.EDU Mon Jun 12 05:17:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 12:18:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 12:18:12 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 12:18:11 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA03187; Mon, 12 Jun 95 12:17:47 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9506121917.AA03187@taurus.cs.nps.navy.mil> Subject: Re: Upgrading and the MBONE To: fenner@parc.xerox.com (Bill Fenner) Date: Mon, 12 Jun 1995 12:17:46 -0700 (PDT) Cc: mbone (Multicast Backbone mail list) In-Reply-To: <95Jun12.111032pdt.49859@crevenia.parc.xerox.com> from "Bill Fenner" at Jun 12, 95 11:10:19 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 904 I would be happy to send a message to operators of old versions encouraging them to upgrade. Many other folks would likely be willing too. It is important to resolve this upgrade issue, both for current and future MBone work & research. In order to avoid creating a spam attack, maybe we might start a petition and send it to them. Usually something like this is mainly solved by getting the issue in front of the right person. Attacks would be counterproductive since an older mroute is better than none. I know this sounds lame but other things haven't worked. Since it appears to be a people problem, perhaps we might attempt people solutions. all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv.html From list-mgr@ISI.EDU Mon Jun 12 11:16:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 12:18:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 12:17:46 -0700 Received: from mailer.jhuapl.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 12:17:45 -0700 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA11696; Mon, 12 Jun 1995 15:17:42 -0400 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA10960; Mon, 12 Jun 1995 15:16:57 -0400 Date: Mon, 12 Jun 1995 15:16:56 -0400 (EDT) From: Jim Bogard BIX Subject: mrouted 3.5 odd behavior To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 585 My mrouted 3.5 (Sparc 5, SunOS 4.1.4) which is normally rock solid refuses to run in a tunnel only mode. Does anyone else have this problem? The warning "phyint disabled-running tunnels only" appears in the log, but then the daemon goes away. If I remove the phyint disable, it works ok, but we're doing some config changes and I really don't want it spewing multicast on its subnet... Ideas? Help! Thanks. J-. ---- Jim Bogard JHU/APL BIX Group "This is my banjo. There are many Backbone Network Engineer like it, but this one is mine." From list-mgr@ISI.EDU Mon Jun 12 09:10:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 12:11:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 12:10:44 -0700 Received: from everest.cclabs.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 12:10:43 -0700 Received: from indy47.gclab.missouri.edu (indy47.gclab.missouri.edu [128.206.48.211]) by everest.cclabs.missouri.edu (8.6.12/8.6.12) with SMTP id OAA12729; Mon, 12 Jun 1995 14:10:32 -0500 Date: Mon, 12 Jun 1995 14:10:30 -0500 (CDT) From: "Paul 'Shag' Walmsley" X-Sender: ccshag@indy47.gclab.missouri.edu To: Bill Fenner Cc: nowicki@tree.engr.sgi.com, mbone Subject: Re: Upgrading and the MBONE In-Reply-To: <95Jun12.111032pdt.49859@crevenia.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Jun 1995, Bill Fenner wrote: > I'd like to ask the people who are still running 2.x on SunOS machines: There are probably quite a few people still trunning mrouted 2.x on IRIX systems. We just upgraded our campus mrouted to SGI's beta 3.4 distribution about a week ago - to the best of my knowledge, it has not been publicly announced, although it seems to be publicly available. We've been running the IRIX beta 3.4 mrouted on several of our leaf multicast routers and it's worked very well. To run mrouted 3.4, the host must also be running IRIX 5.3, which will keep the IRIX 4.0.5 and 6.x crowd at mrouted 2.2 ... - Paul "Shag" Walmsley "Praise and blame alike mean nothing." -- Virginia Woolf From list-mgr@ISI.EDU Mon Jun 12 11:51:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 12:51:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 12:51:29 -0700 Received: from davinci.gmu.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 12:51:28 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id PAA03266; Mon, 12 Jun 1995 15:51:35 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199506121951.PAA03266@davinci.gmu.edu> Subject: SD To: mbone Date: Mon, 12 Jun 1995 15:51:35 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 343 Is there a way to feed the options for SD on the command line so that an interactive session with it (in order to create a new entry) is not required? Michael -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Mon Jun 12 06:17:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 13:18:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 13:17:56 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 13:17:56 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14404(6)>; Mon, 12 Jun 1995 13:17:47 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Mon, 12 Jun 1995 13:17:35 -0700 X-Mailer: exmh version 1.6 4/21/95 To: Jim Bogard BIX Cc: mbone Subject: Re: mrouted 3.5 odd behavior In-Reply-To: Your message of "Mon, 12 Jun 95 12:16:56 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jun 1995 13:17:21 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun12.131735pdt.49859@crevenia.parc.xerox.com> In message you write: >My mrouted 3.5 (Sparc 5, SunOS 4.1.4) which is normally rock solid >refuses to run in a tunnel only mode. This is a known bug, and will be fixed in 3.6 . I can give you a prerelease of 3.6 if you want (for some reason, my todo list is growing even though I'm constantly removing items from it =) Bill From list-mgr@ISI.EDU Mon Jun 12 06:15:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 13:18:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 13:15:34 -0700 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Jun 1995 13:15:31 -0700 Posted-Date: Mon 12 Jun 95 13:15:07 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Mon, 12 Jun 95 13:15:17 PDT Date: Mon 12 Jun 95 13:15:07 PDT From: Stephen Casner Subject: Re: Upgrading and the MBONE To: MBONE Cc: fenner@parc.xerox.com Message-Id: <802988107.0.CASNER@XFR.ISI.EDU> In-Reply-To: <95Jun12.111032pdt.49859@crevenia.parc.xerox.com> Mail-System-Version: Some of the delay in upgrading is due to people being too busy, but that's not the only reason and may not be the biggest one. My guess is that many of the machines running 2.x mrouted are unable to upgrade because they are running vendor-supplied kernel multicast code, for example Solaris. (In that particular case, I happen to know that the release of 3.4 upgrades is imminent.) However, there is another problem that our discussion on this list won't help: some of the mrouted node maintainers are not on this list or don't read it. For example, one of the peers of my router is running 2.0, but when I contacted the person who maintains it, he said he was unaware of the need to upgrade and would get to it ASAP. So, my suggestion to you all who run mrouted machines is to please send a note to the maintainers of your peer mrouteds which have not been upgraded asking them to do so. I found this technique to be effective in the early days of the mbone when I was able to figure out a contact name for most of the mrouted nodes and send them messages myself, but this is no longer practical. However, a distributed implementation of this technique would work, especially since you are more likely to know a contact name for your peer nodes. If they are downsteam, then you also have a good reason to ask them to upgrade, so that pruning will work on your node. -- Steve ------- From list-mgr@ISI.EDU Sat Jun 10 12:00:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 13:02:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 13:02:26 -0700 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 13:02:25 -0700 Received: from [132.236.199.54] (PHANTOM.CIT.CORNELL.EDU [132.236.199.54]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id QAA16964; Sat, 10 Jun 1995 16:02:12 -0400 X-Sender: rc19@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 10 Jun 1995 16:00:53 -0400 To: Jon Crowcroft From: R.Cogger@cornell.edu (Richard Cogger) Subject: Re: EUnet GB policy on Cu-SeeMe ... Cc: mbone At 10:39 AM 6/10/95, Jon Crowcroft wrote: > >OK, we'll do it. (It will start at the Min, default value 10.) For > >two-party connections, it should be effective; but for connecting to a > >multiparty conference, senders will already have worked up to their levels, > >so it won't help much. Also, I'm not sure how quickly folks will pick up a > >new version with just that change. It is easy enough to do, though, so > >we'll get it out in a couple of days. > >Dick > >surely a reflector could treat each fanout spearately, and new >receivers joing to a reflector get a throttle up (slow start) same as >pomint to point? > > jon Jon, Yes of course. I was replying to the request for a quick one-line change. The work on the reflector to have it treat each receiver individually is mostly done, at least for its first version, and we can put slow start into that as well, but the whole package will be a few more weeks to finish and get out. -Dick From list-mgr@ISI.EDU Sat Jun 10 12:40:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 13:42:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 13:42:24 -0700 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 10 Jun 1995 13:42:23 -0700 Received: from [132.236.199.54] (PHANTOM.CIT.CORNELL.EDU [132.236.199.54]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id QAA18505; Sat, 10 Jun 1995 16:42:18 -0400 X-Sender: rc19@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 10 Jun 1995 16:40:59 -0400 To: brutzman@cs.nps.navy.mil (Don Brutzman) From: R.Cogger@cornell.edu (Richard Cogger) Subject: Re: EUnet GB policy on Cu-SeeMe ... Cc: mbone >I was disappointed to not see anything in your message about >multicast. It leaves the impression that you will continue to make >CU-SeeME a dangerous tool that consumes excessive bandwidth with each >successive user, requiring labor-intensive reflectors that are >unlikely to be well matched to the bandwith capacity of actual links. > There are a lot of issues involved in going to multicast, but when we can, we will. Apple's mcast code (part of their OpenTransport package) is supposed to be out soon (in a solid version), perform reasonably sometime after that, and be in most folks hands, perhaps by early '96. A more serious problem is the following: How soon do you estimate that a typical non-techie Internet user will be able to just use IP mcast, without having to consult with a network admin, etc. to get access to the mbone? What fraction of current Internet users would you estimate have access to the mbone? What fraction in a year? Of course, I agree that mcast is the way to go for anything approaching a "broadcast" of some event. Setting up cascades of reflectors is not a satisfactory approach. However, a 2-party conference clearly won't benefit from mcast (excuse me for stating the obvious) and it's not so obvious that a 3- or 4-party conference benefits that much. In fact, the ability of a reflector to operate with application-level knowledge of codings, receiver preferences, and such, customizing streams to each recipient is a significant advantage. Presently, I believe, if you join an mbone conference which has, say 6 senders, you will receive all 6 video streams, even if you only open windows for 2 of them, and you will receive each stream at the full bandwidth (minus dropped packets) the sender sends it. Of course, future developments will provide source-specific pruning, layered encodings, and so on. For conferences of modest size, we'll get there sooner with a reflector arcitecture. But please don't mark me down as being anti-multicast. Actually, I think the best results are ultimately going to come from a combination of topology-aware multicast routing with application-aware relay points, such as reflectors. >Making CU-SeeMe MBone-compatible will greatly reduce bandwidth >problems, will allow Macs to send/receive programs on the MBone, and will >avoid reflector difficulties. I am worried that CU-SeeMe will break >the frame relay cloud we have set up for schools in our two counties, >where average school access is 128 Kbps. > We would also have to implement the encodings, and at least a good part of the currently deployed Mac (and Windows) fleet lacks the oomph to handle it. I'm not sure which reflector difficulties you have in mind; but we would also forego reflector opportunities. But like I said, we are going to do it when and as it becomes feasable, but I expect we will keep on with the reflector too. Do you expect to be able to handle multi-party mbone conferencing on this frame-relay cloud? I don't think you can do very successful multiparty conferencing on a network of that capacity (unless maybe if you dedicate it for a single conference) with either carefully engineered mbone tunnels or with a carefully engineered reflector net. I can't guess which way you could have a least unsatisfactory result, but I doubt the difference will be large. -Dick From list-mgr@ISI.EDU Tue Jun 13 11:13:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 02:23:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 02:15:29 -0700 Received: from sun.mhs-relay.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 02:15:22 -0700 X400-Received: by mta sun.mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Tue, 13 Jun 1995 10:14:13 +0100 X400-Received: by mta ash.shu.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Tue, 13 Jun 1995 10:13:55 +0100 Date: Tue, 13 Jun 1995 10:13:55 +0100 X400-Originator: liaison@Sheffield-Hallam.ac.uk X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;ash.shu.ac.u:293443:950613091355] X400-Content-Type: P2-1988 (22) Content-Identifier: Re: Upgrading an From: Liaison Message-Id: <"ash.shu.ac.u:293442:950613091355*/S=liaison/O=Sheffield-Hallam/PRMD=UK.AC/ADMD= /C=GB/"@MHS> To: Stephen Casner Cc: fenner , MBONE In-Reply-To: <802988107.0.CASNER@XFR.ISI.EDU> References: <95Jun12.111032pdt.49859@crevenia.parc.xerox.com> Subject: Re: Upgrading and the MBONE Discarded-X400-Ipms-Extensions: iso (1) memberBody (2) gb (826) (0) (1004) (10) (1) (1) Hi, >Some of the delay in upgrading is due to people being too busy, but >that's not the only reason and may not be the biggest one. [... lots cut ...] >So, my suggestion to you all who run mrouted machines is to please >send a note to the maintainers of your peer mrouteds which have not >been upgraded asking them to do so. I found this technique to be >effective in the early days of the mbone when I was able to figure out >a contact name for most of the mrouted nodes and send them messages >myself, but this is no longer practical. However, a distributed [... more cut ...] Would it be practical / desireable to include some configuration directives in the mrouted.conf file which include the router maintainers name and EMail address? In this way it may be possible to write a tool which could probe all the mrouted's running and return the likely contact point .....? Just my .5c worth. Dave Haywood. liaison@shu.ac.uk From list-mgr@ISI.EDU Tue Jun 13 05:07:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 06:08:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 06:07:50 -0700 Received: from mailer.jhuapl.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 06:07:49 -0700 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA05247; Tue, 13 Jun 1995 09:07:47 -0400 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA29019; Tue, 13 Jun 1995 09:07:02 -0400 Date: Tue, 13 Jun 1995 09:07:02 -0400 (EDT) From: Jim Bogard BIX Subject: Re: EUnet GB policy on Cu-SeeMe ... To: Richard Cogger Cc: mbone In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 588 > Presently, I believe, if you > join an mbone conference which has, say 6 senders, you will receive all 6 > video streams, even if you only open windows for 2 of them, and you will > receive each stream at the full bandwidth (minus dropped packets) the > sender sends Minor nit - according to the dox, one only receives data for the windows one has open. They suggest you close "empty office" windows for this reason. J-. ---- Jim Bogard JHU/APL BIX Group "This is my banjo. There are many Backbone Network Engineer like it, but this one is mine." From list-mgr@ISI.EDU Tue Jun 13 07:32:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 08:38:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 08:38:11 -0700 Received: from mailer.jhuapl.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 08:37:29 -0700 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA12939; Tue, 13 Jun 1995 11:34:33 -0400 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA05853; Tue, 13 Jun 1995 11:32:38 -0400 Date: Tue, 13 Jun 1995 11:32:37 -0400 (EDT) From: Jim Bogard BIX Subject: Re: EUnet GB policy on Cu-SeeMe ... To: Richard Cogger Cc: mbone In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 883 Oops. I read too fast and transposed cusm and mbone. J-. On Tue, 13 Jun 1995, Richard Cogger wrote: > Which dox? Without source specific pruning, how does an mbone participant > get anything sent to a group without getting everything? -Dick > > >> Presently, I believe, if you > >> join an mbone conference which has, say 6 senders, you will receive all 6 > >> video streams, even if you only open windows for 2 of them, and you will > >> receive each stream at the full bandwidth (minus dropped packets) the > >> sender sends > > > >Minor nit - according to the dox, one only receives data for the windows > >one has open. They suggest you close "empty office" windows for this reason. > > > >J-. > >---- > >Jim Bogard JHU/APL BIX Group "This is my banjo. There are many > >Backbone Network Engineer like it, but this one is mine." > > > From list-mgr@ISI.EDU Tue Jun 13 05:05:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 12:05:18 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 12:05:16 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id MAA14579; Tue, 13 Jun 1995 12:06:00 -0700 Message-Id: <199506131906.MAA14579@rx7.ee.lbl.gov> To: dolors@alps.cc.gatech.edu Cc: mbone-na Subject: host alps.cc.gatech.edu sending 450kb/s to mbone Date: Tue, 13 Jun 95 12:05:59 PDT From: Van Jacobson Host alps.cc.gatech.edu (130.207.8.16) is sending 450kb/s of god-knows-what to 224.1.1.1/7001 at ttl 128. This is very antisocial. Could someone ask them to either reduce their ttl to <32 or reduce their bandwidth to <128kb/s. Thanks. - Van From list-mgr@ISI.EDU Tue Jun 13 05:51:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 12:50:46 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 12:50:44 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id MAA14614; Tue, 13 Jun 1995 12:51:30 -0700 Message-Id: <199506131951.MAA14614@rx7.ee.lbl.gov> To: mbone-na Subject: Georgia Tech now sending 600kb/s to mbone Date: Tue, 13 Jun 95 12:51:28 PDT From: Van Jacobson Host alps.cc.gatech.edu and appalachian.cc.gatech.edu are now sending a total of 600kb/s at ttl 128 to mbone address 224.1.1.1, udp ports 7001, 7002, 7003. They have going doing this for a couple of hours. Email to root & users logged on to this machine has had no effect. Is there someone at or near Georgia Tech that could ask them to stop? Thanks. - Van From list-mgr@ISI.EDU Tue Jun 13 12:35:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 13:35:46 -0700 Received: from burdell.cc.gatech.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 13:35:45 -0700 Received: from alps.cc.gatech.edu (kevin@alps.cc.gatech.edu [130.207.8.16]) by burdell.cc.gatech.edu (8.6.12/8.6.9) with ESMTP id QAA12289; Tue, 13 Jun 1995 16:35:37 -0400 Received: (from kevin@localhost) by alps.cc.gatech.edu (8.6.10/8.6.9) id QAA00548; Tue, 13 Jun 1995 16:35:35 -0400 Date: Tue, 13 Jun 1995 16:35:35 -0400 From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199506132035.QAA00548@alps.cc.gatech.edu> To: dolors@cc.gatech.edu, van@ee.lbl.gov Subject: Re: host alps.cc.gatech.edu sending 450kb/s to mbone Cc: mbone-na >>Host alps.cc.gatech.edu (130.207.8.16) is sending 450kb/s of >>god-knows-what to 224.1.1.1/7001 at ttl 128. This is very >>antisocial. Could someone ask them to either reduce their >>ttl to <32 or reduce their bandwidth to <128kb/s. Thanks. This problem has been corrected. Someone is our group is running some multicast application performance tests. They are working on reducing their TTL and bandwidth requirements. Now if everyone did pruning... -Kevin Almeroth From list-mgr@ISI.EDU Tue Jun 13 12:46:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 13:46:14 -0700 Received: from renaissance.Services.Peach.NET by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 13:46:13 -0700 Received: from [131.144.4.42] (Alan.OIT.PeachNet.EDU [131.144.4.42]) by renaissance.Services.Peach.NET (8.6.9/8.6.9) with SMTP id QAA16206; Tue, 13 Jun 1995 16:46:05 -0400 X-Sender: alan@mail.DTN.OIIT.PeachNet.EDU Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 Jun 1995 16:46:26 -0400 To: Van Jacobson , mbone-na From: Alan@PeachNet.EDU (Alan M. Brown) Subject: Re: Georgia Tech now sending 600kb/s to mbone Van - I'm "near" Georgia Tech (GIT). They are one of our Universities. I've contacted a sys admin there; he and I've been buddies for years. He's not real sure where the hosts are; but, he'll see what he can do. I hope this will yield results. Alan At 3:51 PM 6/13/95, Van Jacobson wrote: >Host alps.cc.gatech.edu and appalachian.cc.gatech.edu are now >sending a total of 600kb/s at ttl 128 to mbone address >224.1.1.1, udp ports 7001, 7002, 7003. They have going doing >this for a couple of hours. Email to root & users logged on to >this machine has had no effect. Is there someone at or near >Georgia Tech that could ask them to stop? Thanks. > > - Van ====================================================================== Alan M. Brown InterNet: Alan@PeachNet.EDU Director - Engineering Telephone: (404) 423-6860 PeachNet Facsimile: (404) 423-6868 From list-mgr@ISI.EDU Tue Jun 13 07:41:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 14:41:33 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 14:41:32 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14428(1)>; Tue, 13 Jun 1995 14:41:13 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Tue, 13 Jun 1995 14:41:03 -0700 X-Mailer: exmh version 1.6 4/21/95 To: kevin@cc.gatech.edu (Kevin C. Almeroth) Cc: dolors@cc.gatech.edu, van@ee.lbl.gov, mbone-na Subject: Re: host alps.cc.gatech.edu sending 450kb/s to mbone In-Reply-To: Your message of "Tue, 13 Jun 95 13:35:35 PDT." <199506132035.QAA00548@alps.cc.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jun 1995 14:41:00 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun13.144103pdt.49859@crevenia.parc.xerox.com> In message <199506132035.QAA00548@alps.cc.gatech.edu> you write: >Now if everyone did pruning... ...it would still be disruptive because of the periodic flooding. (Perhaps that's how to get people to upgrade to pruning mrouted's -- inject 1Mbps of traffic and say "well you wouldn't be getting it if you were running a more recent mrouted" =) Bill From list-mgr@ISI.EDU Tue Jun 13 07:47:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 14:51:42 -0700 Received: from isc.sjsu.edu (sparta.SJSU.EDU) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 14:51:39 -0700 Received: by isc.sjsu.edu (4.1/25-eef) id AA19399; Tue, 13 Jun 95 14:47:07 PDT Date: Tue, 13 Jun 95 14:47:07 PDT From: John Rudd Message-Id: <9506132147.AA19399@isc.sjsu.edu> To: Alan@peachnet.edu, mbone-na, van@ee.lbl.gov Subject: Re: Georgia Tech now sending 600kb/s to mbone Cc: help@cc.gatech.edu, peter@cc.gatech.edu the best way to get a response from *.cc.gatech.edu machines is to email help@cc.gatech.edu with the problem. (at least, that's the only direct way I know of to reach the sys admins there.. mailing direct to root doesn't usually do anything, since those are NFS/NIS workstations and such, not central servers) (Peter Wan (peter@cc.gatech.edu) is probably the more correct person to contact) (I'm an ex-student at the College of Computing at Ga Tech (cc.gatech.edu)) (I've cc'ed help@cc.gatech.edu) John >Van - >I'm "near" Georgia Tech (GIT). They are one of our Universities. > >I've contacted a sys admin there; he and I've been buddies for years. He's >not real sure where the hosts are; but, he'll see what he can do. I hope >this will yield results. > >Alan > >At 3:51 PM 6/13/95, Van Jacobson wrote: >>Host alps.cc.gatech.edu and appalachian.cc.gatech.edu are now >>sending a total of 600kb/s at ttl 128 to mbone address >>224.1.1.1, udp ports 7001, 7002, 7003. They have going doing >>this for a couple of hours. Email to root & users logged on to >>this machine has had no effect. Is there someone at or near >>Georgia Tech that could ask them to stop? Thanks. >> >> - Van >====================================================================== >Alan M. Brown InterNet: Alan@PeachNet.EDU >Director - Engineering Telephone: (404) 423-6860 >PeachNet Facsimile: (404) 423-6868 From list-mgr@ISI.EDU Tue Jun 13 07:53:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 14:53:11 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 14:53:10 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id OAA14821; Tue, 13 Jun 1995 14:53:54 -0700 Message-Id: <199506132153.OAA14821@rx7.ee.lbl.gov> To: kevin@cc.gatech.edu (Kevin C. Almeroth) Cc: mbone-na Subject: Re: host alps.cc.gatech.edu sending 450kb/s to mbone In-Reply-To: Your message of Tue, 13 Jun 95 16:35:35 EDT. Date: Tue, 13 Jun 95 14:53:53 PDT From: Van Jacobson > Now if everyone did pruning... Ciscos don't prune. Given cisco's attitude, they're not likely to anytime soon. So as long as there's at least one cisco somewhere in the world running PIM (and there are many, many more than one already) sending at an inappropriate ttl is going to cause trouble. - Van From list-mgr@ISI.EDU Tue Jun 13 14:20:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 15:20:31 -0700 Received: from cssun.mathcs.emory.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 15:20:30 -0700 Received: from shangchun.mathcs.emory.edu (shangchun [128.140.2.17]) by cssun.mathcs.emory.edu (8.6.10/8.6.9-940818.01cssun) with ESMTP id SAA08563; Tue, 13 Jun 1995 18:20:24 -0400 From: Shun Yan Cheung Received: (cheung@localhost) by shangchun.mathcs.emory.edu (8.6.10/8.6.9) id SAA04486; Tue, 13 Jun 1995 18:20:24 -0400 Date: Tue, 13 Jun 1995 18:20:24 -0400 Message-Id: <199506132220.SAA04486@shangchun.mathcs.emory.edu> To: kevin@cc.gatech.edu, van@ee.lbl.gov Subject: Re: host alps.cc.gatech.edu sending 450kb/s to mbone Cc: mbone-na X-Sun-Charset: US-ASCII >From: Van Jacobson > >Ciscos don't prune. Given cisco's attitude, they're not likely >to anytime soon. So as long as there's at least one cisco >somewhere in the world running PIM (and there are many, many more >than one already) sending at an inappropriate ttl is going to >cause trouble. Do not fear, we are working on improving the video stream sender so it will determine the most appropriate TTL for each multicast group. We have to `thank' the non-prune fiasco to come up with this improvement... Shun Yan From list-mgr@ISI.EDU Tue Jun 13 13:15:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 16:15:24 -0700 Received: from everest.cclabs.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 16:15:23 -0700 Received: from sgi6.phlab.missouri.edu (sgi6.phlab.missouri.edu [128.206.115.36]) by everest.cclabs.missouri.edu (8.6.12/8.6.12) with SMTP id SAA00014; Tue, 13 Jun 1995 18:15:05 -0500 Date: Tue, 13 Jun 1995 18:15:03 -0500 (CDT) From: "Paul 'Shag' Walmsley" X-Sender: ccshag@sgi6.phlab.missouri.edu To: Van Jacobson Cc: "Kevin C. Almeroth" , mbone-na Subject: Re: host alps.cc.gatech.edu sending 450kb/s to mbone In-Reply-To: <199506132153.OAA14821@rx7.ee.lbl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 13 Jun 1995, Van Jacobson wrote: > > Now if everyone did pruning... > > Ciscos don't prune. Given cisco's attitude, they're not likely > to anytime soon. So as long as there's at least one cisco Why has cisco chosen not to implement pruning 'anytime soon?' - Paul "Shag" Walmsley "Praise and blame alike mean nothing." -- Virginia Woolf From list-mgr@ISI.EDU Tue Jun 13 11:57:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 18:58:08 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 18:58:07 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id SAA28770; Tue, 13 Jun 1995 18:57:34 -0700 Date: Tue, 13 Jun 1995 18:57:34 -0700 From: Dino Farinacci Message-Id: <199506140157.SAA28770@stilton.cisco.com> To: ccshag@cclabs.missouri.edu Cc: van@ee.lbl.gov, kevin@cc.gatech.edu, mbone-na In-Reply-To: "Paul 'Shag' Walmsley"'s message of Tue, 13 Jun 1995 18:15:03 -0500 (CDT) Subject: host alps.cc.gatech.edu sending 450kb/s to mbone >> Why has cisco chosen not to implement pruning 'anytime soon?' Cisco hasn't chosen anything. We never really do. DVMRP Pruning/Grafting is on our todo list. We have never said we weren't going to do it. Dino From list-mgr@ISI.EDU Tue Jun 13 18:36:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 19:37:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 19:36:57 -0700 Received: from cssun.mathcs.emory.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 19:36:54 -0700 Received: (from cheung@localhost) by cssun.mathcs.emory.edu (8.6.10/8.6.9-940818.01cssun) id WAA16081; Tue, 13 Jun 1995 22:36:44 -0400 Date: Tue, 13 Jun 1995 22:36:44 -0400 From: Shun Yan Cheung Message-Id: <199506140236.WAA16081@cssun.mathcs.emory.edu> To: mbone Subject: Multicast experiment Cc: ammar@cc.gatech.edu, root@cc.gatech.edu Content-Length: 1217 First let me appologize for today's multicast experiment that caused so much activity of the mailing list. We were fieldtesting an adaptive multicast multimedia system. The program has been previously tested (thoroughly) using either Emory or OGI as receiver and sender at Georgia Tech. However receivers at Emory and OGI were never fired up at the same time. When we were sending between GaTech and Emory, we took care not to use large TTL (they are connected by a T1 link and the sustained transmit rate is about 450Kbps). Today we tried the experiment using receivers at Emory and OGI. What went wrong today was the result of (1) interference of two features in our system, (2) an errornous assumption on the pervasiveness of pruning and (3) one design flaw. I won't go into the features. But today's fiasco exposed a design flaw that previous experiments could not expose, which was to use the same (large) TTL for all multicast groups. We have made two improvements to the system: 1. restrain sender and receivers (done and tested) 2. use different TTL for diff. groups (incorporated, but not tested). These changes will prevent the system from overwhelming the MBone again. Regards, Shun Yan Cheung From list-mgr@ISI.EDU Tue Jun 13 15:43:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 22:45:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 22:44:27 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 13 Jun 1995 22:44:27 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA08771; Tue, 13 Jun 95 22:43:56 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9506140543.AA08771@taurus.cs.nps.navy.mil> Subject: Re: EUnet GB policy on Cu-SeeMe ... To: R.Cogger@cornell.edu (Richard Cogger) Date: Tue, 13 Jun 1995 22:43:55 -0700 (PDT) Cc: mbone (Multicast Backbone mail list), i3la_netdesign@mbari.org (I3LA Network Design Team), tlemswil@nps.navy.mil (Tracey L Emswiler) In-Reply-To: from "Richard Cogger" at Jun 10, 95 04:40:59 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 4261 Richard Cogger writes: > There are a lot of issues involved in going to multicast, but when we can, > we will. Apple's mcast code (part of their OpenTransport package) is > supposed to be out soon (in a solid version), perform reasonably sometime > after that, and be in most folks hands, perhaps by early '96. A more > serious problem is the following: > How soon do you estimate that a typical non-techie Internet user > will be able to just use IP mcast, without having to consult with a network > admin, etc. to get access to the mbone? What fraction of current Internet > users would you estimate have access to the mbone? What fraction in a year? (a) MBone users don't need to consult with a net admin type to use MBone. Initially configuring tunnels takes expertise but it is essentially a one-time effort. The bad effects of excessive bandwidth are so severe that you want your site network administrators involved in initial configuration, hopefully to avoid situations like the one that started this whole thread going. You do not need a site administrator or a connection to the MBone to download tools and run them locally. You do not need a site administrator to access the global MBone from a connected subnet. We do try to provide minimal protection from naive users by setting 'group' permissions on installed MBone software apps, requiring a short training session before giving a user execute permission. (b) Most recent statistic reported on this list was 1800 subnets, something around 15 countries, with a corresponding footprint equivalent to the size of the Internet in 1990, growing at about the same exponential rate. (c) If you mean how big in a year's time from now, the number a year ago was 1500 subnets. That sounds like one per day. There is not that much 'where do I connect my tunnel to' traffic on this list, though... I read somewhere that physical growth of the Internet is 15% per month, sustained, currently equal to about one LAN every 30 seconds. (Any better statistic + reference is welcome). > [...] > please don't mark me down as being anti-multicast. Actually, I think the > best results are ultimately going to come from a combination of > topology-aware multicast routing with application-aware relay points, such > as reflectors. > [...] > We would also have to implement the encodings, and at least a good part of > the currently deployed Mac (and Windows) fleet lacks the oomph to handle > it. I'm not sure which reflector difficulties you have in mind; but we > would also forego reflector opportunities. But like I said, we are going > to do it when and as it becomes feasable, but I expect we will keep on with > the reflector too. A reflector that sends/listens to multicast backbone nv/vic and sends/listens to multicast CU-SeeMe encoding for local Macs/PCs sounds like a win-win for bandwidth conservation and computational horsepower. > Do you expect to be able to handle multi-party mbone conferencing on this > frame-relay cloud? I don't think you can do very successful multiparty > conferencing on a network of that capacity (unless maybe if you dedicate it > for a single conference) with either carefully engineered mbone tunnels or > with a carefully engineered reflector net. I can't guess which way you > could have a least unsatisfactory result, but I doubt the difference will > be large. We are considering those same questions. We do have a default video application. I hope to see a single channel of program video, a shared audio channel that includes a class, and perhaps a very low framerate video channel back from the class. There are a lot of interesting challenges to see if this can be arranged in a useful way. This is several-to-many, i.e. several interacting sites with many monitoring. We understand it is impossible on paper and are trying anyway... :) One interesting thing about Frame Relay is that it can be upgraded fractionally to T1 with a phone call and $$. Thanks for your feedback. All the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv.html From list-mgr@ISI.EDU Wed Jun 14 10:34:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 01:40:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 01:35:27 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 01:35:26 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 14 Jun 1995 01:35:20 -0700 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 14 Jun 1995 09:34:56 +0100 To: hwb@nlanr.net (Hans-Werner Braun) Cc: mbone Subject: Re: wanna try audio or video stuff? In-Reply-To: Your message of "Sun, 11 Jun 95 11:03:31 PDT." <199506111803.LAA06425@hwb.extern.ucsd.edu> Date: Wed, 14 Jun 95 09:34:53 +0100 Message-Id: <645.803118893@cs.ucl.ac.uk> From: Jon Crowcroft >I am only saw the bits and pieces people forwarded me of this >discussion, as I do not regularly cunsult this mailing list. I have to >say, though, that most of what I saw appears a little silly to me. i thought _some_ of it looked like a useful debate...at least to get at least 2 or 3 ISPs views on things....even though this list isn't really for operational short term things, but ratehr for Mbone activity/operations.....but anyhow: meanwhile to address the money-flow versus timeliness guarantee standard answer to how to support Mbone or other pseudo-constant bitrate (or at least non--politeley-adaptive) traffic: the origianl problem that the provider in question had can be solved one of two ways 1/ engineer routers that _support_ minimum rates (or other int-serv service models) of traffic....and bill for anyone using above the pure fifo or fair queue service ....apparently, some people thought this is too hard (despite being pointed at existence proofof router code that can do it...), so lets go on to the other approach.... 2/ engineer routers to provide a drop/filter for traffic that doesn't conform to TCP congestion control schemes (most peopels comments here made it clear that people didn't udnerstand the subtleties of tcp congestion control in cases of differenrt RTTs to the bottlenecjk, ore in extreme overload cases but we'll let that lie for now....) the latter case is trivial - yo ucan use existing simple priority queue mechanisms in many vendors routers to put all UDP traffic in a lower priority queue so that if the queues get full, it gets dropped before TCP traffic.....of course, you might want to avoid doign this to stuff on DNS or SNMP ports, and you might want to beat up router vendors where this sort of filtering impinges on the standard IP forwarding path performance, but thwen f you are a half way dwecent ISP, you will already have done this for firewall performance reasons anyhow........ so in the short short term, the problem that the ISPs wanted to fix was the (unintended) denial of service casused by non-backing-off UDP based applications......not the active support program for giving the latter traffic a minimum (or other) guarantee..... cheers jon From list-mgr@ISI.EDU Thu Jun 15 09:29:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 06:30:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 06:29:11 -0700 Received: from pec.etri.re.kr by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 06:28:52 -0700 Received: by pec.etri.re.kr (8.6.9H1/8.6.4) id XAA13668 From: Jung-Soo Park Posted-Date: Wed, 14 Jun 1995 23:29:08 +1000 Message-Id: <199506141329.XAA13668@pec.etri.re.kr> Subject: subscribe To: mbone Date: Wed, 14 Jun 1995 23:29:06 +0900 (KST) X-Mailer: ELM [version 2.4 PL21-h4] Content-Type: text Content-Length: 63 subscribe From Jungsoo, Park (email : jspark@pec.etri.re.kr) From list-mgr@ISI.EDU Wed Jun 14 01:03:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 08:04:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 08:03:43 -0700 Received: from hwb.extern.ucsd.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 08:03:42 -0700 Received: by hwb.extern.ucsd.edu id IAA10764; Wed, 14 Jun 1995 08:03:02 -0700 From: hwb@nlanr.net (Hans-Werner Braun) Message-Id: <199506141503.IAA10764@hwb.extern.ucsd.edu> Subject: Re: wanna try audio or video stuff? To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Wed, 14 Jun 95 8:03:01 PDT Cc: mbone In-Reply-To: <645.803118893@cs.ucl.ac.uk>; from "Jon Crowcroft" at Jun 14, 95 9:34 am >2/ engineer routers to provide a drop/filter for traffic that doesn't >conform to TCP congestion control schemes (most peopels comments here >made it clear that people didn't udnerstand the subtleties of tcp >congestion control in cases of differenrt RTTs to the bottlenecjk, ore >in extreme overload cases but we'll let that lie for now....) > >the latter case is trivial - yo ucan use existing simple priority >queue mechanisms in many vendors routers to put all UDP traffic in a >lower priority queue so that if the queues get full, it gets dropped >before TCP traffic.....of course, you might want to avoid doign this >to stuff on DNS or SNMP ports, and you might want to beat up router >vendors where this sort of filtering impinges on the standard >IP forwarding path performance, but thwen f you are a half way dwecent >ISP, you will already have done this for firewall performance reasons >anyhow........ Personally, I think this would be inappropriate. Remember the Mailbridges, where in the end one exception after the other had to be made? At a higher level this would change the Internet service model from an IP network to a TCP(-like) network. This would not be right or wrong, but the change in model would have to be well defined, communicated, and sold to customers. Say, if someone would want to do high speed fluid dynamics graphics output as, say, a chemist at a high performance computing center, and wants to send, hmm, 10 frames of a 24 bit image (1k*1k) across the country to a chemistry colleague (or a funding agency?) without caring for losses if some bits or even images drop out, then a simple UDP stream would be appropriate. This may be a meritorious and funded activity, and the grant for it may be funding the connection to the ISP. That chemist may not otherwise know anything or care about networking, and just wants things to work, and premium service on his expensive link to an ISP. You better have a good story for why you make him a second class citizen on the net. This is not an outrageous example, we are clearly expecting such applications, and people are working on it, if not have them already. And thousands of them may appear and disappear in parallel. >so in the short short term, the problem that the ISPs wanted to fix >was the (unintended) denial of service casused by non-backing-off UDP >based applications......not the active support program for giving the >latter traffic a minimum (or other) guarantee..... Uh, I understand that. At a high enough level of abstraction people use services in an environment that the environment was not built for. As such you have to choose between two unpopular choices, set policy, or change the environment. From an ISP's point of view I agree that tactical decisions have to be made that ensure the survival of the network (and its clients) over the survival of a single application. But tell that to the chemist who is paying for the services. Or funding agencies who may like CU-SeeMe because it "just works" across the network from workstations in their offices and is inexpensive. Or kids who like the iphone IRC audio tie-in and like chatting with their new-found pals. Hans-Werner From list-mgr@ISI.EDU Wed Jun 14 08:09:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 09:11:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 09:09:39 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 09:09:38 -0700 Received: by chops.icp.net id <20696>; Wed, 14 Jun 1995 12:09:25 -0400 From: Sean Doran To: hwb@nlanr.net, J.Crowcroft@cs.ucl.ac.uk Subject: Re: wanna try audio or video stuff? Cc: mbone Message-Id: <95Jun14.120925-0400_edt.20696+88@chops.icp.net> Date: Wed, 14 Jun 1995 12:09:22 -0400 | the latter case is trivial - yo ucan use existing simple priority | queue mechanisms in many vendors routers to put all UDP traffic in a | lower priority queue so that if the queues get full, it gets dropped | before TCP traffic. No you can't. What Dino hasn't mentioned is that while Cisco has a custom queueing system, it can't be run at anything approaching the kind of pps throughput rates in backbone boxes, where you come across this kind of bottleneck, and bottlenecks relating to TCP flows through large delay*bandwidth products. I am not aware of ANY router by ANY vendor that has the horsepower to do this kind of per-protocol-and-per-port queueing with an FDDI interface and three DS3s (or two FDDI interfaces and two DS3s, or one FDDI interface, one DS3 and a bunch of E1s or... all of which are astonishingly busy). I imagine that this will change eventually, however to suggest that this is trivial or even possible now or in the short run is simply not realistic. Once again, you are unwilling to recognize that we are a generation or two worth of deployable router technology away from being able to do what you want. Sean. From list-mgr@ISI.EDU Wed Jun 14 10:10:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 11:11:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 11:10:59 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 11:10:57 -0700 Received: by chops.icp.net id <20696>; Wed, 14 Jun 1995 14:10:45 -0400 From: Sean Doran To: hwb@nlanr.net, J.Crowcroft@cs.ucl.ac.uk Subject: Re: wanna try audio or video stuff? Cc: mbone Message-Id: <95Jun14.141045-0400_edt.20696+93@chops.icp.net> Date: Wed, 14 Jun 1995 14:10:44 -0400 No, what we want is to make it very clear to the people writing applications that they have to be network-friendly, DESPITE what people who claim they know better than the people who run networks say to them. Case in point - the CUSEEME folks are now learning that they have to adjust their software to avoid it being a tool for denials-of-service, notwithstanding the fact that there are people here who are complaining that the Internet OUGHT to support X, Y, and Z, and that to do so is trivial, and therefore the service providers should be ignored as lazy, whining fools who don't know how to run their networks. Sean. From list-mgr@ISI.EDU Wed Jun 14 04:23:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 11:38:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 11:25:14 -0700 Received: from hwb.extern.ucsd.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 11:24:13 -0700 Received: by hwb.extern.ucsd.edu id LAA11175; Wed, 14 Jun 1995 11:23:18 -0700 From: hwb@nlanr.net (Hans-Werner Braun) Message-Id: <199506141823.LAA11175@hwb.extern.ucsd.edu> Subject: Re: wanna try audio or video stuff? To: smd@icp.net (Sean Doran) Date: Wed, 14 Jun 95 11:23:18 PDT Cc: mbone In-Reply-To: <95Jun14.141045-0400_edt.20696+93@chops.icp.net>; from "Sean Doran" at Jun 14, 95 2:10 pm From a service providers point of view I would agree with you. From someone's point of you who buys a T1 flat from you, I would claim it is none of your business what I do with it. If that is not ok, define your service model and sell it as that. But do not sell it as an IP network then, because it won't be. Not having such a model makes you appear as lazy, whining fools who don't know how to run their networks. YOU asked for playing in the kitchen, nobody forced you. YOU told people you give them a T1 (or whatever), and tell them you take care of the rest. Case in point - the ISP folks are now learning that they have to adjust their mindset to avoid it being a tool for denials-of-service. Not all applications are equal, unlike phone circuits, for example. >No, what we want is to make it very clear to the people >writing applications that they have to be network-friendly, >DESPITE what people who claim they know better than >the people who run networks say to them. > >Case in point - the CUSEEME folks are now learning that >they have to adjust their software to avoid it being >a tool for denials-of-service, notwithstanding the fact >that there are people here who are complaining that the >Internet OUGHT to support X, Y, and Z, and that to do >so is trivial, and therefore the service providers >should be ignored as lazy, whining fools who don't know >how to run their networks. > > Sean. From list-mgr@ISI.EDU Wed Jun 14 23:08:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 12:09:49 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 12:08:58 -0700 Received: from eunet.EU.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 12:08:55 -0700 Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id VAA09388; Wed, 14 Jun 1995 21:08:53 +0200 Received: by jotun.EU.net id AA00676 (5.67a/IDA-1.5); Wed, 14 Jun 1995 21:08:52 +0200 Message-Id: <199506141908.AA00676@jotun.EU.net> From: Per Gregers Bilse Date: Wed, 14 Jun 1995 21:08:52 +0200 In-Reply-To: <199506141823.LAA11175@hwb.extern.ucsd.edu> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: hwb@nlanr.net (Hans-Werner Braun) Subject: Re: wanna try audio or video stuff? Cc: mbone On Jun 14, 11:23, Hans-Werner Braun wrote: > none of your business what I do with it. If that is not ok, define your > service model and sell it as that. But do not sell it as an IP network > then, because it won't be. Not having such a model makes you appear as For the record, what set this whole thing rolling was precisely the fact that people were referred to the service agreement, which (quite reasonably, IMHO) states that customers are not allowed to use applications that do damage to the network; similar clauses exist in practically all Internet access contracts/agreements. (If somebody thinks that we are oversensitive, that's just too bad; we want to maintain the quality of our network at the levels the vast majority of our customers have become accustomed to.) Generally, if a sizeable majority of the software being used in the Internet doesn't stay network friendly, ISPs will be forced to employ measures that make the whole Internet an altogether much less interesting place to be. What we (and all other ISPs, can't imagine anything else) want is for developers to please keep this in mind and think just a little bit in terms of Internet ecology when writing applications. It is not in tune with "modern thinking" to have some authority (the ISP in this case) clean up after wasteful individuals -- it is generally accepted that individuals must assume at least some responsibility themselves, and a particularly heavy responsibility is placed on product developers. I don't really see why this should be substantially different for the Internet than for any other industry/products. Everybody can say "CFC-free", how about "UDP-free"? I'm joking!! :-) Well, mostly; don't release more than necessary. -- === ___ === Per G. Bilse, Mgr Network Operations Ctr === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From list-mgr@ISI.EDU Wed Jun 14 11:19:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 12:20:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 12:20:03 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 12:20:01 -0700 Received: by chops.icp.net id <20696>; Wed, 14 Jun 1995 15:19:44 -0400 From: Sean Doran To: hwb@nlanr.net, smd@icp.net Subject: Re: wanna try audio or video stuff? Cc: mbone Message-Id: <95Jun14.151944-0400_edt.20696+95@chops.icp.net> Date: Wed, 14 Jun 1995 15:19:33 -0400 What SprintLink sells is connectivity to the Global Internet. The value in the product stems from the fact that: 1/ it works 2/ it gets you to essentially all the places you want to get to 3/ you can generally get there pretty quickly if you have a T1 4/ we know what we're doing for the short and medium terms and know what we want to be doing for the long term, and have been silent about none of that It is nobody's business what you do with your T1 so long as you don't cause denials-of-service to people, try to break into their machines and suchlike. All of those are generally best dealt with in a real society, however it is important for engineers to keep networks workable, so we DO attack potential and actual denials-of-service. If you want an IP network with the kind of things you and Jon seem to be asking for from "an IP network", then you want to talk to the Sprint Managed Router Networks folks, details in http://www.sprintmrn.com/. Just don't expect global connectivity with the same kind of service-levels you'll get from them. They even care when you whine and piss and complain about unworkable things and fantasies about what is in your service agreement, unlike me. Sean. From list-mgr@ISI.EDU Wed Jun 14 11:56:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 12:57:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 12:56:45 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 12:56:42 -0700 Received: by chops.icp.net id <20696>; Wed, 14 Jun 1995 15:56:34 -0400 From: Sean Doran To: hwb@nlanr.net, smd@icp.net Subject: Re: wanna try audio or video stuff? Cc: mbone Message-Id: <95Jun14.155634-0400_edt.20696+98@chops.icp.net> Date: Wed, 14 Jun 1995 15:56:30 -0400 Actually, I want to clarify one quick thing; Sprint's SprintLink and ICM service model is relatively straightforward, particularly with respect to International Private Lines, the saturation of which was what started this whole thing... What you do with your access link is up to you. If you want to do stupid things that saturates your lines, then you can go do that, we don't care. If someone is doing nasty things to your link and you need our help to stop it, we will help stop it. However, if you don't care, then neither do we. This mostly stems out of my Swedish-speaking colleague smacking me on the head and pointing out that if CUSEEME becomes a problem in our network, we will fix our network, and that this was not made clear here. He also pointed out that there is an E3 being built between Pennsauken and Stockholm, and that lots of people are going to be doing lots of things that will eat bandwidth for breakfast lunch and dinner. ("There are 600 or so local radio stations in Sweden, do you want them all?") So, we have to be ready for that. Scary, yes. Impossible to deal with, no. Difficult in the short run for us, and for other providers, absolutely. Can we avoid things that make it MORE difficult, like badly-designed protocols? Yes. Should we? I hear "Yes" from people here who are network operators. It would be nice to hear even grudging "Yes"es from HWB and company, since people do respect them, and it's nice to be reassured that they have clues. :-) Sean. From list-mgr@ISI.EDU Thu Jun 15 16:08:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 13:09:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 13:08:33 -0700 Received: from munnari.OZ.AU by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 13:08:31 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18023; Thu, 15 Jun 1995 06:08:17 +1000 (from kre@munnari.OZ.AU) To: Per Gregers Bilse Cc: hwb@nlanr.net (Hans-Werner Braun), mbone Subject: Re: wanna try audio or video stuff? In-Reply-To: Your message of "Wed, 14 Jun 1995 21:08:52 +0200." <199506141908.AA00676@jotun.EU.net> Date: Thu, 15 Jun 1995 06:08:10 +1000 Message-Id: <3669.803160490@munnari.OZ.AU> From: Robert Elz Date: Wed, 14 Jun 1995 21:08:52 +0200 From: Per Gregers Bilse Message-ID: <199506141908.AA00676@jotun.EU.net> For the record, what set this whole thing rolling was precisely the fact that people were referred to the service agreement, which (quite reasonably, IMHO) states that customers are not allowed to use applications that do damage to the network; And then ... From: Sean Doran Message-Id: <95Jun14.151944-0400_edt.20696+95@chops.icp.net> Date: Wed, 14 Jun 1995 15:19:33 -0400 It is nobody's business what you do with your T1 so long as you don't cause denials-of-service to people, try to break into their machines and suchlike. The question here seems to be what "do damage" means. Almost anyone would agree that "try to break into their machines" is at least an attempt at that, so would be deliberately running those obscure applications (perversions of applications) that (used to) cause routers to crash. Whether simply sending traffic from a widely available application that seems to be useful and productive, falls into the class of "causing damage" or even a denial of service, or whether its just the user's business using their T1 as they see fit, doesn't seem nearly so clear to me. I'd suspect that if the ISP's want to be able to stop this class of application, then they're going to need to add one of three things to their service agreement, as I doubt that "do damage" covers this case (however much it might be apaprent to the ISP that this application causes problems). Those are, either 1) some applications are prohibited, the list available from time to time from the ISP (perhaps prohibited unless used in certain manners, or at certain times) 2) while the available bandwidth is T1 (or whatever) the aggregate that the customer is allowed to inject into the network (averaged over some suitable shortish period - 15 mins or something) s really only T1/x for some x. [Clearly the amount that the customer can extract from the net need not be limited, if its reached the customer its beyond doing "damage".] 3) (2), except only applying when the ISP's net, or some net further down the chain is congested. Now (3) looks to be what the ISP's are likely to actually care about. As long as there's bandwidth, etc, available, what the customers actually do isn't a problem, its only when the ISP's bandwidth is pressed that it matters. However (3) looks to me to be unimplementable - how on earth is the customer to ever discover just when the ISP's net is congested, let alone nets further down the chain? So that leaves just (1) or (2), one of which might be necessary, might even be reasonable, however I suspect that terms like those will need to be made explicit, and simply can't be covered by "do damage". Of course, there might be some other method I haven't considered, but I'd also doubt that "do damage" can reasonably cover that either. Note that there's a pretty simple traffic (as in automobile) analogy to all of this - there's no doubt that the road system can only carry certain numbers of cars (and trucks, etc). There also tend to be rules (usually laws) against doing damage to the road network. Clearly, to the road network itself, injecting more traffic into a conjested system is "doing damage" in the sense that only an upgrading of the roads can cope. However, you'd be very surprised to find flashing lights and a siren behind you, signalling you to pull over, when all you'd done was driving onto a congested freeway. You'd be unlikely to be less surprised if instead of a single car you were a member of a wedding or funeral procession, with perhaps hundreds of cars, or leaving from work at a large factory/whatever where there might be thousands all leaving basically as quickly as the car park gates let them out. From the consumer's point of view, this kind of thing just isn't "damage". kre From list-mgr@ISI.EDU Thu Jun 15 01:48:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 14:51:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 14:49:57 -0700 Received: from noc.BelWue.DE by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 14:49:52 -0700 Received: from pi4.informatik.uni-mannheim. (pi4.informatik.uni-mannheim.de) by noc.BelWue.DE with SMTP id AA19464 (5.65c8/IDA-1.4.4 for ); Wed, 14 Jun 1995 23:49:18 +0200 Received: from eratosthenes by pi4.informatik.uni-mannheim.de (5.65/BelWue-1.1DEC) id AA26638; Wed, 14 Jun 95 23:23:16 +0200 From: whd@pi4.informatik.uni-mannheim.de (Wieland Holfelder) Received: by eratosthenes; (5.65/1.1.8.2/02May95-1040AM) id AA08661; Wed, 14 Jun 1995 23:48:40 +0200 Message-Id: <9506142148.AA08661@eratosthenes> Subject: Re: wanna try audio or video stuff? To: smd@icp.net (Sean Doran) Date: Wed, 14 Jun 1995 23:48:40 +0200 (MET DST) Cc: mbone (Multicast Backbone) In-Reply-To: <95Jun14.151944-0400_edt.20696+95@chops.icp.net> from "Sean Doran" at Jun 14, 95 03:19:33 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1965 Sean Doran writes: > What SprintLink sells is connectivity to the Global Internet. Hhm, I guess we should better understand what the "Global Internet" is after all. What the Internet makes is clear for probably most of the users concerning their campus net, for some of them it might be even clear how it works to connect to a service provider, but behind that it's quite dark for most of them (including myself). It's just the "Global Internet" whatever it means, who cares?. If I buy a T1 from my site to a provider, how do I know what is going on behind this service access point? Who is providing the "Global Internet" everybody else is connecting to? Who decides who is allowed to provide service to it? In Germany e.g. we still have the monopoly of the German Telekom and a service provider can't just offer complete service. The customers have to buy a link from the Telekom to connect to the service provider and they offer the service to the Internet. But where are all these providers are connecting to? What is the hierarchy, is the net of providers the Global Internet? Who decides who can be a provider and why? If I want to connect to the Global Internet, why can I just be a provider myself so I don't have to take the detour through another provider? But on the other hand where do I have to connect to then? I hope this is not too high level, just random thoughts and it would definitely helpful if someone could bring some light into it. just my .05$ -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder University of Mannheim Praktische Informatik IV Email: whd@pi4.informatik.uni-mannheim.de L 15,16 Fax : +49-621-292-5745 68131 Mannheim Phone: +49-621-292-5642 Germany http://www.informatik.uni-mannheim.de/~whd ------------------------------------------------------------------------------- From list-mgr@ISI.EDU Wed Jun 14 15:14:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 16:15:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 16:14:42 -0700 Received: from titan.sprintlink.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 16:14:39 -0700 Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id TAA24703; Wed, 14 Jun 1995 19:14:26 -0400 Date: Wed, 14 Jun 1995 19:14:26 -0400 From: Vadim Antonov Message-Id: <199506142314.TAA24703@titan.sprintlink.net> To: bilse@eu.net, kre@munnari.OZ.AU Subject: Re: wanna try audio or video stuff? Cc: hwb@nlanr.net, mbone kre wrote: >Whether simply sending traffic from a widely available >application that seems to be useful and productive, falls >into the class of "causing damage" or even a denial of service, >or whether its just the user's business using their T1 as >they see fit, doesn't seem nearly so clear to me. Want to get a T-3 full of pings from a useful and productive application? Just to make it clear to you. A person arguing that cooperative congestion control should be scrapped for the sake of "usefulness" and "productivity" is fool or worse. (Of course, there is a possiblity that he's genius and figured out a way to do global data networks w/o doing it or increasing costs by order of magnitude; in this case we'd like to hear how, bless the humankind, please). The situation is clear-cut -- there is an application which breaks the network for no good reason. It should be fixed, or ISPs will protect themselves and their customers which bought network access to use older well-behaved applications. --vadim From list-mgr@ISI.EDU Wed Jun 14 15:27:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 16:28:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 16:28:10 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 16:28:08 -0700 Received: by chops.icp.net id <20696>; Wed, 14 Jun 1995 19:27:49 -0400 From: Sean Doran To: bilse@eu.net, kre@munnari.OZ.AU Subject: Re: wanna try audio or video stuff? Cc: hwb@nlanr.net, mbone Message-Id: <95Jun14.192749-0400_edt.20696+4@chops.icp.net> Date: Wed, 14 Jun 1995 19:27:43 -0400 Ok, kre, so I open up a 2048kbps full-motion video pipe to a colleague of mine in Australia at the far end of AARNET, no TCP, no congestion-control. Obviously this is OK by you, and it's OK by the AARNET connectee (there was a talk about AARNET's volume charging which was moderately scary, but the organization in question has very deep pockets), and I know that the infrastructure between me and the U.S. end of the straw to AARNET isn't going to be a problem. AARNET's pipe is pretty fat now, so that might not be all that bad a problem now too. I think it may actually work, modulo some loss here and there. Cool. I'll do it at 2100 local time (GMT -0500). Run-time will be about two or three hours, depending on when I remember to turn off the transmitter. I gather that no flashing lights or sirens of the ISP type will be seen or heard from your side of the world, no? Sean. P.S.: Tomorrowishly I may do a bunch of CUSEEMEs back and forth, about the same time of day. Ten to sixteen or so should be relatively straightforward. From list-mgr@ISI.EDU Wed Jun 14 15:32:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 16:33:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 16:32:41 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 16:32:38 -0700 Received: by chops.icp.net id <20696>; Wed, 14 Jun 1995 19:32:26 -0400 From: Sean Doran To: smd@icp.net, whd@pi4.informatik.uni-mannheim.de Subject: Re: wanna try audio or video stuff? Cc: mbone Message-Id: <95Jun14.193226-0400_edt.20696+5@chops.icp.net> Date: Wed, 14 Jun 1995 19:32:17 -0400 | If I buy a T1 from my site to a provider, how do I know what | is going on behind this service access point? You don't need to; TCP figures this out quite well. TCP-like congestion-avoidance and -control for UDP-using applications would too. The rest of your questions should go to com-priv@psi.net (the standard place where that sort of thing goes unanswered) or to whatever folks have taken over the InterNIC's Information Services. Sean. From list-mgr@ISI.EDU Thu Jun 15 20:01:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 17:02:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 17:02:09 -0700 Received: from munnari.OZ.AU by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 17:02:03 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27275; Thu, 15 Jun 1995 10:01:16 +1000 (from kre@munnari.OZ.AU) To: Sean Doran Cc: bilse@eu.net, hwb@nlanr.net, mbone Subject: Re: wanna try audio or video stuff? In-Reply-To: Your message of "Wed, 14 Jun 1995 19:27:43 -0400." <95Jun14.192749-0400_edt.20696+4@chops.icp.net> Date: Thu, 15 Jun 1995 10:01:09 +1000 Message-Id: <3748.803174469@munnari.OZ.AU> From: Robert Elz Date: Wed, 14 Jun 1995 19:27:43 -0400 From: Sean Doran Message-ID: <95Jun14.192749-0400_edt.20696+4@chops.icp.net> Ok, kre, so I open up a 2048kbps full-motion video pipe to a colleague of mine in Australia at the far end of AARNET, I think it may actually work, modulo some loss here and there. Yes, it quiote probably might, though the amount of loss would be pretty high - you're right the pipe is pretty fat, but at the time of day you (not so accidentally I assume) picked, it would be full anyway, however big it gets made, its always full. I gather that no flashing lights or sirens of the ISP type will be seen or heard from your side of the world, no? Actually, very probably not. P.S.: Tomorrowishly I may do a bunch of CUSEEMEs back and forth, about the same time of day. Ten to sixteen or so should berelatively straightforward. I wouldn't be surprised if that's normal anyway. I had been lacking an attribution to place on some major traffic usage we get (less than http, and ftp still I think, but up there, way more than netnews, mbone, etc) but hadn't ever thought to think it could be CuSeeMe (nor until reecently would I have guessed the port). I've never actually see that in use, though I do know it is used in thisss part of the world. I'm about to check and see if our missing traffic is CuSeeMe, it would be nice to finally account for it. kre ps: I suspect that you read my message the wrong way, the same as I suspect Vadim did, I won't send the reply I sent him all over again. From list-mgr@ISI.EDU Thu Jun 15 20:15:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 17:31:03 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 17:16:31 -0700 Received: from munnari.OZ.AU by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 17:16:24 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28112; Thu, 15 Jun 1995 10:16:00 +1000 (from kre@munnari.OZ.AU) To: mbone Subject: Re: wanna try audio or video stuff? In-Reply-To: Your message of "Wed, 14 Jun 1995 19:14:26 -0400." <199506142314.TAA24703@titan.sprintlink.net> Date: Thu, 15 Jun 1995 10:15:53 +1000 Message-Id: <3764.803175353@munnari.OZ.AU> From: Robert Elz After saying in the last message I sent that I wouldn't repeat my reply to Vadim, I found that ISI had said ... While talking to isi.edu: >>> RCPT To: <<< 550 ... User unknown 550 ... User unknown which looks a bit on the weird side. Never mind, here it is one more time (not that I really believe the mbone list is the most appropriate place for all of this traffic). Date: Wed, 14 Jun 1995 19:14:26 -0400 From: Vadim Antonov Message-ID: <199506142314.TAA24703@titan.sprintlink.net> Want to get a T-3 full of pings from a useful and productive application? No, but its a little hard to see how such could be productive, however were some application to be using ICMP for some wacko reason, I don't see any difference from UDP (the two protocols are essentially identical for most purposes if the applications can handle the addressing differences (no ports, but types, etc)). A person arguing that cooperative congestion control should be scrapped for the sake of "usefulness" and "productivity" is fool or worse. I certainly wasn't doing that (however note that denying the (gawd, I've forgotten the term, the thing after the "if", my logic training, such as it was, has flown out the window) doesn't disprove the conclusion...). Hans-Werner commented that the ISP's probably need to make their rules more explicitly known to their customers, many of whom have no real knowledge of what congestion control means by the way. A comment was made that the "do no dammage" clause would cover it, which I responded to, doubting that. I have no desire to see the net ground into the ground by applications that don't scale well, fixing those applications, or restricting them, seems just fine to me. However I do feel that the ISP's should be very clear to the customers about just what is permitted - "anything I don't like when I see it" is a little too broad for me. Is that so difficult? kre From list-mgr@ISI.EDU Wed Jun 14 18:32:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 19:33:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 19:32:30 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 19:32:26 -0700 Received: by chops.icp.net id <20696>; Wed, 14 Jun 1995 22:32:19 -0400 From: Sean Doran To: kre@munnari.OZ.AU, mbone Subject: Re: wanna try audio or video stuff? Message-Id: <95Jun14.223219-0400_edt.20696+6@chops.icp.net> Date: Wed, 14 Jun 1995 22:32:05 -0400 | However I do | feel that the ISP's should be very clear to the customers about | just what is permitted - "anything I don't like when I see it" | is a little too broad for me. Is that so difficult? The problem is that people are inventing new ways of using the Internet all the time, and if we could foresee them, we would be getting rich instead of the people who did, and who subsequently invented them. Things that have existed awhile that we don't necessarily know about (I will admit to occasional lapses in my omniscience) sometimes become popular, and then their side-effects start getting noticed, and sometimes that's painful, as in the case of EUNET et al. vs. CUSEEME. This is also difficult to foresee. One could typify a particular class of applications as "things that don't back off in the face of serious congestion" and therefore should not be used. There are other applications though which are net-unfriendly, viz. "things that set options on streams of packets" and "things that send lots of datagrams at core routers", however there are certainly others which haven't been dreamed up yet that will "do damage". Consequently, one has to have a fairly broad tool with which to stop such things even if they're unforeseeable now. Networking types who abuse a tool like that will probably make their lawyers unhappy, and will get screamed at and other unpleasantries, however once again, the reality is that with the growth rate of the Internet far exceeding the potential learning curve of most formal policymakers, the whole kit and kaboodle often lands in the laps of engineers who generally have as a primary goal keeping everything _working_. Thus the EUNET decision, and my subsequent vocal support for it. Sean. From list-mgr@ISI.EDU Thu Jun 15 23:58:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 21:01:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 21:00:19 -0700 Received: from pec.etri.re.kr by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 14 Jun 1995 20:58:17 -0700 Received: by pec.etri.re.kr (8.6.9H1/8.6.4) id NAA17114 From: Jung-Soo Park Posted-Date: Thu, 15 Jun 1995 13:58:54 +1000 Message-Id: <199506150358.NAA17114@pec.etri.re.kr> Subject: MBone tools for Windows NT[Q] To: mbone Date: Thu, 15 Jun 1995 13:58:53 +0900 (KST) X-Mailer: ELM [version 2.4 PL21-h4] Content-Type: text Content-Length: 1708 Hello, I'd like to know whether MBone tools for Windows NT are or not. I saw the MBone Mailing list on yesterday. I finded the next paragraphes. ---------- Original Message ----------------- > Hi, > > I tried to use WinSd/Vat/NV. It complains "Cannot bind sockett. > Does this mean that the programs do not work with the TCP suite I have > ( TCP from Trumpet) ? In general, where can I find out where the problem > is at -- windows is quite different from UNIX. I cannot read something > like a man page. > > Thanks. It means that your TCP/IP stack does not support the multicast extensions. I had, but lost, the mcast extensions for the Microsoft 32-bit stack (any pointers, anyone?). I'm told that mcast works correctly with Microsoft's stack + extensions, and that FTP Software's mcast kernel works, also. I don't think Trumpet will support mcast in the near future. I could be wrong, though -- I would LIKE to be wrong in this case. -- arlie ---------- the end ----------------- Thus, my question is "Is the WinSd/Vat/NV software mbone tools for Windows NT ?" , and give me the information. Thanks in advance. +----------------------------------------------------+ | Jungsoo, Park | | | | ETRI, Multimedia Standardization Section | | Protocol Engineering Center | | 161 Kajong-Dong, Yusong-Gu, TAEJON, 305-350, KOREA | | (Phone) : 82-42-860-6118 | | (FAX) : 82-42-861-5404 | | (EMAIL) : jspark@pec.etri.re.kr | +----------------------------------------------------+ From list-mgr@ISI.EDU Thu Jun 15 10:11:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 01:15:27 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 01:12:49 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 01:12:45 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 15 Jun 1995 01:12:43 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 15 Jun 1995 09:11:41 +0100 To: Sean Doran Cc: hwb@nlanr.net, J.Crowcroft@cs.ucl.ac.uk, mbone Subject: Re: wanna try audio or video stuff? In-Reply-To: Your message of "Wed, 14 Jun 95 14:10:44 EDT." <95Jun14.141045-0400_edt.20696+93@chops.icp.net> Date: Thu, 15 Jun 95 09:11:37 +0100 Message-Id: <6917.803203897@cs.ucl.ac.uk> From: Jon Crowcroft >No, what we want is to make it very clear to the people >writing applications that they have to be network-friendly, >DESPITE what people who claim they know better than >the people who run networks say to them. this is a wanton misreading of what i and anyone else said clearly, if an appplcation can meaningful adapt, it should however, the IP model does not dictate that it must - a video and audio application has a meaningful minimum rate below which it cannot go (sorry to reaperast this stuff, but this man refuses to actually read what i said before) SO DOES TCP if you as an ISP don't provide a mionimum for the sert of application users you _expect_ to be active, then your service provision is close to useless... that minimum can be 1 MSS per RTT for the set of all acvtive TCP sessions, or maybe a little more - this will cost you a tad more in backbone provision (and EUNET's phrasing i ntheir message was actually pretty good here in the latter part they establish grounds for negotiating this extra with subscribers...) the question of denial of service attacks, whether deliberate or accidental, disrupting other users is not something in the long run that you can make a business case asking the _users_ (or all application writers) to address....at least to do so in a 100% safe way in an ever changing internet of ever changing applications.... if you provide stat muxing service, and its based on FIFO queues, you will lose, since the game theory (and practive) says people will learn how to turn off slow start, so if a few of them, do it they win....sure if a lot of them do it, they all lose,...but in a jungle, there are usually only a few tigers and lots of monkeys... if you don't police them in access routers, how can you expect to survive.... you compeltely misread the underlyingg idea in messages about where i believe respnbilsity lies, and to whome... back to TCP..... Web use of TCP breaks the "cooperativbve " model you _imagine exists in the Internet...Web use of distributed servers breaks the routing ....and network dimensioning badly too because of its poor spatial locality of reference... run web caching servers at every single access point in the net, to fix this, and you as an ISP will _lose business, but this will prevent HTTP (and netscape in particular) overruning your net with thousands of non-slow started SYN/SYN-ACK packets..... where do you think the business case lies? i think it is pretty subtle actually... now back on CUSeeMe - if i have a T1 line, but i run it at 10% CuSeeMe (say a constant single CUSeeMe session) how do you dictate that this non-backed off proportion of my access line is too much? why shouldn't i choose some percentage of the service to be video? - maybe 10% of my traffic is sharte dealers chatting to each other about the content of the other varying 1-90% ....what business is it of yours? conclusions 1. you must pritect your net to protect your subscribers from EACH OTHER 2. you need to have a model of applications that is a tad more subtle than "its TCP, its ok; it isn't, ask us..." that is all i was saying.... jon From list-mgr@ISI.EDU Thu Jun 15 14:21:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 01:25:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 01:24:20 -0700 Received: from rhea.otol.fi by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 01:24:16 -0700 Received: (from okko@localhost) by rhea.otol.fi (8.6.12/8.6.9) id LAA12957; Thu, 15 Jun 1995 11:21:43 +0300 Date: Thu, 15 Jun 1995 11:21:43 +0300 (EET DST) From: Olli-Pekka Halonen To: Dave Wright Cc: mbone Subject: Re: Sparc 5 In-Reply-To: <199506142336.TAA05829@alex.msri.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 14 Jun 1995, Dave Wright wrote: > Has anyone tried using a Sparc5 running 4.1.3 not Solaris with a > VideoPix card to broadcast? We have been using videopix with Sun IPX and SparcStation 10 using both 4.1.3 and 4.1.4. They work just swell, i assume you shouldn't encounter any further problems using this videocard in Sparc5 (thou i can't guarantee it..) -- Okko Olli-Pekka Halonen, Oulu Institute of Technology, Finland From list-mgr@ISI.EDU Thu Jun 15 10:38:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 01:47:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 01:41:47 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 01:41:45 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 15 Jun 1995 01:41:12 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 15 Jun 1995 09:38:35 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Sean Doran Cc: hwb@nlanr.net, mbone Subject: Re: wanna try audio or video stuff? In-Reply-To: Your message of "Wed, 14 Jun 95 15:19:33 EDT." <95Jun14.151944-0400_edt.20696+95@chops.icp.net> Date: Thu, 15 Jun 95 09:38:32 +0100 Message-Id: <18087.803205512@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >If you want an IP network with the kind of things you and >Jon seem to be asking for from "an IP network", then you >want to talk to the Sprint Managed Router Networks folks, >details in http://www.sprintmrn.com/. Just don't expect >global connectivity with the same kind of service-levels >you'll get from them. There are two issues - dealing with this traffic today, and planning so that we can deal with it better tomorrow. Whether you like it or now, real-time traffic sources are here to stay - if not over IP, then the non-realtime traffic will probably move elsewhere too. You don't need heavyweight (or at least what I think of as heavyweight) stuff to handle realtime traffic, but you do need some kind of negative feedback to prevent it taking over all your bandwidth (unless you're from the "bandwidth is free" school). There are many ways to provide this negative feedback, including adaptive applications, charging per bit for UDP, charging for reservations, capping realtime traffic and relying on user disatisfaction, etc, etc. Not all of these are solutions I would like to see in use in tomorrows internet. There are problems though with solutions that don't get *some* assitance from the network (unless the net is overprovisioned for realtime traffic, but that must be payed for somehow): - On congested links, you need (some form of) prioritisation for realtime traffic or the delays (jitter maps to delay in the receiver) become too great. - You probably don't want realtime traffic to exclude none realtime traffic when your realtime traffic exceeds your (backbone) link bandwidth. - Realtime apps cannot usually back off to the same extent as TCP and still remain useful. Thus you're probably talking about realtime and non-realtime being in different traffic classes. Both realtime and non-realtime apps should be adaptive unless you charge for reservations, and probably so even then so you can gain above your reservation when the net is quiet. Realtime and non-realtime should be able to use unused b/w from the other catagory when it's not being used. I'm not talking about any particular service model here - just the basics for "peaceful co-existence". There are many many implementation details that can and will be done differently by different vendors and service providers. Now you say no routers have the horsepower to do this. Fine. So router vendors have to make routers that can do this. I do not believe this is strictly a technical problem - Tony has already said that if they'd foreseen this they'd have ciscos that did this well already. If it doesn't happen soonish, customers will seek other solutions, and if you believe that they'll use (for example) pure ATM for their realtime traffic and IP for their data, you're probably mistaken - if IP network implementations don't do realtime well (and we know that IP itself isn't the problem) then people will make ATM (or whatever) do data sufficiently well. There are already proposals for WWW over ATM (with no IP in between). I happen to believe IP is the better solution for most problems, but rather than complaining about what we can't do right now, we should be making suggestions for where we want to go and how to get there. If ISPs really believe this is fantasy, please tell me and I'll buy ATM shares :-) Can we move the thread onto intserv please. Mark From list-mgr@ISI.EDU Thu Jun 15 03:41:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 10:41:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 10:41:24 -0700 Received: from admin.ogi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 10:41:23 -0700 Received: by admin.ogi.edu (4.1/SMI-4.1) id AA06232; Thu, 15 Jun 95 10:41:20 PDT Date: Thu, 15 Jun 1995 10:41:19 -0700 (PDT) From: Dan Revel Subject: Backbone traffic mixes? To: mbone In-Reply-To: <3748.803174469@munnari.OZ.AU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone have recent data on the mixes of IP backbone traffic? (i.e. %ftp, %http, %multicast, %nntp, %smtp, %tcp, %udp, etc.) Dan Revel Is it tomorrow, or just the end of time? - Jimi Hendrix From list-mgr@ISI.EDU Fri Jun 16 19:54:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 16:59:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 16:58:11 -0700 Received: from munnari.OZ.AU by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 16:58:03 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22687; Fri, 16 Jun 1995 09:57:40 +1000 (from kre@munnari.OZ.AU) To: Sean Doran Cc: mbone Subject: Re: wanna try audio or video stuff? In-Reply-To: Your message of "Wed, 14 Jun 1995 22:32:05 -0400." <95Jun14.223219-0400_edt.20696+6@chops.icp.net> Date: Fri, 16 Jun 1995 09:54:41 +1000 Message-Id: <3860.803260481@munnari.OZ.AU> From: Robert Elz Date: Wed, 14 Jun 1995 22:32:05 -0400 From: Sean Doran Message-ID: <95Jun14.223219-0400_edt.20696+6@chops.icp.net> The problem is that people are inventing new ways of using the Internet all the time, Yes, of course, which is why, in my first message, that you clearly didn't read before criticising, I suggested a couple of possible quite general mechanisms that ISPs could use - that is, could tell their customers was their policy - in order to avoid this. There neither needs to be, nor should be, a "CUSeeMe is prohibited" term in agreements, while that might be the attitude now, a later revision of CUSeeMe might be just fine, or it might be fine if reflectors are set up just right, or something. I can imagine that some ISPs might not want to add seemingly restrictive terms to their contracts - it may place them at a competitive disadvantage to those ISPs that don't, customers may prefer the seeming freedom of the latter. The point is that having given the customer that freedom, by not explicitly indicating that some uses of the internet, which are to all external appearances quite legitimate, are in fact not allowed, then its too late to complain about such usage later. "Do no damage" is insufficient, as to a customer, his usage of these tools isn't damaging, its legitimate. A term in the contract like... From time to time, some internet applications are found which have the potential to upset the smooth operation of our [ISPs] internal network, or the Internet in general. Use of these applications, or similar techniques, in a way that does cause network problems is not permitted. A list or current known problems applications is available upon request, and is updated from time to time. Should you [customer] be found to be causing network problems by the use of any such application we may filter traffic to that application or disconnect you from the network [or whatever you want to be able to do]. At least that way the customer is warned, that seemingly innocent activities can cause problems, and what the repercussions may be - and has a way (by obtaining the current list) to usually avoid encountering the problems. An alternative might be You are authorised to inject into the network only N bits per second on average, averaged over any M minute period. If you exceed that limit, and our network capacity is overloaded, we may drop traffic from your link, or disconnect you [or whatever...] That won't help with the customer on a string causing megabits of data being sent to them, but it would help with those customers with E3's that rudely want to actually use all that bandwidth from time to time. kre From list-mgr@ISI.EDU Thu Jun 15 11:31:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 18:33:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 18:31:10 -0700 Received: from venus.Sun.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 15 Jun 1995 18:31:03 -0700 Received: from Eng.Sun.COM by venus.Sun.COM (Sun.COM) id SAA16872; Thu, 15 Jun 1995 18:30:57 -0700 Received: from jurassic.Eng.Sun.COM (jurassic-248.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18153; Thu, 15 Jun 1995 18:30:53 -0700 Received: from offshore.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id SAA28035; Thu, 15 Jun 1995 18:30:52 -0700 Received: by offshore.Eng.Sun.COM (5.x/SMI-SVR4) id AA14419; Thu, 15 Jun 1995 18:31:33 -0700 Date: Thu, 15 Jun 1995 18:31:33 -0700 From: Allyn.Romanow@Eng.Sun.COM (Allyn Romanow) Message-Id: <9506160131.AA14419@offshore.Eng.Sun.COM> To: mbone Subject: Multicast pruning (mc 3.3/3.4+) available for Solaris 2.4 X-Sun-Charset: US-ASCII Multicast version 3.3 is available for Solaris 2.4. Mrouted 3.4+ is included. You can get the necessary files and instructions via the web ftp://playground.sun.com/pub/multicast/README and Solaris_mc33.2.4.tar.Z or ftp the two files from playground.sun.com/pub/multicast As the README file explains, we plan to replace multicast version 3.3 by multicast version 3.5 soon. Eventually, a current version of multicast will be in the Solaris release, but for the meantime, you will need to install the files. The README file gives installation instructions and other information. From list-mgr@ISI.EDU Fri Jun 16 09:04:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 16 Jun 1995 00:13:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 16 Jun 1995 00:07:43 -0700 Received: from pimac2.iet.unipi.it by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 16 Jun 1995 00:07:38 -0700 Received: by pimac2.iet.unipi.it (5.57/Ultrix3.0-C) id AA24843; Fri, 16 Jun 95 09:07:32 +0200 Message-Id: <9506160707.AA24843@pimac2.iet.unipi.it> X-Sender: stefano@radar.iet.unipi.it Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Jun 1995 09:04:03 +0000 To: MBONE From: giordano@pimac2.iet.unipi.it (Stefano Giordano) Subject: Re: Backbone traffic mixes? X-Mailer: We made some measurements related to the statistical characterization of this traffic mix but over DQDB MAN. We are very interested on this subject too. Probably Klivansky, Mukherjee and Song have collected data over the NSFNET TRaffic. They presented a very interesting paper at the last IEEE 7th Workshop on LAN and MAN in Florida. Best regards Stefano ---------------------------------------------------------------------- X ... X X e-mail giordano@iet.unipi.it (o o) Stefano Giordano X X TEL. +39 50 568539 ... v ... X X FAX +39 50 568522 .. .. University of Pisa X X ..... Department of X X TELECOMMUNICATIONS GROUP **^*^** Information Engineering X X Via Diotisalvi 2 X X TLC NETWORKS 56126 PISA X X ITALY X ---------------------------------------------------------------------- From list-mgr@ISI.EDU Fri Jun 16 07:25:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 16 Jun 1995 08:28:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 16 Jun 1995 08:27:27 -0700 Received: from prom.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 16 Jun 1995 08:27:26 -0700 Received: (dschluss@localhost) by prom.engin.umich.edu (8.6.12/8.6.4) id LAA08325; Fri, 16 Jun 1995 11:26:59 -0400 Date: Fri, 16 Jun 1995 11:25:42 -0400 (EDT) From: "david a. schlussel" Subject: Re: Sparc 5 To: Olli-Pekka Halonen Cc: Dave Wright , mbone In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've been having much trouble with audio on my sparc5 and 4.1.3. supposedly sunOS 4.1.4 will fix the problem +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ On Thu, 15 Jun 1995, Olli-Pekka Halonen wrote: > > On Wed, 14 Jun 1995, Dave Wright wrote: > > > Has anyone tried using a Sparc5 running 4.1.3 not Solaris with a > > VideoPix card to broadcast? > > We have been using videopix with Sun IPX and SparcStation 10 using both > 4.1.3 and 4.1.4. > > They work just swell, i assume you shouldn't encounter any further problems > using this videocard in Sparc5 (thou i can't guarantee it..) > > -- > Okko > Olli-Pekka Halonen, Oulu Institute of Technology, Finland > From list-mgr@ISI.EDU Fri Jun 16 17:43:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 16 Jun 1995 08:46:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 16 Jun 1995 08:44:12 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 16 Jun 1995 08:44:04 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id QAA05827; Fri, 16 Jun 1995 16:43:29 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id QAA02261; Fri, 16 Jun 1995 16:43:26 +0100 Date: Fri, 16 Jun 1995 16:43:26 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: "david a. schlussel" Cc: mbone Subject: Re: Sparc 5 In-Reply-To: Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 16 Jun 1995, david a. schlussel wrote: > I've been having much trouble with audio on my sparc5 and 4.1.3. > supposedly sunOS 4.1.4 will fix the problem The question was not about audio it was about supporting a VideoPix card. There are audio patches for both SunOS 4.1.3_U1 and 4.1.4 to make the audio work on SS5s. They are: 4.1.3_U1: 102161-03 4.4.4: 102387-01 I haven't tried the VideoPix card in an SS5 so I cannot comment on that. Graeme > > On Wed, 14 Jun 1995, Dave Wright wrote: > > > > > Has anyone tried using a Sparc5 running 4.1.3 not Solaris with a > > > VideoPix card to broadcast? > > > > We have been using videopix with Sun IPX and SparcStation 10 using both > > 4.1.3 and 4.1.4. > > > > They work just swell, i assume you shouldn't encounter any further problems > > using this videocard in Sparc5 (thou i can't guarantee it..) > > > > -- > > Okko > > Olli-Pekka Halonen, Oulu Institute of Technology, Finland ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Fri Jun 16 20:50:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 16 Jun 1995 12:54:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 16 Jun 1995 12:54:20 -0700 Received: from sinkhole.unf.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 16 Jun 1995 12:54:18 -0700 Received: from corvair.unf.edu by sinkhole.unf.edu with SMTP id AA25773 (5.65c/IDA-1.4.4 for ); Fri, 16 Jun 1995 15:54:11 -0400 Received: from magpie.cis.unf.edu by corvair.unf.edu (4.0/SMI-4.0) id AA23166; Fri, 16 Jun 95 15:54:08 EDT Received: by magpie.cis.unf.edu (5.0/SMI-SVR4) id AA23442; Fri, 16 Jun 1995 15:50:38 +0500 Date: Fri, 16 Jun 1995 15:50:38 +0500 From: rbutler@magpie.cis.unf.edu (ralph butler) Message-Id: <9506161950.AA23442@magpie.cis.unf.edu> To: mbone Subject: question about new mbone connection Cc: sherk@sura.net, slyon@unf6.cis.unf.edu Content-Length: 2696 At the University of North Florida, we have just begun to receive an mbone feed from SuraNet. We are running mrouted version 2.2 on a Sun with Solaris 2.3; we plan to upgrade to Solaris 2.4 with mrouted 3.4+ within a few weeks. I have a problem which I did not see discussed in any version of the mbone FAQ which I was able to locate. When I start "sd", no sessions are ever reported active. But, when I borrowed a .sd_cache file from a colleague at Argonne, I began to see a list of several cached sessions and was able to open them. Each time I opened one, I would begin to receive a PARTIAL list of the participants. I could watch some participants enter and leave the session, but my colleague at Argonne saw a larger set of participants than I. I have also started mrouted with a debug level > 0, and have been able to watch it exchange information such as follows: SENT route report from 139.62.200.183 to 128.167.208.2 update 126 starting at 629 of 1204 RECV route report from 128.167.208.2 to 139.62.200.183 RECV route report from 128.167.208.2 to 139.62.200.183 RECV route report from 128.167.208.2 to 139.62.200.183 RECV route report from 128.167.208.2 to 139.62.200.183 RECV route report from 128.167.208.2 to 139.62.200.183 RECV route report from 128.167.208.2 to 139.62.200.183 SENT route report from 139.62.200.183 to 128.167.208.2 RECV route report from 128.167.208.2 to 139.62.200.183 RECV route report from 128.167.208.2 to 139.62.200.183 RECV route report from 128.167.208.2 to 139.62.200.183 RECV route report from 128.167.208.2 to 139.62.200.183 SENT route report from 139.62.200.183 to 128.167.208.2 SENT route report from 139.62.200.183 to 128.167.208.2 update 126 starting at 755 of 1204 RECV route report from 128.167.208.2 to 139.62.200.183 SENT route report from 139.62.200.183 to 128.167.208.2 RECV route report from 128.167.208.2 to 139.62.200.183 These facts lead me to believe that perhaps I am receiving some of the mbone feed from SuraNet, but not all of it. But, being a novice to the mbone, I am acutely aware of the fact that it could be some problem on my end which I need to fix. As it is late on a Friday afternoon, I was unable to contact support at SuraNet, so thought to post this note hoping to have some feedback early next week. If you are able to offer some advice it would be greatly appreciated. Please email me directly since I am not a member of this mailing list (maybe I should join?). Thanks for your help. --ralph butler From list-mgr@ISI.EDU Tue Jun 20 12:23:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 01:28:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 01:26:30 -0700 Received: from mail.zrz.TU-Berlin.DE by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 01:26:25 -0700 Received: from mailgzrz.TU-Berlin.DE by mail.zrz.TU-Berlin.DE with SMTP (PP); Tue, 20 Jun 1995 10:26:12 +0200 Received: from ftsu10.ee.TU-Berlin.DE (actually max.ee.TU-Berlin.DE) by mailgzrz.TU-Berlin.DE with SMTP (PP); Tue, 20 Jun 1995 10:25:54 +0200 Received: by ftsu10.ee.TU-Berlin.DE (4.1/ZRZ) id AA00273; Tue, 20 Jun 95 10:23:42 +0200 Date: Tue, 20 Jun 95 10:23:42 +0200 From: Jean-Pierre Ebert Message-Id: <9506200823.AA00273@ftsu10.ee.TU-Berlin.DE > To: mbone, wolisz@dag.uni-sb.de, okp@cs.tu-berlin.de Subject: Wrapped German Reichstag: Christo & Jean-Claude live press conference Announcement: ------------- On June 23, 19:00 -21:00 GMT, we will transmit the press conference of Christo & Jeanne-Claude who are wrapping the German Reichstag. The Wrapped Reichstag art project is an outstanding cultural event for Berlin, Germany and maybe you. The press conference will close the wrapping work and start the exhibition. Used MBone Tools: ----------------- Video: vic (h261 (maybe nv), 128 kbit/s) Audio: nevot (PCM, 64 kbit/s) used TTL 127 Some technical outlines: ------------------------ Because of the very limited network ressources at the conference venue we will use a wireless link (ARLAN radio bridges and directive antennas - WLAN equipment) to be connected to the Technical University of Berlin. The distance is about 3 miles. At Technical Univ. Berlin the data are routed over ATM to GMD FOKUS Berlin, which will broadcast the press conference by MBone. More Information: ----------------- For more information about the Wrapped Reichstag and the Live press conference Mbone transmission (this is under construction) look at http://www.kulturbox.de/christo/reichs_d.htm Regards Jean-Pierre Ebert From list-mgr@ISI.EDU Tue Jun 20 07:06:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 08:07:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 08:06:49 -0700 Received: from LINC.CIS.UPENN.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 08:06:47 -0700 Received: from blue.seas.upenn.edu (mtfinkel@BLUE.SEAS.UPENN.EDU [130.91.5.148]) by linc.cis.upenn.edu (8.6.10/UPenn 1.4) with ESMTP id LAA01055 for ; Tue, 20 Jun 1995 11:06:46 -0400 Received: by blue.seas.upenn.edu id LAA29423; Tue, 20 Jun 1995 11:06:45 -0400 Posted-Date: Tue, 20 Jun 1995 11:06:45 -0400 Message-Id: <199506201506.LAA29423@blue.seas.upenn.edu> Subject: Vat errors To: mbone Date: Tue, 20 Jun 1995 11:06:45 -0400 (EDT) From: "Matthew T. Finkelstein" X-Mailer: ELM [version 2.4 PL23-upenn2.8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 628 Hi, I am trying to isntall vat on a SPARCstation 5 running SunOS 5.4. Everytime I try to start Vat or SD starts vat I get: vat: unknown host 'Org1000-www' Org1000-www is the machine. I have installed the same vat on a similar machine and I do not get any similar errors. NV and sd appear to work fine on the machine, but vat will not start. Any help would be greatly appreciated. Please send any responses to me by email at mtfinke@sandia.gov because I am not on the mbone mailing list at this time. Thanks! -------------------------------- Matthew T. Finkelstein mtfinke@sandia.gov Sandia National Laboratories From list-mgr@ISI.EDU Tue Jun 20 18:26:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 10:26:19 -0700 Received: from professor.brooks.af.mil by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 10:26:18 -0700 Received: from gilligan. by professor.brooks.af.mil (5.0/SMI-SVR4) id AA06306; Tue, 20 Jun 1995 12:26:12 +0600 Received: by gilligan. (5.0/SMI-SVR4) id AA05066; Tue, 20 Jun 1995 12:26:13 +0600 Date: Tue, 20 Jun 1995 12:26:13 +0600 From: strobom@professor.brooks.af.mil (Michael Strobo) Message-Id: <9506201726.AA05066@gilligan.> To: mbone-na Subject: Cisco 7000 (10.2) & and the Mbone X-Sun-Charset: US-ASCII Content-Length: 2213 Hi Everyone, I trying to get MBone smart. After reading everything I can find about the MBone, I still have a couple questions about the Mbone setup. Below is a logical picture of our LAN, showing a Cisco 7000 (10.2) as our gateway router. From what I have read, the Cisco can be used as the WAN tunnel to a Mbone site. And as long as the workstations which need connectivity are connected to the Cisco 7000, the mrouted program is not needed. But if we wanted to set internal tunnels, then we would need to install the mrouted on a machine off of the Cisco7000 and create tunnels form there. Is this a correct? Currently, we have serveral machines running Solaris 2.3 (multicast extentions built-in) and they can operate the SD/VAT/WB between them locally. From what I have read, 2.3 cannot use the mroute 3.5. The mail talks about using the mroute 2.0-2.2 versions for your binaries. If I'm wrong in the above assumptions/interpretation, I can install the mroute 3.5 on one of our SUNOS 4.1.3 machines. If I can use the Cisco 7000, can someone supply an example of how to set this connection up. From what I have read, one wrong typo and you make lots of new (mad) friends from the Mbone. What do you suggest or think is the best config for us? (T-1) All are routing | | (Gateway) __AGS+____ _Cisco 7000_ ___AGS+___ Hub Europe Hub Atlantis Hub Australia Bldg 175 **************Bldg 619 ********Bldg 1185 | / | | / | | / | | / | | / | | ___AGS+/__ | | Hub America | | Bldg 619 | | / | | / | | / | | / | | / | __AGS+___/ ___AGS+___ Hub Africa Hub Asia Bldg 749 **************Bldg 1150 SSgt Strobo Network Operations 70CS Brooks AFB TX (210)536-5148 From list-mgr@ISI.EDU Tue Jun 20 11:18:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 14:19:06 -0700 Received: from noc1.mid.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 14:19:04 -0700 Received: from karn.mid.net (karn.mid.net [198.247.250.22]) by noc1.mid.net (8.6.10/8.6.9) with ESMTP id QAA17202; Tue, 20 Jun 1995 16:19:02 -0500 Received: (from steve@localhost) by karn.mid.net (8.6.10/8.6.9) id QAA02431; Tue, 20 Jun 1995 16:19:01 -0500 Date: Tue, 20 Jun 1995 16:18:56 -0500 (CDT) From: Steve Schallehn To: mbone-na Cc: mbone@mid.net Subject: new feed for MIDnet Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Greetings- I have added another Mbone feed to MIDnet's Mbone server, ace.mid.net (198.247.225.251) from Sprint: # Sprint (Incoming feed) -Steve 95-06-19 # Contact: /Richard Martin tunnel 198.247.225.251 144.228.1.40 metric 1 threshold 64 # National Center for Atmospheric Research, Boulder, CO (Incoming feed) tunnel 198.247.225.251 192.52.106.7 metric 1 threshold 64 Since this is the first time I have a non-tree-like Mbone feeds and MIDnet is on the provider list, I thought I should do my duty to post in case this changes Mbone routing. -Steve Schallehn Network Engineer MIDnet 402-472-0241 From list-mgr@ISI.EDU Tue Jun 20 13:54:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 20:56:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 20:55:18 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 20:55:17 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA03827; Tue, 20 Jun 95 20:54:51 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9506210354.AA03827@taurus.cs.nps.navy.mil> Subject: URL for multicast channels? To: mbone (Multicast Backbone mail list) Date: Tue, 20 Jun 1995 20:54:51 -0700 (PDT) Cc: gavin@sgi.com (Gavin Bell) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 821 Can anyone point me to proposed url syntax for a multicast channel, e.g. (using an .sd_cache excerpt for MBone Audio): n=2147708930 2147708930 803688518 s=MBone Audio i=Audio conference on the default vat multicast address o=van@ee.lbl.gov c=224.2.0.1 191 0 0 m=audio 3456 0 yields something like: mbone://224.2.0.1/3456/audio in other words mbone://[class D address]/[port]/[media] thanks in advance, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv.html From list-mgr@ISI.EDU Tue Jun 20 14:09:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 21:11:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 21:09:44 -0700 Received: from eat.organic.com by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 21:09:42 -0700 Received: (from brian@localhost) by eat.organic.com (8.6.11/8.6.9) id VAA16113; Tue, 20 Jun 1995 21:09:40 -0700 Date: Tue, 20 Jun 1995 21:09:40 -0700 (PDT) From: Brian Behlendorf Subject: Re: URL for multicast channels? To: Don Brutzman Cc: Multicast Backbone mail list , Gavin Bell In-Reply-To: <9506210354.AA03827@taurus.cs.nps.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 20 Jun 1995, Don Brutzman wrote: > Can anyone point me to proposed url syntax for a multicast channel, e.g. > (using an .sd_cache excerpt for MBone Audio): > > n=2147708930 2147708930 803688518 > s=MBone Audio > i=Audio conference on the default vat multicast address > o=van@ee.lbl.gov > c=224.2.0.1 191 0 0 > m=audio 3456 0 > > yields something like: > > mbone://224.2.0.1/3456/audio > > in other words mbone://[class D address]/[port]/[media] It would probably be something more like mbone://[class D address]:[port]/[media] There is also a bit of information that can't really be put into the URL: the time the resource is available. Maybe that's not all that important.... Brian --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/ From list-mgr@ISI.EDU Tue Jun 20 14:27:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 21:36:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 21:26:43 -0700 Received: from valinor.barrnet.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 21:26:42 -0700 Received: (from vaf@localhost) by valinor.barrnet.net (8.6.8/8.6.6) id VAA02980; Tue, 20 Jun 1995 21:27:33 -0700 Date: Tue, 20 Jun 95 21:27:33 PDT From: Vince Fuller To: mbone Phone: (415) 528-7227 Usmail: 3801 East Bayshore Rd, Palo Alto, CA, 94303 Subject: mrinfo with better features? Cc: vaf@valinor.barrnet.net Message-Id: Has anyone modified mrinfo to do either of the following: - add "-n" flag which prevents DNS lookups (which can take a long time) - fix timeout processing so that the program will give up even if it keeps getting "got reply from x.x.x.x instead of y.y.y.y" messages? With the current version, there isn't any way to prevent mrinfo from hanging forever if it keeps getting "got repl from..." messages. This makes it very difficult to use in scripts which recursively walk the MBONE. If there is a better way to recursively walk the MBONE starting at a particular point and limiting recursion to a particular depth, I'd appreciate knowing about that, too. Please send replies directly to me, as I don't believe I am on the "mbone" mailing list. Thanks, --Vince From list-mgr@ISI.EDU Tue Jun 20 15:38:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 22:41:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 22:36:13 -0700 Received: from nexsys.nexsys.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 22:36:12 -0700 Received: by nexsys.nexsys.net (8.6.10/SM-8.6.4) id WAA02909; Tue, 20 Jun 1995 22:38:09 -0700 Date: Tue, 20 Jun 1995 22:38:09 -0700 From: geoffw@nexsys.net (Geoff White) Message-Id: <199506210538.WAA02909@nexsys.nexsys.net> To: brutzman@cs.nps.navy.mil, brian@organic.com Subject: Re: URL for multicast channels? Cc: mbone, gavin@sgi.com > > On Tue, 20 Jun 1995, Don Brutzman wrote: > > Can anyone point me to proposed url syntax for a multicast channel, e.g. > > (using an .sd_cache excerpt for MBone Audio): > > > > n=2147708930 2147708930 803688518 > > s=MBone Audio > > i=Audio conference on the default vat multicast address > > o=van@ee.lbl.gov > > c=224.2.0.1 191 0 0 > > m=audio 3456 0 > > > > yields something like: > > > > mbone://224.2.0.1/3456/audio > > > > in other words mbone://[class D address]/[port]/[media] > > It would probably be something more like > > mbone://[class D address]:[port]/[media] > > There is also a bit of information that can't really be put into the URL: > the time the resource is available. Maybe that's not all that > important.... > > Brian Shouldn't the TTL value be in there somewhere as well? From list-mgr@ISI.EDU Tue Jun 20 16:01:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 23:04:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 23:02:09 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 23:02:08 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA06740; Tue, 20 Jun 95 23:01:10 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9506210601.AA06740@taurus.cs.nps.navy.mil> Subject: Re: URL for multicast channels? To: geoffw@nexsys.net (Geoff White) Date: Tue, 20 Jun 1995 23:01:02 -0700 (PDT) Cc: brutzman@cs.nps.navy.mil, brian@organic.com, mbone, gavin@sgi.com In-Reply-To: <199506210538.WAA02909@nexsys.nexsys.net> from "Geoff White" at Jun 20, 95 10:38:09 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 847 Geoff White writes: > Shouldn't the TTL value be in there somewhere as well? Perhaps. The motivation behind this question is incorporating audio/video streams into Virtual Reality Modeling Language (VRML), the World-Wide Web (WWW) extension for 3D graphics rendering. We foresee pasting video streams as texture maps and also incorporating auditory streams. Of course an 'mbone URL' might be used to launch MBone tools from current WWW browsers as well. However since ttl is defined by the session creator, the ttl value does not appear to be necessary for any other user (or URL) to connect. all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv.html From list-mgr@ISI.EDU Tue Jun 20 16:34:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 23:37:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 23:35:28 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 20 Jun 1995 23:35:26 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id XAA22401; Tue, 20 Jun 1995 23:35:01 -0700 Message-Id: <199506210635.XAA22401@rx7.ee.lbl.gov> To: Vince Fuller Cc: mbone Subject: Re: mrinfo with better features? In-Reply-To: Your message of Tue, 20 Jun 95 21:27:33 PDT. Date: Tue, 20 Jun 95 23:34:59 PDT From: Van Jacobson Vince, You want mrmap, not mrinfo. It does exactly what you want. It will do a tree walk either to a particular depth or up to a ttl limit (ie., a threshhold boundary). It has a -n flag & its timeouts work reliably. Get it from ftp.ee.lbl.gov file mrmap.tar.Z. This contains the source, makefile, manual entry & a sun binary (it builds & runs on SGI's, PMaxes, Alphas & *BSD 486 boxes but I'm too lazy to make up a full suite of binaries so you'll have to type "make" if you don't have a Sun). Mrmap was released about two years ago. I just put out a new version but the only change is to add a printout of each responding mrouter's version number so we can track how long it takes people to move to v3.5. - Van From list-mgr@ISI.EDU Wed Jun 21 12:49:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 02:28:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 01:50:04 -0700 Received: from noc.BelWue.DE by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 01:50:00 -0700 Received: from pi4.informatik.uni-mannheim. (pi4.informatik.uni-mannheim.de) by noc.BelWue.DE with SMTP id AA06544 (5.65c8/IDA-1.4.4 for ); Wed, 21 Jun 1995 10:49:39 +0200 Received: from eratosthenes by pi4.informatik.uni-mannheim.de (5.65/BelWue-1.1DEC) id AA13145; Wed, 21 Jun 95 10:14:48 +0200 From: whd@pi4.informatik.uni-mannheim.de (Wieland Holfelder) Received: by eratosthenes; (5.65/1.1.8.2/02May95-1040AM) id AA30463; Wed, 21 Jun 1995 10:49:29 +0200 Message-Id: <9506210849.AA30463@eratosthenes> Subject: Re: URL for multicast channels? To: brutzman@cs.nps.navy.mil (Don Brutzman) Date: Wed, 21 Jun 1995 10:49:28 +0200 (MET DST) Cc: mbone (Multicast Backbone) In-Reply-To: <9506210601.AA06740@taurus.cs.nps.navy.mil> from "Don Brutzman" at Jun 20, 95 11:01:02 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1195 Don Brutzman writes: > Geoff White writes: > > Shouldn't the TTL value be in there somewhere as well? > Of course an 'mbone URL' might be used to launch MBone tools from > current WWW browsers as well. However since ttl is defined by the session > creator, the ttl value does not appear to be necessary for any other > user (or URL) to connect. Well, I believe it is. If a user connects to an ongoing session she/he should use the same ttl as the sender does in order to allow the sender to receive RTCP messages (e.g. Receiver Reports). Of course a receiver may choose a lower ttl, but then one can't make use of additional features provided by RTP and the sender doesn't see (and know of) these receivers. -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder University of Mannheim Praktische Informatik IV Email: whd@pi4.informatik.uni-mannheim.de L 15,16 Fax : +49-621-292-5745 68131 Mannheim Phone: +49-621-292-5642 Germany http://www.informatik.uni-mannheim.de/~whd ------------------------------------------------------------------------------- From list-mgr@ISI.EDU Wed Jun 21 11:26:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 03:04:03 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 02:26:47 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 02:26:45 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 21 Jun 1995 02:26:44 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 21 Jun 1995 10:26:09 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: brutzman@cs.nps.navy.mil (Don Brutzman) Cc: mbone (Multicast Backbone mail list), gavin@sgi.com (Gavin Bell) Subject: Re: URL for multicast channels? In-Reply-To: Your message of "Tue, 20 Jun 95 20:54:51 PDT." <9506210354.AA03827@taurus.cs.nps.navy.mil> Date: Wed, 21 Jun 95 10:26:05 +0100 Message-Id: <13717.803726765@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >Can anyone point me to proposed url syntax for a multicast channel, e.g. >(using an .sd_cache excerpt for MBone Audio): > >n=2147708930 2147708930 803688518 >s=MBone Audio >i=Audio conference on the default vat multicast address >o=van@ee.lbl.gov >c=224.2.0.1 191 0 0 >m=audio 3456 0 > >yields something like: > >mbone://224.2.0.1/3456/audio > >in other words mbone://[class D address]/[port]/[media] This makes it difficult to collect media streams together into a conference to provide inter-stream synchronisation and so forth. The current syntax is http://server/dir/file (nothing new here :-) and the server should return an SDP message with MIME content type application/x-sd Mark From list-mgr@ISI.EDU Wed Jun 21 11:51:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 03:29:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 02:53:36 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 02:53:36 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 21 Jun 1995 02:53:34 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 21 Jun 1995 10:51:52 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Vince Fuller Cc: mbone Subject: Re: mrinfo with better features? In-Reply-To: Your message of "Tue, 20 Jun 95 21:27:33 PDT." Date: Wed, 21 Jun 95 10:51:49 +0100 Message-Id: <13826.803728309@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >With the current version, there isn't any way to prevent mrinfo from hanging >forever if it keeps getting "got repl from..." messages. This makes it very >difficult to use in scripts which recursively walk the MBONE. Please don't write yet another script to walk to Mbone. Atanu Ghosh and Piete Brookes did this a year or more ago, and the data you want can be got by querying the mwatch server rather than querying the mrouted's themselves. The data should be accurate to within a few minutes. See http://www.cl.cam.ac.uk:80/mbone/#Mrouted Mark From list-mgr@ISI.EDU Wed Jun 21 15:23:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 04:57:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 04:24:03 -0700 Received: from noc.BelWue.DE by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 04:24:00 -0700 Received: from pi4.informatik.uni-mannheim. (pi4.informatik.uni-mannheim.de) by noc.BelWue.DE with SMTP id AA29729 (5.65c8/IDA-1.4.4 for ); Wed, 21 Jun 1995 13:23:33 +0200 Received: from eratosthenes by pi4.informatik.uni-mannheim.de (5.65/BelWue-1.1DEC) id AA13556; Wed, 21 Jun 95 12:48:36 +0200 From: whd@pi4.informatik.uni-mannheim.de (Wieland Holfelder) Received: by eratosthenes; (5.65/1.1.8.2/02May95-1040AM) id AA05874; Wed, 21 Jun 1995 13:23:21 +0200 Message-Id: <9506211123.AA05874@eratosthenes> Subject: Re: URL for multicast channels? To: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Wed, 21 Jun 1995 13:23:21 +0200 (MET DST) Cc: mbone (Multicast Backbone) In-Reply-To: <14021.803730947@cs.ucl.ac.uk> from "Mark Handley" at Jun 21, 95 11:35:47 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 805 Mark Handley writes: > >Well, I believe it is. If a user connects to an ongoing session > >she/he should use the same ttl as the sender does in order to allow > > The receiver can't tell what the sender's ttl was, as each router > decrements the ttl. > Sure, but at least the sender gets the receiver reports after all. -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder University of Mannheim Praktische Informatik IV Email: whd@pi4.informatik.uni-mannheim.de L 15,16 Fax : +49-621-292-5745 68131 Mannheim Phone: +49-621-292-5642 Germany http://www.informatik.uni-mannheim.de/~whd ------------------------------------------------------------------------------- From list-mgr@ISI.EDU Wed Jun 21 11:55:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 06:11:49 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 06:11:13 -0700 Received: from dingo.cc.uq.oz.au by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 06:11:10 -0700 Received: from sutpalme.slip.cc.uq.oz.au by dingo.cc.uq.oz.au with SMTP id AA09254 (5.67a/IDA-1.5 for ); Wed, 21 Jun 1995 21:57:09 +1000 Message-Id: <199506211157.AA09254@dingo.cc.uq.oz.au> X-Sender: sutpalme@dingo.cc.uq.oz.au X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Jun 1995 21:55:10 -1000 To: mbone From: T.Palmer@mailbox.uq.oz.au (Allan Palmer) Subject: Linux & MBONE Hardware Please can anyone tell me which hardware, video & sound cards are compatible with the MBONE tools when running under LINUX on a Pentium based box. Please reply via DIRECT email as my previous attempts to subscribe have failed dismally!! **************************************************************************** ******* ***** Allan Palmer - Brisbane - Australia ***** ***** Lecturer Anaesthesiology & Intensive Care, The University of Queensland ***** ***** T.Palmer@mailbox.uq.oz.au ***** ***** Webmaster: http://www.uq.oz.au/anaesth/home.html ***** **************************************************************************** ******* From list-mgr@ISI.EDU Wed Jun 21 21:46:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 10:48:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 10:46:53 -0700 Received: from concorde.inria.fr by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 10:46:50 -0700 Received: from magoo.inria.fr (magoo.inria.fr [128.93.17.3]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id TAA04783 for ; Wed, 21 Jun 1995 19:46:43 +0200 Received: from localhost.inria.fr (localhost.inria.fr [127.0.0.1]) by magoo.inria.fr (8.6.8/8.6.6) with SMTP id TAA02299 for mbone@ISI.EDU; Wed, 21 Jun 1995 19:46:42 +0200 From: Pierre Leonard Message-Id: <199506211746.TAA02299@magoo.inria.fr> X-Authentication-Warning: magoo.inria.fr: Host localhost.inria.fr didn't use HELO protocol To: mbone Subject: Usage and Quality enhancement in Videoconferencing systems: The TELESIA approach. Date: Wed, 21 Jun 95 19:46:41 +0200 X-Mts: smtp Following is the abstract of a paper concerning the work of the TELESIA team at INRIA on the videoconferencing system TELESIA. The full paper will be soon available at the follwoing URL : http://magoo.inria.fr/pl/telesia-pap1.html Any comments, suggestions, will be studied. Authors: Pierre Lionard, Alain Caristan, Pierre De La Motte, Andrzej Wozniak Abstract During the last years, the TELESIA application, remote-seminar / remote-meeting, was the base of a large number of experimentations. These experimentations, in France and over the world, was the field tests for advanced multimedia services and evaluation and technologies research and developments. The usages are rather different due to the user's needs for a remote-seminar or a remote-meeting. Know-how, expertise exchange is enrich with the telepresence of the speaker: the listeners are free from the information decoding. The technology is crucial for the telepresence, which is the main principle of the teleseminars. Therefore, the audio and the video processing and networking needs to prevent the weakness of the low quality networks: off sequence packets, lost packets, variable transit delays. These paper present the analysis of the major defects encountered during the experiments, the solutions designed and realized, to embrace the objective and subjective quality of the audio the video. Finally we present the analyze of the results trough "in-the-field tests" and campaigns of measures done during December 1994 and May 1995. Pierre Lionard INRIA Rocquencourt Tel Standard +33 (1) 39 63 55 11 B.P. 105 Tel direct +33 (1) 39 63 50 46 78153 Le Chesnay Fax +33 (1) 39 63 51 14 France E-mail: Pierre.Leonard@inria.fr From list-mgr@ISI.EDU Wed Jun 21 07:38:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 14:41:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 14:39:44 -0700 Received: from eitech.eit.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 14:39:42 -0700 Received: from collage (collage.eit.COM) by eitech.eit.com (4.1/SMI-4.1) id AA05322; Wed, 21 Jun 95 14:38:27 PDT Date: Wed, 21 Jun 95 14:38:27 PDT From: vinay@eit.COM (Vinay Kumar) Message-Id: <9506212138.AA05322@eitech.eit.com> To: brutzman@cs.nps.navy.mil, brian@organic.com, M.Handley@cs.ucl.ac.uk Subject: Re: URL for multicast channels? Cc: mbone, gavin@sgi.com, geoffw@nexsys.net > >Can anyone point me to proposed url syntax for a multicast channel, e.g. > >(using an .sd_cache excerpt for MBone Audio): > > > >n=2147708930 2147708930 803688518 > >s=MBone Audio > >i=Audio conference on the default vat multicast address > >o=van@ee.lbl.gov > >c=224.2.0.1 191 0 0 > >m=audio 3456 0 > > > >yields something like: > > > >mbone://224.2.0.1/3456/audio > > > >in other words mbone://[class D address]/[port]/[media] It should not be 'mbone://'. If you are really interested in doing this, then i believe the right thing may look like this (i think !?): wbtp:// (if you are using MBone 'wb' etc..) or, :// > > This makes it difficult to collect media streams together into a > conference to provide inter-stream synchronisation and so forth. > > The current syntax is > > http://server/dir/file > > (nothing new here :-) > > and the server should return an SDP message with MIME content type > application/x-sd > I agree with Mark's comments here, this is probably a good way to follow. An example application that i wrote a while back todo conf. rendezvous with MBone tools using the Web is available at http://www.eit.com/software/mmphone/phoneform.html You may need an external helper application 'wwwphone' in your mailcap file. GET ftp://ftp.eit.com/pub/share/wwwphone.pl Enjoy, --- Vinay Kumar vinay@eit.com From list-mgr@ISI.EDU Wed Jun 21 08:05:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 15:13:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 15:12:23 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 15:12:21 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15220(3)>; Wed, 21 Jun 1995 15:05:58 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Wed, 21 Jun 1995 15:05:45 -0700 X-Mailer: exmh version 1.6 4/21/95 To: brutzman@cs.nps.navy.mil (Don Brutzman) Cc: mbone (Multicast Backbone mail list), gavin@sgi.com (Gavin Bell) Subject: Re: URL for multicast channels? In-Reply-To: Your message of "Tue, 20 Jun 95 20:54:51 PDT." <9506210354.AA03827@taurus.cs.nps.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jun 1995 15:05:31 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun21.150545pdt.49859@crevenia.parc.xerox.com> In message <9506210354.AA03827@taurus.cs.nps.navy.mil> you write: >Can anyone point me to proposed url syntax for a multicast channel I don't think encoding this information in URL's makes sense. It makes much more sense to return SDP descriptions as MIME types, as in http://www.cmf.nrl.navy.mil/sd/ . The only other option I can think of is to encode all the SDP information into the URL, like x-sdp:c=224.2.0.1%20191%200%200%0Dm=audio%203456%200 (eliminating some required fields under the assumption that whatever web page contains this reference will also contain things like session description and contact information). Given how ugly that URL syntax is, I am much more inclined to just ship arround application/x-sd MIME payloads. Bill From list-mgr@ISI.EDU Wed Jun 21 08:18:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 15:21:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 15:19:16 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 15:19:15 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15166(1)>; Wed, 21 Jun 1995 15:18:58 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Wed, 21 Jun 1995 15:18:47 -0700 X-Mailer: exmh version 1.6 4/21/95 To: Vince Fuller Cc: mbone Subject: Re: mrinfo with better features? In-Reply-To: Your message of "Tue, 20 Jun 95 21:27:33 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jun 1995 15:18:37 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun21.151847pdt.49859@crevenia.parc.xerox.com> In message you write: > - add "-n" flag which prevents DNS lookups (which can take a long time) This is in 3.5 . > - fix timeout processing so that the program will give up even if it > keeps getting "got reply from x.x.x.x instead of y.y.y.y" messages? This only occurrs if you are running on a multicast router. I have a possibly-fixed version that you can try if you like. >This makes it very difficult to use in scripts which recursively walk the >MBONE. There are at least three existing mbone walkers. map-mbone is included in the mrouted distribution. mrmap is available from ftp.ee.lbl.gov . There is a daemon running at mwatch.cs.ucl.ac.uk (among others) that constantly walks the mbone and makes its database available. Bill From list-mgr@ISI.EDU Wed Jun 21 11:51:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 18:57:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 18:51:11 -0700 Received: from decu13.triumf.ca ([142.90.100.8]) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 18:51:09 -0700 Received: by decu13.triumf.ca (5.65/DEC-Ultrix/4.3) id AA28558; Wed, 21 Jun 1995 18:49:58 -0700 Date: Wed, 21 Jun 1995 18:51:40 -0700 (PDT) From: Andrew Daviel To: mbone Subject: mbone tools with NCDAudio ?? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I wondered if anyone had written a socket program to use the mbone audio tools such as vat with an NCD audio terminal. I know the local network load is much greater, but we tend to have servers and many X-terminals, rather than audio-capable workstations. Andrew Daviel email: advax@triumf.ca TRIUMF voice: 604-222-7376 4004 Wesbrook Mall fax: 604-222-7307 Vancouver BC http://andrew.triumf.ca/~andrew Canada V6T 2A3 49D14.7N 123D13.6W From list-mgr@ISI.EDU Thu Jun 22 22:08:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 19:13:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 19:09:32 -0700 Received: from jello.qabc.uq.oz.au by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 19:09:23 -0700 Received: (from jason@localhost) by jello.qabc.uq.oz.au (8.6.10/8.6.6) id MAA06220 for mbone@ISI.EDU; Thu, 22 Jun 1995 12:08:09 +1000 From: jason andrade Message-Id: <199506220208.MAA06220@jello.qabc.uq.oz.au> Subject: Re: mbone tools with NCDAudio ?? To: mbone Date: Thu, 22 Jun 1995 12:08:08 +1000 (EST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1341 > > I wondered if anyone had written a socket program to use the mbone audio > tools such as vat with an NCD audio terminal. I know the local network > load is much greater, but we tend to have servers and many X-terminals, > rather than audio-capable workstations. > > Andrew Daviel email: advax@triumf.ca > TRIUMF voice: 604-222-7376 > 4004 Wesbrook Mall fax: 604-222-7307 > Vancouver BC http://andrew.triumf.ca/~andrew > Canada V6T 2A3 49D14.7N 123D13.6W > We have NCD MCX Xterminals w/ built in audio etc here. One of our people (frank@dstc.edu.au) tried getting vat to work with it and basically, you can't, as far as i can tell. (i've exchanged some mail with van/frank/mbone people about NCD's audio stuff back when i was desperate to get the audio working [because i had an NCD on my desk, but i don't anymore :-]). Frank (being the crazy fool that he is (and also having an NCD on his desk for a while..) started playing with NeVot and sort of got that working for listening, but not really for sending. You can try following up questions to him about nevot and ncd's, but i think whatever work frank did has been (maybe) taken up by stephen hocking now.. (can't remember his email). g'luck with getting audio working. we really tried for a while :-/ -jason jason@dstc.edu.au From list-mgr@ISI.EDU Wed Jun 21 17:40:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 00:47:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 00:41:01 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 00:40:59 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA26030; Thu, 22 Jun 95 00:40:29 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9506220740.AA26030@taurus.cs.nps.navy.mil> Subject: Re: URL for multicast channels? To: fenner@parc.xerox.com (Bill Fenner) Date: Thu, 22 Jun 1995 00:40:29 -0700 (PDT) Cc: mbone (Multicast Backbone mail list), gavin@sgi.com (Gavin Bell), brian@organic.com (Brian Behlendorf) In-Reply-To: <95Jun21.150545pdt.49859@crevenia.parc.xerox.com> from "Bill Fenner" at Jun 21, 95 03:05:31 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2383 Bill Fenner writes: > In message <9506210354.AA03827@taurus.cs.nps.navy.mil> you write: > >Can anyone point me to proposed url syntax for a multicast channel > > I don't think encoding this information in URL's makes sense. It makes much > more sense to return SDP descriptions as MIME types, as in > http://www.cmf.nrl.navy.mil/sd/ . Doesn't the above construct imply that the multicast stream at the remote is reflected back as unicast from www.cmf.nrl.navy.mil, or is it just that the SDP data in ..../sd/.sd_cache is returned? The original motivation assumed that the browser attempting to connect to the multicast stream has MBone connectivity and lies within ttl reachability. Duplication of streams as seen by a remote host is not desired. (Please correct any misconceptions above. I assume SDP = sd protocol, ref. ) ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sdp-00.txt >The only other option I can think of is to encode all the SDP information into > the URL, like > > x-sdp:c=224.2.0.1%20191%200%200%0Dm=audio%203456%200 > > (eliminating some required fields under the assumption that whatever web page > contains this reference will also contain things like session description and > contact information). Given how ugly that URL syntax is, I am much more > inclined to just ship arround application/x-sd MIME payloads. Well I certainly agree with ugly in this case! :) A big strength of most URL's is that they can be repeated by a human. Thus any x-mbonep URL format ought to be writeable by a person looking at an sd information window. The above example syntax is probably too error-prone. On the other hand there are many options in the sdp draft, and it probably doesn't make sense to oversimplify things now when other fields might be very important later... I think we do need some type of URL that is extensible but there is not agreement yet on this point. A key characteristic seems to be that the process is not (necessarily) connecting to a remote server, but it is connecting to a locally available multicast address & port. Further comments anyone? all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv.html From list-mgr@ISI.EDU Thu Jun 22 12:12:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 03:36:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 03:30:25 -0700 Received: from mail.zrz.TU-Berlin.DE by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 03:29:07 -0700 Received: from mailgzrz.TU-Berlin.DE by mail.zrz.TU-Berlin.DE with SMTP (PP); Thu, 22 Jun 1995 10:14:45 +0200 Received: from ftsu10.ee.TU-Berlin.DE (actually max.ee.TU-Berlin.DE) by mailgzrz.TU-Berlin.DE with SMTP (PP); Thu, 22 Jun 1995 10:14:30 +0200 Received: by ftsu10.ee.TU-Berlin.DE (4.1/ZRZ) id AA03099; Thu, 22 Jun 95 10:12:06 +0200 Date: Thu, 22 Jun 95 10:12:06 +0200 From: Jean-Pierre Ebert Message-Id: <9506220812.AA03099@ftsu10.ee.TU-Berlin.DE > To: mbone Subject: Additional Infromations: Wrapped German Reichstag: .... For all, which aren't using the sd-tool some additional information here: multicast address: 224.2.240.70 ttl: 127 Media: audio@38170/46026 (Nevot 3.29 - vat protocol, pcm 64KB/s) video@55070/38179 (vic, nv 128 Kbit/s) time: 19-21:00 GMT Bye Jean-Pierre Ebert ------------------------------------------------------------------------------ Technical University of Berlin Tel.: ++49 (030) 314-23833 Sekr. FT 5/Institute of Telecommunication Fax.: ++49 (030) 314-22514 Einsteinufer 25, 10587 Berlin ebert@ftsu00.ee.TU-Berlin.DE From list-mgr@ISI.EDU Thu Jun 22 16:44:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 03:49:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 03:49:09 -0700 Received: from nemesis.ics.forth.gr (nemesis.csi.forth.gr) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 03:46:11 -0700 Received: from medea.csi.forth.gr by nemesis.ics.forth.gr (ICS mailhost); on Thu, 22 Jun 1995 13:44:42 +0300 (EET DST); with id AA27232 Date: Thu, 22 Jun 1995 13:44:42 +0300 From: Vidalis Antonis Received: by medea.csi.forth.gr (4.1/SMI-4.1) id AA07050; Thu, 22 Jun 95 13:46:50 +0300 Message-Id: <9506221046.AA07050@medea.csi.forth.gr> Organization: FORTH - ICS, P.O.Box 1385, Heraklio, Crete, Greece 711 10 tel: +30(81)221171, 229368,02 fax: +30(81)229342,3 tlx: 262389 CCI To: mbone Subject: .sd.tcl Wanted Cc: vidalis@ics.forth.gr Hello Mbone, Does anybody have a complete .sd.tcl file with vat, wb, nv, vic, ivs (and other mbone tools) entries? I would grateful if he could send it to me.. Thanks in advance. Antonis Vidalis vidalis@csi.forth.gr From list-mgr@ISI.EDU Thu Jun 22 06:38:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 07:41:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 07:40:46 -0700 Received: from aotearoa (aotearoa.sura.net) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 07:40:45 -0700 Received: from localhost.sura.net by aotearoa with SMTP (8.6.12/($Id: sendmail.cf,v 1.17 1991/02/11 14:07:23 jmalcolm Exp $)) id KAA02037; Thu, 22 Jun 1995 10:38:50 -0400 Message-Id: <199506221438.KAA02037@aotearoa> To: mbone Cc: rbutler@magpie.cis.unf.edu Subject: Simplex mbone connection Date: Thu, 22 Jun 1995 10:38:49 -0400 From: Erik Sherk Hi, A site of ours is trying to get connected to the mbone. He can see me in the Mbone audio group, but I can't see him. Ralph tried a test and Atanu Ghosh of UCL said that he could hear him, and I saw Atanu respond on mbone audio, but didn't hear him. (But, then again I have a Sparc5 :-) Any one have any ideas? Can anyone see Ralph rbutler@magpie.cis.unf.edu AOTEAROA.SURA.NET 127 # mrinfo 128.167.208.2 128.167.208.2 (jkv2-jkv1-pe.sura.net) [version 1.0]: 128.167.208.2 -> 128.167.196.29 (atu-mp1.sura.net) [1/32/tunnel/down] 128.167.208.2 -> 130.207.244.27 (houdini-fddi.gatech.edu) [1/32/tunnel] 128.167.208.2 -> 137.237.1.90 (it.corp.harris.com) [1/32/tunnel] 128.167.208.2 -> 128.227.100.65 (comlab1.ee.ufl.edu) [1/32/tunnel/down] 128.167.208.2 -> 139.62.200.183 (magpie.cis.unf.edu) [1/32/tunnel] 128.167.208.2 -> 224.0.0.4 (DVMRP.MCAST.NET) [1/1/querier] AOTEAROA.SURA.NET 128 # mrinfo 139.62.200.183 139.62.200.183 (magpie.cis.unf.edu) [version 2.2]: 139.62.200.183 -> 0.0.0.0 (?) [1/32/querier] 139.62.200.183 -> 128.167.208.2 (jkv2-jkv1-pe.sura.net) [1/32/tunnel] 139.62.200.183 -> 192.221.6.242 (?) [1/32/tunnel/down] Thanks... Erik From list-mgr@ISI.EDU Thu Jun 22 16:50:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 07:52:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 07:51:33 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 07:51:01 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id PAA14962; Thu, 22 Jun 1995 15:50:58 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id PAA06185; Thu, 22 Jun 1995 15:50:56 +0100 Date: Thu, 22 Jun 1995 15:50:55 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Erik Sherk Cc: mbone Subject: Re: Simplex mbone connection In-Reply-To: <199506221438.KAA02037@aotearoa> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 22 Jun 1995, Erik Sherk wrote: > Hi, > A site of ours is trying to get connected to the mbone. He > can see me in the Mbone audio group, but I can't see him. Ralph tried > a test and Atanu Ghosh of UCL said that he could hear him, and I saw > Atanu respond on mbone audio, but didn't hear him. (But, then again > I have a Sparc5 :-) Any one have any ideas? Can anyone see Ralph Yes I can see both of you and have received audio from both. Have you applied all the audio patches? Have you checked that another program is not locking your audio device (you should be able to tell if vat has control by looking at the version number text at the bottom of the window - if it is in italics then vat does not have control of the audio device). ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Thu Jun 22 02:09:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 09:15:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 09:13:16 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 09:13:14 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14479(6)>; Thu, 22 Jun 1995 09:09:20 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Thu, 22 Jun 1995 09:09:15 -0700 To: brutzman@cs.nps.navy.mil (Don Brutzman) Cc: mbone (Multicast Backbone mail list), gavin@sgi.com (Gavin Bell), brian@organic.com (Brian Behlendorf) Subject: Re: URL for multicast channels? In-Reply-To: Your message of "Thu, 22 Jun 95 00:40:29 PDT." <9506220740.AA26030@taurus.cs.nps.navy.mil> Date: Thu, 22 Jun 1995 09:09:01 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun22.090915pdt.49859@crevenia.parc.xerox.com> In message <9506220740.AA26030@taurus.cs.nps.navy.mil> you write: >Bill Fenner writes: >> http://www.cmf.nrl.navy.mil/sd/ . > >Doesn't the above construct imply that the multicast stream at the remote is >reflected back as unicast from www.cmf.nrl.navy.mil, No, it implies that you use HTTP to get the document from www.cmf.nrl.navy.mil. Perhaps I should have said "like http://www.cmf.nrl.navy.mil/sd/128.3.112.2_224.2.0.1_03E3.sd". When the web browser gets the application/x-sd MIME type, it runs sd-launch and launches the MBONE apps. >The original motivation >assumed that the browser attempting to connect to the multicast stream has >MBone connectivity and lies within ttl reachability. How do you restrict the availability of the URL only to those within the TTL scope of the stream? >A big strength of most >URL's is that they can be repeated by a human. It's true that the %20 and %0D's from that URL could be replaced by making more ASCII characters "special", perhaps slashes since URL folks are used to them: x-sdp:c=224.2.0.1,191/m=audio,3456 I hesitate to "simplify" it further than that. Remember, there could also be sessions like x-sdp:c=224.2.157.32,127/m=audio,3456/a=fmt:idvi/m=video,35867/a=fmt:vic/c=224.2.167.58,64/m=whiteboard,47285/a=readonly/a=seascape Not to mention things like the repeat times probably belong in this info, since you might be launching a session recording tool from the web or something similar... I would much rather try to remember (or type in!) http://www.somehost.com/the/conference/launch.sd Bill From list-mgr@ISI.EDU Thu Jun 22 11:18:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 12:29:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 12:27:43 -0700 Received: from maelstrom.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 12:27:41 -0700 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.6.10/8.6.6) id PAA00697 for mbone@isi.edu; Thu, 22 Jun 1995 15:18:28 -0400 Message-Id: <199506221918.PAA00697@maelstrom.cc.mcgill.ca> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Yves Lepage Date: Thu, 22 Jun 95 15:18:26 -0400 To: mbone Subject: Tiny problem Reply-To: yves@cc.mcgill.ca Hello, I have recently configured a machine that we will be using as a dedicated MBONE router. Now the problem with this machine is that it doesn't forward the mcast traffic it receives to tunnels or phyint's... It is very strange because mrouted works fine (?). mrinfo also works fine and shows me all the tunnels that are up. The tests I have done are: Setup: machine A running mrouted 2.2 (solaris 2.4) machine B running mrouted 3.3 (FreeBSD 2.0) machine A and B are on the same physical net. target A tunneled to machine A target B tunneled to machine B target C tunneled to machine B target D tunneled to machine A Test 1: create a session from target A. Results: Targets B and C cannot see it. Target D can see it. Test 2: create a session from target B Results: Targets A,C,D cannot see the session. What could the problem be? Here I assume that 3.3 is sane and clean. I also assume my net interface/driver is clean since mrouted and mrinfo run fine. We checked and re-checked all ttl's, thresholds, and all the other basic stuff. I need help. Thanks in advance. Yves Lepage yves@cc.mcgill.ca From list-mgr@ISI.EDU Fri Jun 23 16:26:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 23 Jun 1995 03:24:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 23 Jun 1995 03:23:41 -0700 Received: from cs.tut.fi by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 23 Jun 1995 03:21:36 -0700 Received: from isosotka.cs.tut.fi (mit@isosotka.cs.tut.fi [130.230.17.14]) by cs.tut.fi (8.6.12/8.6.4) with ESMTP id NAA23846 for ; Fri, 23 Jun 1995 13:23:04 +0300 From: Tsokkinen Mikko Received: (mit@localhost) by isosotka.cs.tut.fi (8.6.10/8.6.4) id NAA11020; Fri, 23 Jun 1995 13:26:32 +0300 Date: Fri, 23 Jun 1995 13:26:32 +0300 Message-Id: <199506231026.NAA11020@isosotka.cs.tut.fi> To: mbone Subject: Re: mrinfo with better features? In-Reply-To: <199506210635.XAA22401@rx7.ee.lbl.gov> References: <199506210635.XAA22401@rx7.ee.lbl.gov> Van Jacobson writes: > You want mrmap, not mrinfo. It does exactly what you want. > It will do a tree walk either to a particular depth or up > to a ttl limit (ie., a threshhold boundary). It has a -n > flag & its timeouts work reliably. Get it from ftp.ee.lbl.gov > file mrmap.tar.Z. This contains the source, makefile, manual > entry & a sun binary (it builds & runs on SGI's, PMaxes, Alphas > & *BSD 486 boxes but I'm too lazy to make up a full suite of > binaries so you'll have to type "make" if you don't have a Sun). Has anyone considering writing an SNMP agent for mbone mrouted workstations based on tools like this? This would mean a lot for the service, manager traps and reports could be integrated into regular network administrating tasks. If anyone has implemented this I would be very happy to hear about it. Mikko I. Tsokkinen xxxxx Mit R&D Engineer Multimedia Services Telecom Finland From list-mgr@ISI.EDU Fri Jun 23 06:45:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 23 Jun 1995 06:51:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 23 Jun 1995 06:45:18 -0700 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 23 Jun 1995 06:45:17 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.6.12/8.6.12) id JAA23203; Fri, 23 Jun 1995 09:45:32 -0400 Date: Fri, 23 Jun 1995 09:40:16 From: "Dave Thaler" Subject: mrinfo with better features? Message-Id: <19950623094016.29534@dip.eecs.umich.edu> To: mbone In-Reply-To: <> from "Tsokkinen Mikko" at Fri, Jun 23, 1995 (07:51) Tsokkinen Mikko writes: [excerpt from Van Jacobson about mrmap deleted] > > Has anyone considering writing an SNMP agent for mbone mrouted > workstations based on tools like this? > > This would mean a lot for the service, manager traps and reports could > be integrated into regular network administrating tasks. > > If anyone has implemented this I would be very happy to hear about it. > > Mikko I. Tsokkinen xxxxx Mit > R&D Engineer Multimedia Services > Telecom Finland SNMP support for the multicast and DVMRP mibs is bundled with mrouted3.5. We (at Merit) are working on improving this and writing applications that make use of the information. The next release should be a big improvement and include the IGMP mib as well. Dave From list-mgr@ISI.EDU Wed Jun 24 16:56:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 24 Jun 1995 10:07:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 24 Jun 1995 10:05:52 -0700 Received: from flop.mcom.com by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 24 Jun 1995 10:05:50 -0700 Received: (from news@localhost) by flop.mcom.com (8.6.9/8.6.9) id JAA01552; Sat, 24 Jun 1995 09:56:21 -0700 To: mbone Path: neon.netscape.com!dmose From: dmose@neon.netscape.com (Dan Mosedale) Newsgroups: mcom.list.mbone Subject: Re: URL for multicast channels? Date: 24 Jun 1995 16:56:19 GMT Organization: Netscape Communications Corporation Lines: 22 Message-Id: <3shg3j$1ge@flop.mcom.com> References: <9506212138.AA05322@eitech.eit.com> Nntp-Posting-Host: neon.netscape.com vinay@eit.COM (Vinay Kumar) writes: > > It should not be 'mbone://'. This I agree with, but for a different reason: sdp packets are a useful format for announcing things which are (at least currently) integrated into the MBONE (eg CUSeeMe, RealAudio, etc). sdp: might be a good choice. > If you are really interested in doing > this, then i believe the right thing may look like this (i think !?): > wbtp:// (if you are using MBone 'wb' etc..) > or, > :// The problem with doing this is that every time someone invents a new protocol, you need to create another first-class URL type in your browser. And if you don't have the source, chances are that you're SOL. -- Dan Mosedale Systems Exorcist dmose@netscape.com Netscape Communications Corp. From list-mgr@ISI.EDU Wed Jun 24 17:22:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 24 Jun 1995 10:33:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 24 Jun 1995 10:31:58 -0700 Received: from flop.mcom.com by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 24 Jun 1995 10:31:57 -0700 Received: (from news@localhost) by flop.mcom.com (8.6.9/8.6.9) id KAA02235; Sat, 24 Jun 1995 10:22:31 -0700 To: mbone Path: neon.netscape.com!dmose From: dmose@neon.netscape.com (Dan Mosedale) Newsgroups: mcom.list.mbone Subject: Re: URL for multicast channels? Date: 24 Jun 1995 17:22:30 GMT Organization: Netscape Communications Corporation Lines: 42 Message-Id: <3shhkm$25p@flop.mcom.com> References: <9506220740.AA26030@taurus.cs.nps.navy.mil> <95Jun22.090915pdt.49859@crevenia.parc.xerox.com> Nntp-Posting-Host: neon.netscape.com fenner@parc.xerox.com (Bill Fenner) writes: > In message <9506220740.AA26030@taurus.cs.nps.navy.mil> you write: > > No, it implies that you use HTTP to get the document from > www.cmf.nrl.navy.mil. Perhaps I should have said "like > http://www.cmf.nrl.navy.mil/sd/128.3.112.2_224.2.0.1_03E3.sd". When the > web browser gets the application/x-sd MIME type, it runs sd-launch and > launches the MBONE apps. A problem with the current semantics of application/x-sd is that if someone sends out a multipart mail or news message talking about an upcoming event, what do you do with the x-sd chunk of it? Most people will initially want to view the information formatted in a nice way before they try and launch it (if they actually want to launch it at all). I'd suggest either changing the default semantics of x-sd to be "display the info along with a button to launch", or using x-sd to simply provide the info for formatting as a browser sees fit, and then having URLs for launching. > >A big strength of most > >URL's is that they can be repeated by a human. As Bill pointed out, some large percentage of the sdp URLs will be too long for this to be a real big win. Generally, no matter what gets chosen, there will be way too many punctuation characters for most sdp URLs to be very memorable. > It's true that the %20 and %0D's from that URL could be replaced by making > more ASCII characters "special", perhaps slashes since URL folks are used > to them: > > x-sdp:c=224.2.0.1,191/m=audio,3456 > One nice feature about leaving the % escapes in place is that one can then call the "unescape URL" function built into most browsers and then use the exact same parsing code on .sd_cache files, x-sd documents, and sdp: URLs. -- Dan Mosedale Systems Exorcist dmose@netscape.com Netscape Communications Corp. From list-mgr@ISI.EDU Sun Jun 25 14:38:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 25 Jun 1995 21:41:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 25 Jun 1995 21:39:04 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 25 Jun 1995 21:39:02 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <17112(4)>; Sun, 25 Jun 1995 21:38:51 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49859>; Sun, 25 Jun 1995 21:38:45 -0700 To: dmose@neon.netscape.com (Dan Mosedale) Cc: mbone Subject: Re: URL for multicast channels? In-Reply-To: Your message of "Sat, 24 Jun 95 10:22:30 PDT." <3shhkm$25p@flop.mcom.com> Date: Sun, 25 Jun 1995 21:38:35 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun25.213845pdt.49859@crevenia.parc.xerox.com> In message <3shhkm$25p@flop.mcom.com> you write: >I'd suggest either changing the default semantics of x-sd to be >"display the info along with a button to launch", or using x-sd to >simply provide the info for formatting as a browser sees fit, and then >having URLs for launching. That's a reasonable idea. I had assumed that sdp stuff passed around by email would come with an explanation, and metamail's "Would you like to view this data using sd-launch?" would be a sufficient question. >One nice feature about leaving the % escapes in place is that one can >then call the "unescape URL" function... Yeah, that's why I proposed it first even though I knew that people were going to say it was too ugly. Bill From list-mgr@ISI.EDU Mon Jun 26 00:50:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 26 Jun 1995 07:52:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 26 Jun 1995 07:50:12 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 26 Jun 1995 07:50:11 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id HAA27661; Mon, 26 Jun 1995 07:50:39 -0700 Message-Id: <199506261450.HAA27661@rx7.ee.lbl.gov> To: atlas@sunatlasconf.cern.ch Cc: mbone Subject: sunatlasconf.cern.ch sending 300kb/s nv video Date: Mon, 26 Jun 95 07:50:38 PDT From: Van Jacobson User atlas@sunatlasconf.cern.ch (128.141.202.6) is sending 300kb/s of a motionless drawing to 224.2.164.214/23621 at ttl 127. Near as I can tell, there was never an announcement of this session and it is completely trashing the United Nation's 50th anniversary session and the EPA International Environmental Visualization conference, both of which were scheduled for this time. Perhaps CERN could lower its ttl to something more appropriate (<64) and/or lower its bandwidth to something more civilized (<64Kb/s). Thanks. - Van Jacobson From list-mgr@ISI.EDU Mon Jun 26 08:51:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 26 Jun 1995 15:55:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 26 Jun 1995 15:54:09 -0700 Received: from hill.msri.org (msri.org) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 26 Jun 1995 15:54:08 -0700 Received: from alex.msri.org by hill.msri.org (8.6.10/MSRI) id PAA26235; Mon, 26 Jun 1995 15:54:07 -0700 From: Dave Wright Received: by alex.msri.org (8.6.10/MSRI) id SAA15934; Mon, 26 Jun 1995 18:51:17 -0400 Message-Id: <199506262251.SAA15934@alex.msri.org> Subject: MBone Schedules in tables To: mbone Date: Mon, 26 Jun 1995 15:51:17 -0700 (PDT) Cc: dave@msri.org (6070) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 861 I have created an MBone Schedule in HTML that uses tables to display the schedule. I put in a few entries, so you can get the idea. The list is completely automated except for cancelations. All the tables and hyper-links are generated on input of a new event. The tables are useful for quickly identifying days that have more than one event scheduled, as well as months that have many events. The tables and link in tables will work with Netscape1.1N or any other web browser that supports tables and links in tables. There is also a non-tables version available. Any comments or suggestions at all are very welcomed. The URL is http://www.msri.org/mbone Thanks ________ o Dave Wright _______ _/\_> dave@msri.org _______O=>// O 91CBR1000F 91CBR600F2 87EX500 AFM# 316 -------------- Mathematical Sciences Research Institute From list-mgr@ISI.EDU Mon Jun 26 11:36:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 26 Jun 1995 18:37:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 26 Jun 1995 18:37:03 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 26 Jun 1995 18:37:02 -0700 Received: from gratiano.parc.xerox.com ([13.2.116.55]) by alpha.xerox.com with SMTP id <16987(2)>; Mon, 26 Jun 1995 18:36:58 PDT Received: by gratiano.parc.xerox.com id <177863>; Mon, 26 Jun 1995 18:36:48 -0700 From: Bill Fenner To: mbone Subject: Announcing the 3.6 mrouted-only release, and the 3.5June kernel release Message-Id: <95Jun26.183648pdt.177863@gratiano.parc.xerox.com> Date: Mon, 26 Jun 1995 18:36:47 PDT As always ends up happening, there were bugs in the 3.5 multicast code that I released in May. This is to announce a bugfix release of mrouted, as well as some kernel bug fixes. The 3.5June kernel release includes working if_bqe.o files, as well as some .o's with some requested sun patches applied, and a resource depletion fix for ip_mroute.c . The files required to upgrade from the original 3.5 kernel release are available from ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/3.5june-upgrade.tar.Z You do not need to upgrade if you don't want the sun patches or the quad ethernet patches, and if you aren't having mbuf usage problems. The "standard" 3.5 release in ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/ipmulti3.5-sunos41x.tar.Z has been upgraded to include these files as well, so if you were waiting for the sun patches to install, now is the time to install. The 3.6 mrouted runs over a 3.5 kernel. SunOS binaries are available from ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.6-sparc-sunos41x.tar.Z and the source code is available from ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.6.tar.Z You are strongly encouraged to upgrade to 3.6, as it had some multicast traceroute bugs that could hang or kill mrouted. Since there is no kernel upgrade required, upgrading to 3.6 is as simple as ftp'ing the binaries or building the source, killing mrouted and restarting the new one. As always, please let me know of any troubles you might have. Bill From list-mgr@ISI.EDU Tue Jun 27 07:41:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 10:21:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 10:19:10 -0700 Received: from access1.digex.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 10:19:04 -0700 Received: from houston_cc_smtp.hai-net.com (houston_cc_smtp.hai-net.com [204.91.94.67]) by access1.digex.net (8.6.12/8.6.12) with SMTP id NAA09026 ; for ; Tue, 27 Jun 1995 13:19:03 -0400 From: rsingleton@hai-net.com Received: from cc:Mail by houston_cc_smtp.hai-net.com id AA804284699; Tue, 27 Jun 95 12:41:40 EST Date: Tue, 27 Jun 95 12:41:40 EST Message-Id: <9505278042.AA804284699@houston_cc_smtp.hai-net.com> To: MBONE Subject: Reflector setup Hi everyone, I was wondering if anyone has set up a reflector on an SGI extreme running Irix 5.2. This is my first time trying to setup this function so if anyone has any pointers I would certainly appreciate it. thx Rickie From list-mgr@ISI.EDU Tue Jun 27 04:30:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 11:31:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 11:30:44 -0700 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 11:30:44 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA12872 (5.65c/IDA-1.4.4nsd for ); Tue, 27 Jun 1995 11:30:39 -0700 Received: by jaspar.NSD.3Com.COM id AA07720 (5.65c/IDA-1.4.4-910730 for mbone@isi.edu); Tue, 27 Jun 1995 11:30:37 -0700 From: "Cyndi M. Jung" Message-Id: <199506271830.AA07720@jaspar.NSD.3Com.COM> Subject: multicast applications - non-MBONE To: mbone Date: Tue, 27 Jun 1995 11:30:36 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 475 Hi, I'm setting up a lab to test multicast IP, and am not having such an easy time finding applications, other than the MBONE applications. I want to do this is isolation of the MBONE, for various reasons, including the safety of the MBONE :-) I've heard there is a version of "maze wars" that runs on a SUN and can use multicast - is this pure rumor, and if not, where can I get it? Any other "simple" applications would be great. Thanks, Cyndi Jung 3Com Corporation From list-mgr@ISI.EDU Tue Jun 27 12:00:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 13:00:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 13:00:19 -0700 Received: from MAYTAG.GRAPHICS.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 13:00:18 -0700 Received: from localhost by maytag.graphics.cornell.edu; (5.65/1.1.8.2/07Nov94-0649PM) id AA10549; Tue, 27 Jun 1995 16:00:48 -0400 Message-Id: <9506272000.AA10549@maytag.graphics.cornell.edu> X-Mailer: exmh version 1.6gamma 3/31/95 To: mbone Subject: MBone negative loss Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Jun 95 16:00:46 -0400 From: Mitch Collinsworth X-Mts: smtp Watching the shuttle launch, nv is reporting negative loss rates as high (low?) as -75%. Seems to vary significantly. Sometimes it's near zero or even positive, then it swings to large negatives again. I would have guessed this to mean that a mis-configuration somewhere is causing packets to be duplicated, yet strangely, vat is not reporting any duplicates. But it does show a significant number of misordered packets. Is vat logging duplicates as misordered? What is causing vat's negative loss? (On the other hand reception is excellent! :-) -Mitch From list-mgr@ISI.EDU Wed Jun 28 02:36:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 13:38:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 13:37:33 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 13:37:26 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.11/8.6.9) id XAA00776; Tue, 27 Jun 1995 23:36:32 +0300 Date: Tue, 27 Jun 1995 23:36:32 +0300 Message-Id: <199506272036.XAA00776@silver.sms.fi> From: Petri Helenius To: Mitch Collinsworth Cc: mbone Subject: MBone negative loss In-Reply-To: <9506272000.AA10549@maytag.graphics.cornell.edu> References: <9506272000.AA10549@maytag.graphics.cornell.edu> Mitch Collinsworth writes: > > Watching the shuttle launch, nv is reporting negative loss rates as > high (low?) as -75%. Seems to vary significantly. Sometimes it's > near zero or even positive, then it swings to large negatives again. > > I would have guessed this to mean that a mis-configuration somewhere > is causing packets to be duplicated, yet strangely, vat is not > reporting any duplicates. But it does show a significant number of > misordered packets. Is vat logging duplicates as misordered? What > is causing vat's negative loss? (On the other hand reception is > excellent! :-) > Not having the source ;-) I'd guess that vat and nv report loss against the expected amount of data for given timeframe. If you have significant amount of jitter and somebody actually can hold back data for couple of seconds, you'll receive 1.5 sec worth of data in single second and that's reported as negative loss. When I was watching the shuttle video at launch time, the data rate went as up as almost 200kbps and the video is sent at 128kbps... So there is huge buffer somewhere in the infrastructure. Pete From list-mgr@ISI.EDU Tue Jun 27 08:58:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 15:59:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 15:58:57 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 15:58:56 -0700 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <17121(3)>; Tue, 27 Jun 1995 15:58:39 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16136>; Tue, 27 Jun 1995 15:58:29 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Petri Helenius Cc: Mitch Collinsworth , mbone Subject: Re: MBone negative loss In-Reply-To: Your message of "Tue, 27 Jun 95 13:36:32 PDT." <199506272036.XAA00776@silver.sms.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Jun 1995 15:58:25 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <95Jun27.155829pdt.16136@ecco.parc.xerox.com> In message <199506272036.XAA00776@silver.sms.fi> you write: > Not having the source ;-) I'd guess that vat and nv report loss against the > expected amount of data for given timeframe. If you have significant > amount of jitter and somebody actually can hold back data for couple of > seconds, you'll receive 1.5 sec worth of data in single second and that's > reported as negative loss. When I was watching the shuttle video at > launch time, the data rate went as up as almost 200kbps and the video > is sent at 128kbps... So there is huge buffer somewhere in the > infrastructure. > No -- in nv, negative loss numbers really do mean packets are being duplicated. It means essentially that it saw N packets in a range of sequence numbers smaller than N, meaning at least some of the packets had to have the same sequence number. The data rate being higher than the expected 128kbps would be explained by the duplication as well -- the source is generating only 128kbps, but multiple arrivals of the same packet cause the received data rate to be higher. -- Ron Frederick frederick@parc.xerox.com From list-mgr@ISI.EDU Wed Jun 28 09:26:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 16:32:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 16:26:50 -0700 Received: from vx23.cc.monash.edu.au by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 16:26:47 -0700 Received: from "port 1686"@basil.eng.monash.edu.au by vaxc.cc.monash.edu.au (PMDF V4.3-12 #8933) id <01HS8GF952KG8YAIWN@vaxc.cc.monash.edu.au>; Wed, 28 Jun 1995 09:26:32 +1000 Received: from BASIL/SpoolDir by basil.eng.monash.edu.au (Mercury 1.20) ; 28 Jun 95 09:26:36 -1000 Received: from SpoolDir by BASIL (Mercury 1.20); 28 Jun 95 09:26:20 -1000 Date: Wed, 28 Jun 1995 09:26:18 GMT+1100 From: JOHN PSALLIDAS Subject: How does NV v 3.3 Beta handle duplicates ? To: mbone Message-Id: <4B131270ECC@basil.eng.monash.edu.au> X-Mailer: Pegasus Mail/Windows (v1.22) Content-Transfer-Encoding: 7BIT Priority: normal Hello out there. Does NV 3.3 beta decode and use duplicate packets, or does it drop them imeddiately uppon their arrival without any further processing ? Just to clear a few things out. Thanks in advance. --------------------------------------------------- John Psallidas Postgraduate student. Monash Uni., Melbourne, Australia. E-mail : yannis@basil.eng.monash.edu.au Phone : (03) 9055350 /-\_/-\ / \ \_/---\*_/ \/ From list-mgr@ISI.EDU Tue Jun 27 09:58:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 17:00:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 16:58:33 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 16:58:32 -0700 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <15175(5)>; Tue, 27 Jun 1995 16:58:14 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16136>; Tue, 27 Jun 1995 16:58:07 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: JOHN PSALLIDAS Cc: mbone Subject: Re: How does NV v 3.3 Beta handle duplicates ? In-Reply-To: Your message of "Wed, 28 Jun 95 02:26:18 PDT." <4B131270ECC@basil.eng.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Jun 1995 16:58:06 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <95Jun27.165807pdt.16136@ecco.parc.xerox.com> In message <4B131270ECC@basil.eng.monash.edu.au> you write: > Does NV 3.3 beta decode and use duplicate packets, or does it > drop them imeddiately uppon their arrival without any further > processing ? > It decodes them if they are still part of the "current" frame, and discards them without further processing if they are a part of an older frame. It uses the RTP timestamp field to determine which frame the packet belongs to. This allows it to decode packets within a frame out of order without having to keep a lot of state about which ones it has seen. -- Ron Frederick frederick@parc.xerox.com From list-mgr@ISI.EDU Tue Jun 27 11:31:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 18:37:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 18:32:10 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 27 Jun 1995 18:32:09 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <17215(3)>; Tue, 27 Jun 1995 18:31:54 PDT Received: by crevenia.parc.xerox.com id <49860>; Tue, 27 Jun 1995 18:31:47 -0700 From: Bill Fenner To: mbone, root@alpha.noc.usl.edu, root@houdini.gatech.edu, root@viviane.usl.edu Subject: Host viviane.usl.edu is responding to multicasts with ICMP net unreach. Cc: fenner@parc.xerox.com Message-Id: <95Jun27.183147pdt.49860@crevenia.parc.xerox.com> Date: Tue, 27 Jun 1995 18:31:35 PDT The host viviane.usl.edu is responding to multicasts with ICMP network unreachable errors, in violation of RFC1112. This is what is causing the 50% packet loss that most people are seeing on the NASA Shuttle Video session (and possibly other sessions). Could someone at USL take care of this ASAP? Barring that, could someone at gatech disconnect USL's tunnel until this is taken care of? Thanks, Bill From list-mgr@ISI.EDU Tue Jun 27 19:21:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 02:28:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 02:20:51 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 02:20:50 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id CAA00765; Wed, 28 Jun 1995 02:21:43 -0700 Message-Id: <199506280921.CAA00765@rx7.ee.lbl.gov> To: mbone Cc: mahler@usl.edu Subject: host viviane.usl.edu still trashing shuttle video stream Date: Wed, 28 Jun 95 02:21:43 PDT From: Van Jacobson As Bill Fenner pointed out yesterday, host viviane.usl.edu (130.70.40.162) appears to be causing the >50% packet loss that most people are seeing on the Shuttle video session. It is causing the loss by sending an ICMP unreachable packet in reponse to every multicast packet put on the 130.70.40 subnet at USL. For a few hours yesterday evening, it appears that alpha.noc.usl.edu (the mbone tunnel endpoint at USL) was off the mbone and the NASA video reception here was perfect (0% loss). At around 12:50am, I started to see ICMP unreachables from viviane again (sent in response to my session msgs in the shuttle audio session) and the NASA video loss rate immediately went up to 50%. There are already ~400 people tuned into the Shuttle mission and there will probably be a couple thousand trying to watch the MIR docking. It would be a shame if this one broken host screwed up the video for people all over the world. It would be best if viviane.usl.edu could be moved to a subnet that didn't get any multicast traffic or just powered off (the machines that normally generate these bogus ICMPs are IBM RTs & Unisys machines -- often these are just as useful with the power off as on). If it can't be powered off or moved, perhaps a filter can be installed on the local gateway to discard all ICMPs from viviane. If USL can't do anything, perhaps Georgia Tech could temporarily disconnect the tunnel from houdini-fddi.gatech.edu to alpha.noc.usl.edu until USL has time to fix the problem. For the curious, the reason that viviane's ICMPs are trashing the video stream is that the kernel interprets ICMP unreachables as an error (they probably would be an error if the traffic were unicast) which causes the next send that nv does to be aborted with an ENETUNREACH error. Nv effectively ignores the error but it does cause the packet that it was trying to send to be discarded. If the nv packets are well spaced, the result is that every other packet gets discarded (50% loss). (The reason that vat audio is working is because vat looks for EUNREACH errors and resends the packet if it gets one.) Viviane is probably not running the multicast apps or a multicast kernel -- it is probably just some host with a broken IP stack that is mis-handling any multicast traffic that happens to appear on the local wire. The reason it's cobbering the Shuttle session is because Steve Mahler is tuned into the Shuttle sessions on host alpha.noc.usl.edu (which is not misbehaving) and that causes the shuttle multicast traffic to get put on the 130.70.40 subnet where viviane lives. Until viviane gets fixed, any video session that Steve tunes into will get trashed. - Van From list-mgr@ISI.EDU Wed Jun 28 15:18:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 02:28:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 02:24:13 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 02:24:12 -0700 Received: from mits.mdata.fi ([192.98.43.1]) by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 28 Jun 1995 02:23:59 -0700 Received: (setala@localhost) by mits.mdata.fi (8.6.12/8.6.5) id MAA09878 for mbone@isi.edu; Wed, 28 Jun 1995 12:18:26 +0300 From: Saku Setala Message-Id: <199506280918.MAA09878@mits.mdata.fi> Subject: Re: Host viviane.usl.edu is responding to multicasts with ICMP net unreach. (fwd) To: mbone Date: Wed, 28 Jun 1995 12:18:26 +0300 (EET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1125 Forwarded message: From setala Wed Jun 28 12:17:27 1995 From: Saku Setala Message-Id: <199506280917.MAA09856@mits.mdata.fi> Subject: Re: Host viviane.usl.edu is responding to multicasts with ICMP net unreach. To: fenner@parc.xerox.com (Bill Fenner) Date: Wed, 28 Jun 1995 12:17:18 +0300 (EET DST) Cc: setala (Saku Setala) In-Reply-To: <95Jun27.183147pdt.49860@crevenia.parc.xerox.com> from "Bill Fenner" at Jun 27, 95 06:31:35 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 604 > > The host viviane.usl.edu is responding to multicasts with ICMP network > unreachable errors, in violation of RFC1112. This is what is causing > the 50% packet loss that most people are seeing on the NASA Shuttle > Video session (and possibly other sessions). Could someone at USL take > care of this ASAP? Barring that, could someone at gatech disconnect > USL's tunnel until this is taken care of? > > Thanks, > Bill > In addition to that, WE have to pay $$$$'s for all the traffic we receive and transmit. This surely is something I don't want to pay for. Where to send the bill? --Saku From list-mgr@ISI.EDU Thu Jun 29 08:25:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 05:27:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 05:25:48 -0700 Received: from vitruvius.arbld.unimelb.EDU.AU by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 05:25:46 -0700 Received: (from darrenr@localhost) by vitruvius.arbld.unimelb.EDU.AU (8.6.12/8.6.12) id WAA11468 for mbone@isi.edu; Wed, 28 Jun 1995 22:25:39 +1000 From: Darren Reed Message-Id: <199506281225.WAA11468@vitruvius.arbld.unimelb.EDU.AU> Subject: mrouted3.6 ? To: mbone Date: Wed, 28 Jun 1995 22:25:38 +1000 (EST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 454 Anyone seeing these with 3.6 ? Jun 28 16:15:41 ledoux vmunix: ip_mforward: ip_mrouter socket queue full Jun 28 16:16:15 ledoux last message repeated 11 times (Err, +10 GMT) And now, my mrouted is stuck in disk-wait (4.1.3_U1, multicast3.5). Built with RSRR and SMUX... :-( err, no, maybe it is trying to dump core, (/ is 100% and /core belongs to in.mrouted but only 24k...:/) a ...I really don't want to have to reboot to get around this. darren From list-mgr@ISI.EDU Wed Jun 28 02:54:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 06:02:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 05:55:35 -0700 Received: from armagnac.ucs.usl.edu (ucs-gw.usl.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 05:55:32 -0700 Received: from noc.usl.edu (alpha.noc.usl.edu) by armagnac.ucs.usl.edu with SMTP id AA07428 (5.65c/IDA-1.4.4 for ); Wed, 28 Jun 1995 07:54:50 -0500 Received: by noc.usl.edu (5.0/ALPHA-2.2V1) id AA00805; Wed, 28 Jun 95 07:54:48 CDT Date: Wed, 28 Jun 95 07:54:48 CDT From: mahler@noc.usl.edu (Stephen J. Mahler) Message-Id: <9506281254.AA00805@noc.usl.edu> To: mbone, van@ee.lbl.gov, setala@mits.mdata.fi, fenner@parc.xerox.com, root@houdini.gatech.edu X-Sun-Charset: US-ASCII Content-Length: 255 All: USL has shutdown its end of the tunnel while we look at the problems caused by viviane.usl.edu. ... Steve Stephen J. Mahler, Director Information Networks University of Southwestern Louisiana voice:318+482-6904 fax:318+482-6195 KF5VH PP-ASEL-IA From list-mgr@ISI.EDU Wed Jun 28 06:30:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 07:34:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 07:30:11 -0700 Received: from loki.oar.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 07:30:10 -0700 Received: for welch@oar.net by loki.oar.net (8.6.10/931123.1402) id KAA09643; Wed, 28 Jun 1995 10:30:09 -0400 From: Arun Welch Message-Id: <199506281430.KAA09643@loki.oar.net> Subject: Camera's To: mbone Date: Wed, 28 Jun 1995 10:30:08 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 412 This is probably a FAQ, but can anyone suggest a camera that works with the Sun videopix card? I'm sure a plain old hand-held camera from any electronics shop will work, but that's an awful lot of desktop real estate to give up. ...arun --------------------------------------------------------------------------- Arun Welch 2455 Northstar Rd Network Engineer Columbus, OH 43221 OARnet welch@oar.net From list-mgr@ISI.EDU Wed Jun 28 06:47:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 07:52:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 07:48:47 -0700 Received: from mailer.jhuapl.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 07:48:44 -0700 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA29702; Wed, 28 Jun 1995 10:48:42 -0400 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA11295; Wed, 28 Jun 1995 10:47:58 -0400 Date: Wed, 28 Jun 1995 10:47:57 -0400 (EDT) From: Jim Bogard BIX Subject: Re: mrouted3.6 ? To: Darren Reed Cc: mbone In-Reply-To: <199506281225.WAA11468@vitruvius.arbld.unimelb.EDU.AU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 760 Yes, with 3.5, too. Although I was fortunate enough not to have the core dump. What causes this? J-. ---- Jim Bogard JHU/APL BIX Group "This is my banjo. There are many Backbone Network Engineer like it, but this one is mine." > > Anyone seeing these with 3.6 ? > > Jun 28 16:15:41 ledoux vmunix: ip_mforward: ip_mrouter socket queue full > Jun 28 16:16:15 ledoux last message repeated 11 times > > (Err, +10 GMT) > > And now, my mrouted is stuck in disk-wait (4.1.3_U1, multicast3.5). > Built with RSRR and SMUX... > > :-( > > err, no, maybe it is trying to dump core, (/ is 100% and /core belongs > to in.mrouted but only 24k...:/) > a > ...I really don't want to have to reboot to get around this. > > darren > From list-mgr@ISI.EDU Wed Jun 28 19:02:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 08:07:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 08:03:25 -0700 Received: from noc.BelWue.DE by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 08:03:18 -0700 Received: from pi4.informatik.uni-mannheim. (pi4.informatik.uni-mannheim.de [134.155.48.96]) by noc.belwue.de with SMTP id RAA04742 (8.6.12/IDA-1.6 for ); Wed, 28 Jun 1995 17:03:08 +0200 Received: from eratosthenes by pi4.informatik.uni-mannheim.de (5.65/BelWue-1.1DEC) id AA08010; Wed, 28 Jun 95 16:21:44 +0200 From: whd@pi4.informatik.uni-mannheim.de (Wieland Holfelder) Received: by eratosthenes; (5.65/1.1.8.2/02May95-1040AM) id AA05684; Wed, 28 Jun 1995 17:02:51 +0200 Message-Id: <9506281502.AA05684@eratosthenes> Subject: Rendevouz Shuttle-MIR To: mbone (Multicast Backbone) Date: Wed, 28 Jun 1995 17:02:50 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 761 Can anybody give a rough estimate on when the rendevous will happen? Or did it happen already and I missed it :-( Sorry to bother you, but I can't receive any MBone traffic right now but I can go to a different office where I could receive it when I only knew when... Thanks, -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder University of Mannheim Praktische Informatik IV Email: whd@pi4.informatik.uni-mannheim.de L 15,16 Fax : +49-621-292-5745 68131 Mannheim Phone: +49-621-292-5642 Germany http://www.informatik.uni-mannheim.de/~whd ------------------------------------------------------------------------------- From list-mgr@ISI.EDU Wed Jun 28 07:18:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 08:22:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 08:18:03 -0700 Received: from MAYTAG.GRAPHICS.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 08:18:02 -0700 Received: from localhost by maytag.graphics.cornell.edu; (5.65/1.1.8.2/07Nov94-0649PM) id AA20541; Wed, 28 Jun 1995 11:18:38 -0400 Message-Id: <9506281518.AA20541@maytag.graphics.cornell.edu> X-Mailer: exmh version 1.6gamma 3/31/95 To: mbone Subject: Re: MBone negative loss In-Reply-To: Your message of "Tue, 27 Jun 95 15:58:25 PDT." <95Jun27.155829pdt.16136@ecco.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Jun 95 11:18:37 -0400 From: Mitch Collinsworth X-Mts: smtp >No -- in nv, negative loss numbers really do mean packets are being duplicated. That's what I thought. I remember seeing it once before some time ago. Since it's still happening today, and since it's probably eating up unnecessary bandwidth over a pretty big portion of the mbone (seen both here and in Finland, as a start) perhaps we should try to track down the problem. I remember when we saw it before we were able to triangulate rather quickly on the offending site by comparing listener reports from various places with a mbone map. (Where is an up-to-date map of mbone topology?) What I don't understand is why when packets are being duplicated, is the percentage of duplicates varying so much. Last time I saw this all packets were duplicated. -Mitch From list-mgr@ISI.EDU Wed Jun 28 01:55:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 08:56:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 08:55:02 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 08:55:01 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id IAA01335; Wed, 28 Jun 1995 08:55:49 -0700 Message-Id: <199506281555.IAA01335@rx7.ee.lbl.gov> To: "Mark S. Fedor" Cc: mbone, mahler@usl.edu Subject: Re: host viviane.usl.edu still trashing shuttle video stream In-Reply-To: Your message of Wed, 28 Jun 95 11:41:14 EDT. Date: Wed, 28 Jun 95 08:55:48 PDT From: Van Jacobson Very strange. As soon as Steve got viviane off the net, the loss rate here went down to 1% & has pretty much stayed there. The path from scorpio.arc.nasa.gov to us & mae-east is the same through mbone.nsi.nasa.gov then diverges. The rest of the path to you is only 2 hops: brahms.sdsc.edu -> vinegar.sesqui.net -> mae-bone.psi.net. Vinegar is running 3.5 but brahms says it's "v1.0". I think this means it's a Proteon. I know that Sura had major multicast packet loss problems on their Proteons (this was what was screwing up Carl Malamud's feeds) so that may be where the problem is. Is anyone downstream of brahms.sdsc.edu seeing a low loss rate (<5%)? - Van From list-mgr@ISI.EDU Wed Jun 28 07:41:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 08:50:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 08:42:35 -0700 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 08:42:34 -0700 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA26461; Wed, 28 Jun 1995 11:41:15 +0500 Message-Id: <9506281541.AA26461@msf.psi.net.> To: Van Jacobson Cc: mbone, mahler@usl.edu Subject: Re: host viviane.usl.edu still trashing shuttle video stream In-Reply-To: Your message of "Wed, 28 Jun 1995 02:21:43 PDT." <199506280921.CAA00765@rx7.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <26459.804354074.1@msf.psi.net> Date: Wed, 28 Jun 1995 11:41:14 -0400 From: "Mark S. Fedor" Content-Length: 2981 FYI... I've been running RTP traces on the shuttle video at mae-bone.psi.net (on mae-east) all morning and I have an average loss rate of 30%. At this time, the loss rate continues at 30%. Mark ------- > As Bill Fenner pointed out yesterday, host viviane.usl.edu > (130.70.40.162) appears to be causing the >50% packet loss that > most people are seeing on the Shuttle video session. It is > causing the loss by sending an ICMP unreachable packet in > reponse to every multicast packet put on the 130.70.40 subnet at > USL. For a few hours yesterday evening, it appears that > alpha.noc.usl.edu (the mbone tunnel endpoint at USL) was off the > mbone and the NASA video reception here was perfect (0% loss). > At around 12:50am, I started to see ICMP unreachables from > viviane again (sent in response to my session msgs in the > shuttle audio session) and the NASA video loss rate immediately > went up to 50%. > > There are already ~400 people tuned into the Shuttle mission > and there will probably be a couple thousand trying to watch > the MIR docking. It would be a shame if this one broken host > screwed up the video for people all over the world. It would be > best if viviane.usl.edu could be moved to a subnet that didn't > get any multicast traffic or just powered off (the machines that > normally generate these bogus ICMPs are IBM RTs & Unisys machines -- > often these are just as useful with the power off as on). If > it can't be powered off or moved, perhaps a filter can be installed > on the local gateway to discard all ICMPs from viviane. If USL > can't do anything, perhaps Georgia Tech could temporarily disconnect > the tunnel from houdini-fddi.gatech.edu to alpha.noc.usl.edu until > USL has time to fix the problem. > > For the curious, the reason that viviane's ICMPs are trashing > the video stream is that the kernel interprets ICMP unreachables > as an error (they probably would be an error if the traffic were > unicast) which causes the next send that nv does to be aborted > with an ENETUNREACH error. Nv effectively ignores the error but > it does cause the packet that it was trying to send to be > discarded. If the nv packets are well spaced, the result is > that every other packet gets discarded (50% loss). (The reason > that vat audio is working is because vat looks for EUNREACH > errors and resends the packet if it gets one.) Viviane is > probably not running the multicast apps or a multicast kernel -- > it is probably just some host with a broken IP stack that is > mis-handling any multicast traffic that happens to appear on the > local wire. The reason it's cobbering the Shuttle session is > because Steve Mahler is tuned into the Shuttle sessions on host > alpha.noc.usl.edu (which is not misbehaving) and that causes the > shuttle multicast traffic to get put on the 130.70.40 subnet > where viviane lives. Until viviane gets fixed, any video > session that Steve tunes into will get trashed. > > - Van From list-mgr@ISI.EDU Wed Jun 28 01:59:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 09:02:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 09:02:15 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 09:02:14 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14770(4)>; Wed, 28 Jun 1995 09:00:11 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49860>; Wed, 28 Jun 1995 09:00:02 -0700 To: Darren Reed Cc: mbone Subject: Re: mrouted3.6 ? In-Reply-To: Your message of "Wed, 28 Jun 95 05:25:38 PDT." <199506281225.WAA11468@vitruvius.arbld.unimelb.EDU.AU> Date: Wed, 28 Jun 1995 08:59:54 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun28.090002pdt.49860@crevenia.parc.xerox.com> In message <199506281225.WAA11468@vitruvius.arbld.unimelb.EDU.AU> you write: >Anyone seeing these with 3.6 ? > >Jun 28 16:15:41 ledoux vmunix: ip_mforward: ip_mrouter socket queue full >Jun 28 16:16:15 ledoux last message repeated 11 times This is a normal startup transient. Was this when you started up mrouted? >err, no, maybe it is trying to dump core, (/ is 100% and /core belongs >to in.mrouted but only 24k...:/) I haven't ever seen a 3.6-release dump core; if it finishes dumping core could you mail me the core file? Thanks, Bill From list-mgr@ISI.EDU Wed Jun 28 18:23:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 09:23:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 09:23:31 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 09:23:23 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id RAA29959; Wed, 28 Jun 1995 17:23:21 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id RAA01535; Wed, 28 Jun 1995 17:23:17 +0100 Date: Wed, 28 Jun 1995 17:23:14 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Van Jacobson Cc: mbone Subject: Re: host viviane.usl.edu still trashing shuttle video stream In-Reply-To: <199506281555.IAA01335@rx7.ee.lbl.gov> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 28 Jun 1995, Van Jacobson wrote: > may be where the problem is. Is anyone downstream of brahms.sdsc.edu > seeing a low loss rate (<5%)? > > - Van No but I am seeing a loss rate of about 60% here in the UK. It is about as bad as I have ever seen it. A large number of packets are misordered but I am seeing very few duplicates. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Wed Jun 28 09:05:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 10:07:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 10:06:52 -0700 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 10:06:51 -0700 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA26551; Wed, 28 Jun 1995 13:05:40 +0500 Message-Id: <9506281705.AA26551@msf.psi.net.> To: Van Jacobson Cc: mbone Subject: Re: host viviane.usl.edu still trashing shuttle video stream In-Reply-To: Your message of "Wed, 28 Jun 1995 08:55:48 PDT." <199506281555.IAA01335@rx7.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <26549.804359139.1@msf.psi.net> Date: Wed, 28 Jun 1995 13:05:40 -0400 From: "Mark S. Fedor" Content-Length: 1680 Hmmmm.... I went to mae-bone and disabled the physint directly on the MAE-East ethernet. There were about 3-5 native multicast speakers on MAE-East that mae-bone was seeing. I left in the mae-bone tunnel to sesquinet. Now I see 0% packet loss on the shuttle video stream. Here is the current mrinfo with the physint disabled. Mark ---------- mae-bone.psi.net# mrinfo 192.41.177.247 192.41.177.247 (mae-bone.psi.net) [version 2.2]: 192.41.177.247 -> 0.0.0.0 (local) [1/1/disabled] 192.41.177.247 -> 38.145.250.3 (rambone.psi.net) [1/10/tunnel] 192.41.177.247 -> 149.127.6.181 (msf.psi.net) [1/3/tunnel] 192.41.177.247 -> 192.121.154.134 (Stockholm.Mbone.Ebone.NET) [1/64/tunnel] 192.41.177.247 -> 128.241.0.91 (VINEGAR.SESQUI.NET) [1/64/tunnel] 192.41.177.247 -> 192.70.92.133 (fmroute1-1.exp.edf.fr) [1/64/tunnel] 192.41.177.247 -> 146.126.248.124 (146.126.248.124) [1/64/tunnel/down] 192.41.177.247 -> 137.39.43.34 (MBONE1.UU.NET) [1/64/tunnel] ------------- > Very strange. As soon as Steve got viviane off the net, the > loss rate here went down to 1% & has pretty much stayed there. > The path from scorpio.arc.nasa.gov to us & mae-east is the > same through mbone.nsi.nasa.gov then diverges. The rest of > the path to you is only 2 hops: brahms.sdsc.edu -> vinegar.sesqui.net > -> mae-bone.psi.net. Vinegar is running 3.5 but brahms says > it's "v1.0". I think this means it's a Proteon. I know that > Sura had major multicast packet loss problems on their Proteons > (this was what was screwing up Carl Malamud's feeds) so that > may be where the problem is. Is anyone downstream of brahms.sdsc.edu > seeing a low loss rate (<5%)? > > - Van From list-mgr@ISI.EDU Wed Jun 28 03:09:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 10:10:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 10:10:33 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 10:10:32 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <17358(3)>; Wed, 28 Jun 1995 10:09:32 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49861>; Wed, 28 Jun 1995 10:09:15 -0700 To: "Mark S. Fedor" Cc: Van Jacobson , mbone, mahler@usl.edu Subject: Re: host viviane.usl.edu still trashing shuttle video stream In-Reply-To: Your message of "Wed, 28 Jun 95 08:41:14 PDT." <95Jun28.091921pdt.59413@klute.parc.xerox.com> Date: Wed, 28 Jun 1995 10:09:01 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun28.100915pdt.49861@crevenia.parc.xerox.com> In message <95Jun28.091921pdt.59413@klute.parc.xerox.com> you write: >FYI... I've been running RTP traces on the shuttle video at mae-bone.psi.net >(on mae-east) all morning and I have an average loss rate of 30%. It's clear that there are multiple sources of loss; we just needed to get rid of the artificial one before we could track down the real ones. rtpqual is showing 0 loss here. Bill From list-mgr@ISI.EDU Wed Jun 28 19:43:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 10:44:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 10:43:43 -0700 Received: from mailhost.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 10:43:37 -0700 Received: (jon@localhost) by weeble.lut.ac.uk (8.6.12/8.6.9) id SAA18685; Wed, 28 Jun 1995 18:43:14 +0100 Date: Wed, 28 Jun 1995 18:43:14 +0100 (BST) From: Jon Knight To: mbone Cc: Graeme.Wood@ucs.ed.ac.uk Subject: Re: host viviane.usl.edu still trashing shuttle video stream In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 28 Jun 1995, Graeme Wood wrote: > No but I am seeing a loss rate of about 60% here in the UK. It is about > as bad as I have ever seen it. A large number of packets are misordered > but I am seeing very few duplicates. And the same here (so its not just a problem at Edinburgh). My stats currently look like this: packets badhdr wrongid badaud lost drop dup order playout 8/8 0/0.0 0/0.0 0/0.0 0/0.0 0/0.0 0/0.0 0/0.0 96ms 129.16.226.208 5/5 0/0.0 0/0.0 0/0.0 0/0.0 0/0.0 0/0.0 0/0.0 86ms 8669/9236 0/0.0 0/0.0 0/0.0 567/6.1 0/0.0 0/0.0 418/4.5 1.4s 192.35.149.44 45806/127896 0/0.0 0/0.0 0/0.0 82090/64 104/0.1 0/0.0 26633/21 663ms NASA STS-71 Mission as reported by 'n' in the vat window. The 82090/64 in the last line is the one to take notice of. Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Researcher, Sysop and General Dogsbody, Department of Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. *** Nothing looks so like a man of sense as a fool who holds his tongue *** From list-mgr@ISI.EDU Wed Jun 28 10:05:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 11:07:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 11:05:46 -0700 Received: from cerc.wvu.edu (cathedral.cerc.wvu.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 11:05:45 -0700 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA07192; Wed, 28 Jun 95 14:05:43 EDT Received: by elk (5.0//ident-1.0) id AA00343; Wed, 28 Jun 1995 14:05:42 -0400 Date: Wed, 28 Jun 1995 14:05:41 -0400 (EDT) From: "Todd L. Montgomery" Subject: Re: host viviane.usl.edu still trashing shuttle video stream To: "Mark S. Fedor" Cc: mbone In-Reply-To: <9506281541.AA26461@msf.psi.net.> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 190 We have now MBone feed from GSFC (right off of mbone.nsi.nasa.gov) and we are seeing about 20-30% loss on the Shuttle video. Audio is even worse at the moment, about 40% or more. -- Todd From list-mgr@ISI.EDU Wed Jun 28 10:23:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 11:25:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 11:23:51 -0700 Received: from aruba.lerc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 11:23:47 -0700 Received: from brahams.lerc.nasa.gov by aruba.lerc.nasa.gov with SMTP (950215.SGI.8.6.10/LeRC/DLW/TAF(1.24-main)) id OAA11361; Wed, 28 Jun 1995 14:23:33 -0400 Received: by brahams.lerc.nasa.gov (5.x/LeRC/DLW/TAF(1.23-local)) id AA15889; Wed, 28 Jun 1995 14:23:26 -0400 Date: Wed, 28 Jun 1995 14:23:25 -0400 (EDT) From: vick To: Wieland Holfelder Cc: Multicast Backbone Subject: Re: Rendevouz Shuttle-MIR In-Reply-To: <9506281502.AA05684@eratosthenes> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Link up should occur at approximately 7:00 am, June 28 EST (8:am CST). On Wed, 28 Jun 1995, Wieland Holfelder wrote: > Can anybody give a rough estimate on when the rendevous will happen? > Or did it happen already and I missed it :-( > Sorry to bother you, but I can't receive any MBone traffic right now > but I can go to a different office where I could receive it when I > only knew when... > > Thanks, > -- Wieland > ------------------------------------------------------------------------------- > Wieland Holfelder > University of Mannheim > Praktische Informatik IV Email: whd@pi4.informatik.uni-mannheim.de > L 15,16 Fax : +49-621-292-5745 > 68131 Mannheim Phone: +49-621-292-5642 > Germany http://www.informatik.uni-mannheim.de/~whd > ------------------------------------------------------------------------------- > > > ----------------------------------------------------------------------------- Vick Kiff Systems Admin (SCd) |ph: 216-433-6547 NASA Lewis Research Center | Cleveland, Ohio 44135 |email: vick@lerc.nasa.gov ----------------------------------------------------------------------------- "May I have your attention please: Due to budget constraints, the light at the end of the tunnel will be turned off...Thank you." From list-mgr@ISI.EDU Wed Jun 28 05:23:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 12:26:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 12:24:36 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 12:24:36 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15354(1)>; Wed, 28 Jun 1995 12:24:20 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49860>; Wed, 28 Jun 1995 12:24:15 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Van Jacobson , evans@nsipo.nasa.gov Cc: "Mark S. Fedor" , mbone Subject: Re: host viviane.usl.edu still trashing shuttle video stream In-Reply-To: Your message of "Wed, 28 Jun 95 08:55:48 PDT." <199506281555.IAA01335@rx7.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Jun 1995 12:23:59 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun28.122415pdt.49860@crevenia.parc.xerox.com> In message <199506281555.IAA01335@rx7.ee.lbl.gov> you write: >The path from scorpio.arc.nasa.gov to us & mae-east is the >same through mbone.nsi.nasa.gov then diverges. Actually, the path to PARC (and presumably to LBL) is via mbone2.nsi.nasa.gov . The path to mae-east is mbone2->mbone->brahms->sesqui->psi . I haven't been able to find a path to someone complaining about packet loss that doesn't go through mbone.nsi.nasa.gov, but given its closeness to the source that's not surprising. However, not all of the people claiming loss are along Mark's path; there are also people behind BARRNet, and even behind mbone.gsfc.nasa.gov . I suspect mbone.nsi.nasa.gov, but I don't have any ideas how to test my suspicions. Perhaps someone from NSI could run rtpqual on a host on the 128.102.32 subnet? Bill From list-mgr@ISI.EDU Wed Jun 28 05:45:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 12:46:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 12:45:17 -0700 Received: from baker.nwnet.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 12:45:14 -0700 Received: by baker.nwnet.net (5.65/UW-NDC Revision: 2.29 ) id AA17295; Wed, 28 Jun 95 12:45:51 -0700 Date: Wed, 28 Jun 1995 12:45:51 -0700 (PDT) From: David Comay To: mbone Subject: Re: host viviane.usl.edu still trashing shuttle video stream In-Reply-To: <95Jun28.100915pdt.49861@crevenia.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 28 Jun 1995, Bill Fenner wrote: > It's clear that there are multiple sources of loss; we just needed to get > rid of the artificial one before we could track down the real ones. speaking of extraneous/bogus unreachables, the following two hosts are also sending them in response to traffic on the `mbone ivs' channel (224.2.224.2 port 2232) eps_adm2.aber.ac.uk eps_nlw1.aber.ac.uk they look like lantronix boxes... dsc From list-mgr@ISI.EDU Wed Jun 28 12:25:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 13:26:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 13:25:48 -0700 Received: from oit.gatech.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 13:25:47 -0700 Received: (from ccoprmm@localhost) by oit.gatech.edu (8.6.12/8.6.12) id QAA15135; Wed, 28 Jun 1995 16:25:43 -0400 From: Michael.Mealling@oit.gatech.edu (Michael Mealling) Message-Id: <199506282025.QAA15135@oit.gatech.edu> Subject: Re: host viviane.usl.edu still trashing shuttle video stream To: van@ee.lbl.gov (Van Jacobson) Date: Wed, 28 Jun 1995 16:25:42 -0400 (EDT) Cc: fedor@msf.psi.net, mbone, mahler@usl.edu In-Reply-To: <199506281555.IAA01335@rx7.ee.lbl.gov> from "Van Jacobson" at Jun 28, 95 08:55:48 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 998 Van Jacobson said this: > Very strange. As soon as Steve got viviane off the net, the > loss rate here went down to 1% & has pretty much stayed there. > The path from scorpio.arc.nasa.gov to us & mae-east is the > same through mbone.nsi.nasa.gov then diverges. The rest of > the path to you is only 2 hops: brahms.sdsc.edu -> vinegar.sesqui.net > -> mae-bone.psi.net. Vinegar is running 3.5 but brahms says > it's "v1.0". I think this means it's a Proteon. I know that > Sura had major multicast packet loss problems on their Proteons > (this was what was screwing up Carl Malamud's feeds) so that > may be where the problem is. Is anyone downstream of brahms.sdsc.edu > seeing a low loss rate (<5%)? Does anyone want me to cut USL off entirely? Just checking.. -MM -- ------------------------------------------------------------------------------ Life is a game. Someone wins and someone loses. Get used to it.

Michael Mealling From list-mgr@ISI.EDU Wed Jun 28 12:34:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 13:36:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 13:36:02 -0700 Received: from lupine.nsi.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 13:36:01 -0700 Received: (from mnewell@localhost) by lupine.nsi.nasa.gov (8.6.12/8.6.12) id QAA16292; Wed, 28 Jun 1995 16:34:04 -0400 Date: Wed, 28 Jun 1995 16:34:04 -0400 (EDT) From: "Michael C. Newell" To: Bill Fenner Cc: Van Jacobson , evans@nsipo.nasa.gov, "Mark S. Fedor" , mbone Subject: Re: host viviane.usl.edu still trashing shuttle video stream In-Reply-To: <95Jun28.122415pdt.49860@crevenia.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 28 Jun 1995, Bill Fenner wrote: > I suspect mbone.nsi.nasa.gov, but I don't have any ideas how to test my > suspicions. Perhaps someone from NSI could run rtpqual on a host on the > 128.102.32 subnet? You might try contacting Dan Evans (evans@nsipo.nasa.gov) directly; he manages mbone.nsi.nasa.gov... I can run stuff on machines on that subnet, but I'm across the country and it might be best to deal with Dan (who is on site.) Thanks, Mike +--------------------------------------+------------------------------------+ |Mike Newell | The opinions expressed herein are | |NASA Science Internet Network Systems | my own, and do not necessarily | |Sterling Software, Inc. | reflect those of the NSI program, | |MNewell@nsipo.nasa.gov | Sterling Software, NASA, or anyone | |+1-202-434-8954 | else. | +--------------------------------------+------------------------------------+ | work: http://www.eco.nsi.nasa.gov/~mnewell | | home: http://www.newell.arlington.va.us | +---------------------------------------------------------------------------+ From list-mgr@ISI.EDU Wed Jun 28 12:59:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:07:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:04:23 -0700 Received: from admii.arl.mil by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:04:22 -0700 Date: Wed, 28 Jun 95 16:59:47 EDT From: Phil Dykstra To: Van Jacobson Cc: mbone Subject: Re: host viviane.usl.edu still trashing shuttle video stream Message-Id: <9506281659.aa14986@ADMII.ARL.MIL> > Is anyone downstream of brahms.sdsc.edu seeing a low loss rate (<5%)? The AAI and IDREN networks are downstream from Brahms, via NCCOSC (mbone-dmz.nosc.mil). Yesterday we also saw 50%-60% nv loss. Today it has been 10%-25% most of the day with occasional drops to 0%. [We routinely run > 200 kbps of internal multicast traffic over these nets with nearly 0% loss.] - Phil From list-mgr@ISI.EDU Wed Jun 28 07:01:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:07:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:03:49 -0700 Received: from hawk.csusm.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:03:47 -0700 Received: by hawk.csusm.edu (AIX 4.1/UCB 5.64/4.03) id AA03380; Wed, 28 Jun 1995 14:01:39 -0700 Date: Wed, 28 Jun 1995 14:01:39 -0700 (PDT) From: Mark Chorak X-Sender: chorak1@hawk.csusm.edu To: mbone Subject: Configuring Mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have a IBM AIX RISC 6k workstation running AIX 4.1.2. I have the software for Mbone, but it says I have to reinstall the kernal to get it to go. Is there an easier way of doing this, like say, through a script? Ive seen one for the SunOS but nothing for AIX. Mark chorak1@coyote.csusm.edu From list-mgr@ISI.EDU Wed Jun 28 13:14:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:15:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:14:23 -0700 Received: from wizard.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:14:21 -0700 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA03141; Wed, 28 Jun 95 17:14:05 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9506282114.AA03141@wizard.gsfc.nasa.gov> Subject: Re: host viviane.usl.edu still trashing shuttle video stream To: tmont@cerc.wvu.edu (Todd L. Montgomery) Date: Wed, 28 Jun 1995 17:14:04 -0400 (EDT) Cc: fedor@msf.psi.net, mbone, evans@nsipo.nasa.gov, van@ee.lbl.gov In-Reply-To: from "Todd L. Montgomery" at Jun 28, 95 02:05:41 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4480 > From: "Todd L. Montgomery" > > We have now MBone feed from GSFC (right off of mbone.nsi.nasa.gov) and > we are seeing about 20-30% loss on the Shuttle video. Audio is even worse > at the moment, about 40% or more. I found one possible problem, but I'm not sure if it is *the* problem. Please read on. I have also been seeing major lossage internal to GSFC. From Van's message stating that he wasn't seeing any significant loss at lbl.gov, I compared the paths from scorpio.arc.nasa.gov (128.102.84.140) to rx7.ee.lbl.gov (128.3.112.12) and wizard.gsfc.nasa.gov (128.183.115.17). wizard% mtracerouteg 128.102.84.140 128.3.112.12 scorpio.arc.nasa.gov(128.102.84.140), 0/0/0 mbone2.nsi.nasa.gov(192.203.230.242), 1/1/2 mbone.nsi.nasa.gov(192.203.230.241), 2/2/3 llnl-mr2.es.net(134.55.12.229), 3/3/67 lbl-mr1.es.net(134.55.12.101), 4/4/67 mr1.lbl.gov(128.3.254.184), 5/5/67 vet.ee.lbl.gov(128.3.112.48), 6/9/67 128.3.112, 7/9/67 This is the OK path. wizard% mtracerouter 128.102.84.140 scorpio.arc.nasa.gov(128.102.84.140), 0/0/0 mbone2.nsi.nasa.gov(192.203.230.242), 1/1/2 mbone.nsi.nasa.gov(192.203.230.241), 2/2/3 mbone-cf.gsfc.nasa.gov(128.183.251.129), 3/3/35 mbone2-f.gsfc.nasa.gov(128.183.253.55), 4/4/35 mbone2.gsfc.nasa.gov(128.183.115.55), 5/4/35 128.183.115, 6/4/35 This is a path with major lossage. As you can see, the paths diverge at mbone.nsi.nasa.gov, the lbl.gov path then using a tunnel to llnl-mr2.es.net (134.55.12.229), while the gsfc.nasa.gov path uses a tunnel mbone-cf.gsfc.nasa.gov (128.183.251.129). Using traceroute to first check the tunnel path from mbone.nsi.nasa.gov to llnl-mr2.es.net: wizard% traceroute -g 192.203.230.241 134.55.12.229 traceroute to 134.55.12.229 (134.55.12.229), 30 hops max, 40 byte packets 1 rtr-sno-r.gsfc.nasa.gov (128.183.115.1) 2 ms 2 ms 2 ms 2 rtr-wan1-cf.gsfc.nasa.gov (128.183.251.1) 3 ms 3 ms 3 ms 3 rtr-internet-ef.gsfc.nasa.gov (192.43.240.36) 4 ms 4 ms 4 ms 4 128.161.1.1 (128.161.1.1) 73 ms 72 ms 76 ms 5 mbone.nsi.nasa.gov (192.203.230.241) 79 ms 86 ms 113 ms 6 192.203.230.13 (192.203.230.13) 91 ms 88 ms 99 ms 7 llnl-ames.es.net (134.55.4.162) 103 ms 103 ms 124 ms 8 llnl-mr2.es.net (134.55.12.229) 112 ms 99 ms 86 ms And then the tunnel path from mbone.nsi.nasa.gov to mbone-cf.gsfc.nasa.gov: wizard% traceroute -g 192.203.230.241 128.183.251.129 traceroute to 128.183.251.129 (128.183.251.129), 30 hops max, 40 byte packets 1 rtr-sno-r.gsfc.nasa.gov (128.183.115.1) 2 ms 2 ms 2 ms 2 rtr-wan1-cf.gsfc.nasa.gov (128.183.251.1) 3 ms 3 ms 3 ms 3 rtr-internet-ef.gsfc.nasa.gov (192.43.240.36) 4 ms 4 ms 4 ms 4 128.161.1.1 (128.161.1.1) 73 ms 75 ms 74 ms 5 mbone.nsi.nasa.gov (192.203.230.241) 82 ms 73 ms 73 ms 6 192.203.230.4 (192.203.230.4) 120 ms 181 ms 159 ms 7 ARC1.NSN.NASA.GOV (192.203.230.5) 91 ms 167 ms 185 ms 8 128.161.1.2 (128.161.1.2) 120 ms 168 ms 156 ms 9 rtr-wan1-ef.gsfc.nasa.gov (192.43.240.33) 97 ms 192 ms 157 ms 10 mbone-cf.gsfc.nasa.gov (128.183.251.129) 78 ms 167 ms 159 ms Both tunnels traverse the FDDI net 192.203.230 from mbone.nsi.nasa.gov, the llnl-mr2.es.net tunnel is routed via 192.203.230.13, while the mbone-cf.gsfc.nasa.gov tunnel is routed via 192.203.230.4. Well, the above traceroute for the mbone-cf.gsfc.nasa.gov tunnel shows a potentially serious problem, but I'm not sure if it's the problem. Notice that the next hop for the mbone-cf.gsfc.nasa.gov tunnel after 192.203.230.4 is 192.203.230.5 which is on the same FDDI net as mbone.nsi.nasa.gov. This may result in massive amounts of ICMP redirects from 192.203.230.4 back to mbone.nsi.nasa.gov, which doesn't appear to be paying any attention to them. This path seems to be using the default route for mbone.nsi.nasa.gov. The path for the llnl-mr2.es.net tunnel seems to be using an explicit route for the 134.55 net, since it is only taking one hop across the FDDI, while the path for the mbone-cf.gsfc.nasa.gov tunnel is taking two hops across the FDDI, via the unnecessary intermediate default route. I didn't check, but I suspect other tunnels may be encountering extra hops across the FDDI as well via the default route. I don't know if this is the cause of the major lossage, but it should probably be corrected in any event. -Bill From list-mgr@ISI.EDU Thu Jun 29 03:24:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:30:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:24:46 -0700 Received: from mits.mdata.fi by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:24:41 -0700 Received: (setala@localhost) by mits.mdata.fi (8.6.12/8.6.5) id AAA25382; Thu, 29 Jun 1995 00:24:30 +0300 From: Saku Setala Message-Id: <199506282124.AAA25382@mits.mdata.fi> Subject: Re: host viviane.usl.edu still trashing shuttle video stream To: J.P.Knight@lut.ac.uk (Jon Knight) Date: Thu, 29 Jun 1995 00:24:29 +0300 (EET DST) Cc: mbone In-Reply-To: from "Jon Knight" at Jun 28, 95 06:43:14 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 854 > On Wed, 28 Jun 1995, Graeme Wood wrote: > > No but I am seeing a loss rate of about 60% here in the UK. It is about > > as bad as I have ever seen it. A large number of packets are misordered > > but I am seeing very few duplicates. > Here in Helsinki, Finland, I am seeing loss rates from 40-80%, even sometimes it drops down to 30% and jumps as high as 90%. Couple months ago during NASA transmissions the loss was about 10-20% and I thought that was bad. ping testing to stockholm.mbone.ebone.net gave me 1% loss, u.s. side of the tunnel just gave me host unreachables. Today daytime there was a moment when datarate suddenly bursted up to 200kbit/s for couple of minutes and nv was reporting negative loss. European sessions arrive with 0-20% loss, and some transmissions from states (other than NASA) arrived yesterday with 30% loss. --Saku From list-mgr@ISI.EDU Wed Jun 28 13:40:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:41:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:40:46 -0700 Received: from mailer.psc.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:40:44 -0700 Received: from zippy.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA00734; Wed, 28 Jun 1995 17:40:39 -0400 Message-Id: <9506282140.AA00734@mailer.psc.edu> To: mbone-nsi@nsipo.nasa.gov Cc: mathis@psc.edu, mbone Subject: Mbone lossage Date: Wed, 28 Jun 1995 17:40:37 -0400 From: "Matt Mathis" The tunnel between oday.psc.edu and mbone.nsi.nasa.gov seems to have truly massive congestion problems right at mbone.nsi.nasa.gov. I can easily get more than 2 Mbit/s as far as fix-west-nap.SanFrancisco.mci.net (204.70.34.10), but no more than 45 kbit/s to mbone.nsi.nasa.gov, the next IP hop. Can sombody at NASA look at this? Thanks, --MM-- From list-mgr@ISI.EDU Wed Jun 28 13:56:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 15:03:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:56:54 -0700 Received: from wizard.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 14:56:52 -0700 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA03302; Wed, 28 Jun 95 17:56:30 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9506282156.AA03302@wizard.gsfc.nasa.gov> Subject: Re: host viviane.usl.edu still trashing shuttle video stream To: tmont@cerc.wvu.edu (Todd L. Montgomery) Date: Wed, 28 Jun 1995 17:56:29 -0400 (EDT) Cc: fedor@msf.psi.net, mbone, evans@nsipo.nasa.gov, van@ee.lbl.gov, fenner@parc.xerox.com, bill@wizard.gsfc.nasa.gov In-Reply-To: from "Todd L. Montgomery" at Jun 28, 95 02:05:41 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4078 More info: The default route for mbone.nsi.nasa.gov, namely 192.203.230.4, is dropping a large percentage of packets. The immediately preceeding router in my path from this router, 192.203.230.5, is not dropping packets. -Bill wizard% ping -s 192.203.230.4 PING 192.203.230.4: 56 data bytes 64 bytes from 192.203.230.4: icmp_seq=0. time=103. ms 64 bytes from 192.203.230.4: icmp_seq=1. time=86. ms 64 bytes from 192.203.230.4: icmp_seq=2. time=86. ms 64 bytes from 192.203.230.4: icmp_seq=3. time=102. ms 64 bytes from 192.203.230.4: icmp_seq=4. time=94. ms 64 bytes from 192.203.230.4: icmp_seq=6. time=107. ms 64 bytes from 192.203.230.4: icmp_seq=7. time=124. ms 64 bytes from 192.203.230.4: icmp_seq=8. time=83. ms 64 bytes from 192.203.230.4: icmp_seq=9. time=81. ms 64 bytes from 192.203.230.4: icmp_seq=10. time=71. ms 64 bytes from 192.203.230.4: icmp_seq=12. time=148. ms 64 bytes from 192.203.230.4: icmp_seq=13. time=86. ms 64 bytes from 192.203.230.4: icmp_seq=15. time=89. ms 64 bytes from 192.203.230.4: icmp_seq=16. time=113. ms 64 bytes from 192.203.230.4: icmp_seq=17. time=98. ms 64 bytes from 192.203.230.4: icmp_seq=21. time=87. ms 64 bytes from 192.203.230.4: icmp_seq=22. time=181. ms 64 bytes from 192.203.230.4: icmp_seq=25. time=102. ms 64 bytes from 192.203.230.4: icmp_seq=26. time=114. ms 64 bytes from 192.203.230.4: icmp_seq=29. time=94. ms 64 bytes from 192.203.230.4: icmp_seq=30. time=124. ms ^C ----192.203.230.4 PING Statistics---- 32 packets transmitted, 21 packets received, 34% packet loss round-trip (ms) min/avg/max = 71/103/181 wizard% ping -s 192.203.230.5 PING 192.203.230.5: 56 data bytes 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=0. time=75. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=1. time=70. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=2. time=72. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=3. time=70. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=4. time=71. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=5. time=152. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=6. time=70. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=7. time=71. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=8. time=70. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=9. time=70. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=10. time=71. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=11. time=71. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=12. time=70. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=13. time=70. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=14. time=71. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=15. time=71. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=16. time=70. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=17. time=106. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=18. time=129. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=19. time=141. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=20. time=70. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=21. time=70. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=22. time=70. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=23. time=72. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=24. time=72. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=25. time=71. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=26. time=71. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=27. time=70. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=28. time=70. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=29. time=72. ms 64 bytes from ARC1.NSN.NASA.GOV (192.203.230.5): icmp_seq=30. time=70. ms ^C ----192.203.230.5 PING Statistics---- 31 packets transmitted, 31 packets received, 0% packet loss round-trip (ms) min/avg/max = 70/78/152 From list-mgr@ISI.EDU Wed Jun 28 14:16:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 15:18:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 15:17:31 -0700 Received: from wizard.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 15:17:29 -0700 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA03386; Wed, 28 Jun 95 18:16:48 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9506282216.AA03386@wizard.gsfc.nasa.gov> Subject: Re: Rendevouz Shuttle-MIR To: vick@lerc.nasa.gov (vick) Date: Wed, 28 Jun 1995 18:16:47 -0400 (EDT) Cc: whd@pi4.informatik.uni-mannheim.de, mbone In-Reply-To: from "vick" at Jun 28, 95 02:23:25 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3477 > From: vick > > Link up should occur at approximately 7:00 am, June 28 EST (8:am CST). > > > On Wed, 28 Jun 1995, Wieland Holfelder wrote: > > > Can anybody give a rough estimate on when the rendevous will happen? > > Or did it happen already and I missed it :-( > > Sorry to bother you, but I can't receive any MBone traffic right now > > but I can go to a different office where I could receive it when I > > only knew when... The info I have is that it is scheduled for 13:20 UTC [9:20 EDT?] on Thursday, June 29 (see below). -Bill Newsgroups: gsfc.pao Subject: STS-71 SAREX Mission Begins Date: 28 Jun 95 13:49:05 GMT SB SAREX @ AMSAT $STS-71.002 STS-71 SAREX Mission Begins Silver Spring, MD June 28 @ 04:00 UTC The Space Shuttle Atlantis began its historic flight to the Russian Space Station MIR yesterday with an on-time launch from the Kennedy Space Center. Despite the threat of weather delays, the STS-71 mission and its U.S. and Russian crew of seven were lofted into the cloudy Florida skies at 19:32 UTC. This mission represents the first docking of U.S. and Russian manned space vehicles since the Apollo-Soyuz mission nearly 20 years ago. The seven member crew includes two ham radio operators: Pilot Charlie Precourt, KB5YSQ, and Mission Specialist Ellen Baker, KB5SIX. The other five shuttle crew members include Commander Hoot Gibson, Mission Specialists Greg Harbaugh and Bonnie Dunbar and Russian Cosmonauts Anatoly Solovyev and Nikolai Budarin. Prior to the docking with MIR, which is scheduled for 13:20 UTC on Thursday June 29, the Space Shuttle Atlantis will perform several, large thruster burns to catch up with the space station. Because the Shuttle Flight path will be so variable over the next few days, shuttle Keplerian elements will not be provided by the SAREX working group. The primary goal of the Shuttle Mission is to rendezvous and dock with MIR. Thus, the MIR orbital elements will provide ground-based observers the best "final trajectory" profile for the Space Shuttle Atlantis. SAREX enthusiasts should also note that the Shuttle crew will be quite busy during this rendezvous and docking phase of the mission. Thus, the crew is not expected to operate SAREX during this flight phase. SAREX operations during the docked portion of the mission will also be curtailed due to the SAREX antenna being blocked by MIR. SAREX operations are expected to be initiated after the post separation burn is performed on July 4 at 13:39 UTC. A MIR Keplerian Element set is provided for your convenience. Mir 1 16609U 86017A 95177.57042795 .00002606 00000-0 42223-4 0 1007 2 16609 51.6480 110.7224 0004878 115.5949 244.5543 15.56965667534337 Satellite: Mir Catalog number: 16609 Epoch time: 95177.57042795 Element set: 100 Inclination: 51.6480 deg RA of node: 110.7224 deg Semi-major axis: 3657.9590 n.mi. Eccentricity: 0.0004878 Apogee altitude: 215.8092 n.mi. Arg of perigee: 115.5949 deg Perigee altitude: 212.2405 n.mi. Mean anomaly: 244.5543 deg Altitude decay: 0.0036 n.mi./day Mean motion: 15.56965667 rev/day Apsidal rotation: 3.7266 deg/day Decay rate: 2.6060E-05 rev/day^2 Nodal regression: -4.9994 deg/day Epoch rev: 53433 Nodal period: 92.4261 min Checksum: 316 Submitted by Frank H. Bauer, KA3HDO for the SAREX Working Group From list-mgr@ISI.EDU Wed Jun 28 08:27:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 15:28:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 15:27:40 -0700 Received: from sgi.sgi.com (SGI.COM) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 15:27:39 -0700 Received: from tree.engr.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for <@sgi.sgi.com:mbone@isi.edu> id PAA02471; Wed, 28 Jun 1995 15:27:37 -0700 Received: by tree.engr.sgi.com (940816.SGI.8.6.9/911001.SGI) for mbone@isi.edu id PAA28790; Wed, 28 Jun 1995 15:27:36 -0700 From: "Bill Nowicki" Message-Id: <9506281527.ZM28788@tree.engr.sgi.com> Date: Wed, 28 Jun 1995 15:27:33 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: mbone Subject: Mbone losses Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii We (SGI) have been seeing large loss rates on almost all mbone traffic for about the past two weeks. First I thought it was a problem with our line or Barrnet, but after some help from Barrnet, and the recent U.N. and Cisco multicasts that had no losses at all, I now suspect it is something at NASA. We see about 30% loss from NASA, even though I can see Moffet Field out our window, and unicast routing is quick through Barrnet. Also seeing many "misordered" packets in vat. Xerox is also about five miles away, and we lose about half of the packets from them, as well as ISI. As far as I can tell, they both route through DARTnet, which seems to connect to the rest of the world at NASA Ames, mbone.nsi.nasa.gov and mbone2.nsi.nasa.gov, etc. It is unusable right now; anbody have suggestions? -- Bill Nowicki Silicon Graphics From list-mgr@ISI.EDU Thu Jun 29 19:39:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 16:40:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 16:39:35 -0700 Received: from octavia.anu.edu.au by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 16:39:11 -0700 Received: (from markus@localhost) by octavia.anu.edu.au (8.6.12/8.6.12) id JAA28538 for mbone@isi.edu; Thu, 29 Jun 1995 09:39:02 +1000 Date: Thu, 29 Jun 1995 09:39:02 +1000 From: Markus Buchhorn Message-Id: <199506282339.JAA28538@octavia.anu.edu.au> To: mbone Subject: FLASH: Shuttle destroys Oz Workstation Well - Ok - it crashed it anyway ;-). First time any of the mbone tools have ever done it here. vat 3.4, Solaris 2.4, SS5, with a fair few patches, including the 102125-02 audio/vat/SS5/2.4 patch. I ran sd, then fired up vat from the Shuttle Audio session. Sound was atrocious (50% loss yesterday, 60%+ today :-( ). I tried to watch the stats but only hit the little mute box (so many people listening!) so resized the vat window to something more usable. Brought up the stats (shift-LMB) and watched them for a while. Then gave up, dismissed the stats and hit 'Quit'. Bang - instantly workstation crashes/reboots: (timestamp and machine name 'neptune') stripped from the following) unix: BAD TRAP: type=9 rp=f058cb2c addr=fc4fff5c mmu_fsr=326 rw=1 unix: vat: Data fault unix: kernel read fault at addr=0xfc4fff5c, pme=0x0 unix: MMU sfsr=326: Invalid Address on supv data fetch at level 3 unix: pid=11100, pc=0xfc4fa304, sp=0xf058cb78, psr=0x44010c2, context=0 unix: g1-g7: f00574a4, 0, f0076910, 10, fc2425a8, 1, fc3f5c80 unix: Begin traceback... sp = f058cb78 unix: Called from fc4ec534, fp=f058cbd8, args=fc20e810 fc4faad4 e1fae4ff 1 88 7 [...] unix: End traceback... unix: panic: Data fault Any suggestions ? Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] From list-mgr@ISI.EDU Wed Jun 28 09:44:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 16:45:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 16:44:19 -0700 Received: from gator.arc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 16:44:18 -0700 Received: from localhost.arc.nasa.gov by gator.arc.nasa.gov (8.6.12/1.5T) id QAA03892; Wed, 28 Jun 1995 16:44:07 -0700 Message-Id: <199506282344.QAA03892@gator.arc.nasa.gov> X-Mailer: exmh version 1.6 4/21/95 To: "Matt Mathis" Cc: mbone-nsi@nsipo.nasa.gov, mathis@psc.edu, mbone, marty@gator.arc.nasa.gov Subject: Re: Mbone lossage In-Reply-To: Your message of "Wed, 28 Jun 1995 17:40:37 EDT." <9506282140.AA00734@mailer.psc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Jun 1995 16:44:05 -0700 From: "Martin Duda NASA Science Internet" Dan Evans is away, but we are seeing strange behavior between hosts on FIX-WEST and the world. Video is fine on 128.102.32 net. We can run rtpqual with some *assistance* in Dan's absence. From list-mgr@ISI.EDU Wed Jun 28 10:29:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 17:32:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 17:30:23 -0700 Received: from gator.arc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 17:30:22 -0700 Received: from localhost.arc.nasa.gov by gator.arc.nasa.gov (8.6.12/1.5T) id RAA04005; Wed, 28 Jun 1995 17:29:57 -0700 Message-Id: <199506290029.RAA04005@gator.arc.nasa.gov> X-Mailer: exmh version 1.6 4/21/95 To: "Matt Mathis" Cc: mbone-nsi@nsipo.nasa.gov, mathis@psc.edu, mbone, marty@gator.arc.nasa.gov Subject: Re: Mbone lossage In-Reply-To: Your message of "Wed, 28 Jun 1995 17:40:37 EDT." <9506282140.AA00734@mailer.psc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Jun 1995 17:29:56 -0700 From: "Martin Duda NASA Science Internet" OK. Thanks for all the information. We are adding unicast host routes to alleviate the *bottleneck* on tunnels on mbone.nsi. Things should be looking better shortly. From list-mgr@ISI.EDU Wed Jun 28 16:56:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 17:57:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 17:56:13 -0700 Received: from gold.interlog.com by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 28 Jun 1995 17:56:07 -0700 Received: (from ryan@localhost) by gold.interlog.com (8.6.10/8.6.10) id UAA08179; Wed, 28 Jun 1995 20:56:05 -0400 Date: Wed, 28 Jun 1995 20:56:04 -0400 (EDT) From: Ryan Clan Subject: unsubscribe To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From list-mgr@ISI.EDU Fri Jun 30 02:39:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 03:42:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 03:39:20 -0700 Received: from mail.ncku.edu.tw by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 03:39:17 -0700 Received: (from ckwen@localhost) by mail.ncku.edu.tw (8.6.12/8.6.12) id SAA00546; Thu, 29 Jun 1995 18:39:57 +0800 From: Cheng-Kang Wen Message-Id: <199506291039.SAA00546@mail.ncku.edu.tw> Subject: Re: Camera's To: welch@oar.net (Arun Welch) Date: Thu, 29 Jun 1995 18:39:56 +0800 (WST) Cc: mbone In-Reply-To: <199506281430.KAA09643@loki.oar.net> from "Arun Welch" at Jun 28, 95 10:30:08 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 309 Mr. Welch, Currently I applied two kinds of video input devices to work with the Sun VideoPix card. They are Panasonic V8 camera and the camera which comes with SunVideo card and is made by Sony. The V8 has the function of zoom in/out while the SunVideo camera only gets a wide-angle len. Cheng-Kang Wen From list-mgr@ISI.EDU Fri Jun 30 05:33:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 05:32:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 05:30:56 -0700 Received: from sunstation2.tsinghua.edu.cn by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 05:30:47 -0700 Received: from csnet4.tsinghua.edu.cn ([166.111.166.17]) by sunstation2.tsinghua.edu.cn (4.1/SMI-4.1) id AA04979; Thu, 29 Jun 95 20:30:03 CDT Received: by csnet4.tsinghua.edu.cn (5.0/SMI-SVR4) id AA00407; Thu, 29 Jun 1995 20:33:22 --800 Date: Thu, 29 Jun 1995 20:33:19 +0900 (CDT) From: Wu Shangguang To: mbone Subject: [Q] How to mix several audio data stream? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 339 Hi, I'm working on audio tranferring on TCP/IP network. Now I have some problems: 1) How to mix several audio data stream? Which audio coding method do I need for the source data: PCM, ADPCM, A-law, u-law? 2) How to operate on the several source audio data to get the mixed audio data? Any help will be highly appreciated! Andy Wu From list-mgr@ISI.EDU Thu Jun 29 00:02:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 07:02:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 07:01:41 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 07:01:39 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id HAA02595; Thu, 29 Jun 1995 07:02:29 -0700 Message-Id: <199506291402.HAA02595@rx7.ee.lbl.gov> To: mbone Cc: moravan@fairplay.acns.colostate.edu Subject: host vines.colostate.edu trashing shuttle video Date: Thu, 29 Jun 95 07:02:28 PDT From: Van Jacobson Host vines.colostate.edu (129.82.100.101) is sending ICMP unreachables to the Shuttle audio & video addresses and completely trashing the shuttle video. This started happening as soon as a user named moravan@fairplay.acns.colostate.edu started watching the Shuttle session at around 8:30am CDT this morning (about 30 minutes ago). It would be nice if (a) the plug could get pulled on vines.colostate.edu or (b) moravan@fairplay.acns.colostate.edu would stop using the mbone until (a) happens or (c) whoever supplies a tunnel to Colorado State would disconnect the tunnel until either (a) or (b) happens. Thanks. - Van From list-mgr@ISI.EDU Thu Jun 29 00:59:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 07:59:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 07:58:18 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 07:58:17 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id HAA02640; Thu, 29 Jun 1995 07:59:11 -0700 Message-Id: <199506291459.HAA02640@rx7.ee.lbl.gov> To: mbone Subject: could Colorado (Boulder) disconnect the tunnel to Colorado State? Date: Thu, 29 Jun 95 07:59:10 PDT From: Van Jacobson A host at Colorado State (vines.colostate.edu) is sending ICMP unreachables in reponse to all multicast packets. This is causing severe problems on a number of MBone video sessions, including the Shuttle session (where slightly over 350 people are trying to watch the MIR docking). Colorado State doesn't seem to be dealing with this problem. Could whoever runs cabal.colorado.edu please disconnect the tunnel that goes from cabal.Colorado.EDU to matisse.VIS.ColoState.EDU until Colorado State has fixed the problem at their end. Thanks. - Van From list-mgr@ISI.EDU Thu Jun 29 08:29:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 08:29:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 08:29:25 -0700 Received: from ames.arc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 08:29:24 -0700 Received: from qmgate.arc.nasa.gov by ames.arc.nasa.gov with SMTP id AA12875 (5.65b/IDA-1.4.3 for mbone@ISI.EDU); Thu, 29 Jun 95 08:29:23 -0700 Message-Id: Date: 29 Jun 1995 08:32:35 U From: "Gaye Graves" Return-Receipt-To: "Gaye Graves" Subject: unsubscribe To: "mbone" X-Mailer: Mail*Link SMTP-QM 3.0.2 unsubscribe 8:26 AM unsubscribe From list-mgr@ISI.EDU Thu Jun 29 02:05:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 09:11:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 09:11:06 -0700 Received: from neon.netscape.com by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 09:11:04 -0700 Received: (from dmose@localhost) by neon.netscape.com (950215.SGI.8.6.10/8.6.9) id JAA16837; Thu, 29 Jun 1995 09:05:54 -0700 From: Dan Mosedale Message-Id: <199506291605.JAA16837@neon.netscape.com> Subject: Re: URL for multicast channels? To: fenner@parc.xerox.com (Bill Fenner) Date: Thu, 29 Jun 1995 09:05:54 -0700 (PDT) Cc: mbone In-Reply-To: <95Jun25.213845pdt.49859@crevenia.parc.xerox.com> from "Bill Fenner" at Jun 25, 95 09:38:35 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1155 > > In message <3shhkm$25p@flop.mcom.com> you write: > >I'd suggest either changing the default semantics of x-sd to be > >"display the info along with a button to launch", or using x-sd to > >simply provide the info for formatting as a browser sees fit, and then > >having URLs for launching. > > That's a reasonable idea. I had assumed that sdp stuff passed around by > email would come with an explanation, and metamail's "Would you like to > view this data using sd-launch?" would be a sufficient question. My thought is that often it will come with an explanation, but not always. Presumably, once more and better MIME mailers become the norm, someone might typically forward a message with a text part of "hey check out this conference that's coming up:" and an application/x-sd part pointing to the conference, expecting the reader to then go read the description field and hit any URLs mentioned therein. I also usually want to see the media & format info before starting a conference. I typically don't have tools installed to deal with all the media and format types, or sometimes I'm not interested in an audio-only conference, etc. Dan From list-mgr@ISI.EDU Thu Jun 29 04:42:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 09:44:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 09:42:56 -0700 Received: from dozer.Colorado.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 09:42:54 -0700 Received: by dozer.colorado.edu id AA22555 (5.64+/IDA-1.4.4 for mbone@ISI.EDU); Thu, 29 Jun 95 10:42:40 -0600 From: Chris Garner Message-Id: <9506291642.AA22555@dozer.colorado.edu> Subject: Re: host vines.colostate.edu trashing shuttle video To: van@ee.lbl.gov (Van Jacobson) Date: Thu, 29 Jun 1995 10:42:39 -0600 (MDT) Cc: mbone, moravan@fairplay.acns.colostate.edu In-Reply-To: <199506291402.HAA02595@rx7.ee.lbl.gov> from "Van Jacobson" at Jun 29, 95 07:02:28 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 781 > >Host vines.colostate.edu (129.82.100.101) is sending ICMP unreachables >to the Shuttle audio & video addresses and completely trashing the >shuttle video. This started happening as soon as a user named >moravan@fairplay.acns.colostate.edu started watching the Shuttle >session at around 8:30am CDT this morning (about 30 minutes ago). >It would be nice if (a) the plug could get pulled on vines.colostate.edu >or (b) moravan@fairplay.acns.colostate.edu would stop using the >mbone until (a) happens or (c) whoever supplies a tunnel to Colorado >State would disconnect the tunnel until either (a) or (b) happens. >Thanks. > > - Van > > I couldn't get in touch with Michael at CSU, so I shut off their feed. -- -Chris (cgarner@westnet.net) From list-mgr@ISI.EDU Thu Jun 29 03:02:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 10:06:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 10:04:59 -0700 Received: from balder.ssds.com by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 10:04:55 -0700 Received: (from mail@localhost) by balder.ssds.com (8.6.9/8.6.9.SSDSnet-hub) id LAA08343; Thu, 29 Jun 1995 11:02:27 -0600 Received: from denver(134.127.16.1) by balder via smap (V1.3) id sma008341; Thu Jun 29 11:02:26 1995 Received: from sanjose.ssds.com (sanjose.ssds.com [134.127.10.1]) by denver.ssds.com (8.6.9/8.6.9.SSDSnet-hub) with SMTP id LAA28184; Thu, 29 Jun 1995 11:02:24 -0600 Received: by sanjose.ssds.com (5.x/SMI-SVR4) id AA13869; Thu, 29 Jun 1995 10:02:12 -0700 Date: Thu, 29 Jun 1995 10:02:12 -0700 (PDT) From: Chris Swanson X-Sender: cds@sanjose To: Bill Nowicki Cc: mbone Subject: Re: Mbone losses In-Reply-To: <9506281527.ZM28788@tree.engr.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT Greetings, I was the engineer for Carl Malamud at the UN multicast. A couple of times during the multicast we would see all but directly connected BARRNet sites drop off the participants list. BARRNet connected sites stayed on. Regards, -+Chris / Chris Swanson ____/ ____/ ___ / ____/ Engineer ____ / ____ / /__/ / ____ / 8841 Nicollet Ave South _______/ _______/ _______/ _______/ Bloomington, MN 55420 business driven technology solutions. (612) 888-4045 FAX (612) 888-4066 On Wed, 28 Jun 1995, Bill Nowicki wrote: > Date: Wed, 28 Jun 1995 15:27:33 -0700 > From: Bill Nowicki > To: mbone@ISI.EDU > Subject: Mbone losses > > We (SGI) have been seeing large loss rates on almost all mbone > traffic for about the past two weeks. First I thought it was a problem > with our line or Barrnet, but after some help from Barrnet, and the > recent U.N. and Cisco multicasts that had no losses at all, I > now suspect it is something at NASA. We see about 30% loss from NASA, > even though I can see Moffet Field out our window, and unicast > routing is quick through Barrnet. Also seeing many "misordered" > packets in vat. > > Xerox is also about five miles away, and we lose about half of the > packets from them, as well as ISI. As far as I can tell, they both > route through DARTnet, which seems to connect to the rest of the > world at NASA Ames, mbone.nsi.nasa.gov and mbone2.nsi.nasa.gov, etc. > > It is unusable right now; anbody have suggestions? > > -- Bill Nowicki > Silicon Graphics > From list-mgr@ISI.EDU Thu Jun 29 03:51:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 10:52:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 10:51:55 -0700 Received: from popcorn.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 10:51:54 -0700 Received: from Club Young.LLNL.GOV by popcorn.llnl.gov (8.6.10/LLNL-2.0) id KAA22763; Thu, 29 Jun 1995 10:51:53 -0700 Date: Thu, 29 Jun 1995 10:51:53 -0700 Message-Id: <199506291751.KAA22763@popcorn.llnl.gov> X-Sender: e800686@popcorn.llnl.gov X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: seiden1@llnl.gov (Young Seiden) Subject: WIN32S V.1.2 Does anyone know of a mirror site, or a FTP site where I can get WIN32S V.1.2 besides from Microsoft Corp.(their FTP server seems always busy)? Young S. Thanks, Lawrence Livermore Nat'l Lab email: seiden1@llnl.gov phone: (510) 423-7055 From list-mgr@ISI.EDU Thu Jun 29 07:07:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 14:09:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 14:05:06 -0700 Received: from coyote.csusm.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 14:05:00 -0700 Received: by coyote.csusm.edu (AIX 3.2/UCB 5.64/TM-02) id AA38495; Thu, 29 Jun 1995 14:07:14 -0700 Date: Thu, 29 Jun 1995 14:07:14 -0700 (PDT) From: Mark Chorak To: mbone Subject: REPOST SunOS mbone install script Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is the script you requested David. If there is any one else reading this who got mbone working on a IBM RISC 6K running AIX 4.1.2 or has a script for to install it, I would appreciate it. chorak1@coyote.csusm.edu #! /bin/csh -f ######################################################################## # # Copyright 1993 by the Massachusetts Institute of Technology. # All rights reserved. # # Developed by the Intelligent Engineering Systems Laboratory # M.I.T., Cambridge, Massachusetts. # # THIS SOFTWARE IS PROVIDED "AS IS", AND M.I.T. MAKES NO REPRESENTATIONS # OR WARRANTIES, EXPRESS OR IMPLIED. By way of example, but not # limitation, M.I.T. MAKES NO REPRESENTATIONS OR WARRANTIES OF # MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR # THAT THE USE OF THE LISCENCED SOFTWARE OR DOCUMENTATION WILL NOT # INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER # RIGHTS. # # The name of Massachusetts Institute of Technology or M.I.T. may # NOT be used in advertising or publicity pertaining to distribution # of the software. Title to copyright in this software and any # associated documentation shall at all times remain with M.I.T., # and USER agrees to preserve the same. # # Permission to use, copy, modify, and distribute this material # for any purpose and without fee is hereby granted, provided that # the above copyright notice and this permission notice appear in # all copies. # ########################################################################### # Author Info: # ########################################################################### # Jim Culbert # # Research Engineer # # M.I.T Intelligent Engineering Systems Laboratory # # Room 1-272 # # Cambridge, Ma. 02139. # # # # Phone (617) 253-7134 # # e-mail: culbert@iesl.mit.edu # ########################################################################### # Program Info: # ########################################################################### # This script installs the multicast extensions released by parc xerox. # # It relies heavily on their directory structuring. If they change # # the release structure this install will need to be modified. # # # # The Script figures out which kernel release you are running and # # installs the appropriate files. It then builds a config file # # runs config, makes the kernel and optionally installs it for you. # # # # Have Fun. # ########################################################################### set TSTAMP = `date +%T` # Only allow program to run if root. if ( `whoami` != "root") then echo "Must be root to install binaries. ABORT" goto ABORT endif # Must have the patch program to install patches. Do not run # unless you have a patch program!! if ( -e "/usr/local/bin/patch" ) then set PATCH_PROG = /usr/local/bin/patch else if ( -e "/usr/bin/patch" ) then set PATCH_PROG = /usr/bin/patch else echo -n "Enter full path for \"patch\" program: " set resp = $< if ( -e $resp ) then set PATCH_PROG = $resp else echo "Unable to locate patch program. ABORT." goto ABORT endif endif ##################################################################### # Locate the directory where the extensions have been untarred. ##################################################################### set MCAST_DIR = `pwd` echo -n "Directory to find Multicast extensions [$MCAST_DIR]: " set resp = $< if ( $resp != "" ) set MCAST_DIR = $resp ##################################################################### # Get os release information. # obtuse but will work if they change the showrev data locations.... ##################################################################### echo Looking for system release level information........ # 1) First grok output from show rev set OS_REL = `/usr/etc/showrev -a | grep "Release:" | awk '{print $3}'` # 2) Compare this to information in conf.common. If differnt # then something is really funny. Warn the user and let her # choose. set WARN = 0 if ( $OS_REL != `cat /usr/sys/conf.common/RELEASE` ) set WARN = 1 # 3) The kernel is always the best place to check!! Look to see if # the groked string is found in the kernel somewhere. It should be. # If not, then warn and let the user decide. set tmp = `strings /vmunix | grep $OS_REL` if ( "$tmp" == "" ) set WARN = 1 # If strangeness warn.... if ( $WARN == 1 ) then echo "WARNING: Discrepancy found in kernel release information." echo "Default release may be wrong." endif echo -n "Enter Kernel Release [$OS_REL]: " set resp = $< if ( $resp != "" ) set OS_REL = $resp ##################################################################### # Find out if they want to be able to support mrouting. ##################################################################### set MROUTING_FLAG = 0 echo -n "Do you wish to support multicast routing? (y/n) [y]: " set resp = $< if ( $resp != "n" ) set MROUTING_FLAG = 1 ##################################################################### # Get the kernel architecture. ##################################################################### set karch = `arch -k` ##################################################################### # Last chance to chicken out. Show configuration, prompt then go! ##################################################################### echo "Installing multicast extensions for $karch binaries." echo -n "Continue? (y/n) [y]: " set resp = $< if ( $resp == "n" ) then echo "Aborting install..." goto ABORT endif ##################################################################### # Generate the release directory name. Current nomenclature is # sys.sunos41x. Thus all we have to do is pick off the last digit # of the release information and append. Pretty rickety code.... ##################################################################### # This is very "non-protable".... set REL_LEVEL = $OS_REL:e set OS_REL_DIR = sys.sunos41$REL_LEVEL ##################################################################### # Ready to go. First push to the untarred directory. ##################################################################### pushd $MCAST_DIR >&! /dev/null # Existance sanity checks. if ( ! -e $OS_REL_DIR ) then echo "Could not locate extension directory $MCAST_DIR/$OS_REL_DIR" echo ABORT goto ABORT endif cd $OS_REL_DIR set KARCH_OBJ_DIR = $karch.OBJ if ( ! -e $KARCH_OBJ_DIR ) then echo "Could not locate objects for kernel architecture $karch" echo ABORT goto ABORT endif # Ok if we're here, we can proceed to patch the files ##################################################################### # This probably doesn't need to be a macro since this root is # not likely to move around for the sun. On the other hand if # this serves other architectures, it might. User probably desrves # a say in the matter.....Naaaaahhhh. ##################################################################### set INSTALL_ROOT = /usr/sys echo "Patching files in directories under $INSTALL_ROOT node....." echo "" set dirlist = * ##################################################################### # GO! # while( there are more directories ) # if its a directory we're interested in then # goto that directory # for all the files in that directory # Locate corresponding system file # execute appropriate patch/cp manuver # go back to release directory # ##################################################################### # BEGIN DIRECTORY INSTALL LOOP while ( $#dirlist != 0 ) set current = $dirlist[1] # If the file is not a directory, then we do not do anything with it if ( ! -d $current ) then shift dirlist continue endif ####################################################################### # If the file ends in .OBJ, then it is an object file directory. There # may be more than one sunxx.OBJ subdir so discard ones that do no # match your kernel architecture. For all other directories, push # there and begin install loop. ####################################################################### if ( $current:e == "OBJ" ) then if ( $current:r == $karch ) then pushd $current >&! /dev/null set current = $current:r/OBJ else shift dirlist continue endif else pushd $current >&! /dev/null endif ####################################################################### # The following is really anal. Prints out a pretty banner for each # directory subtree that is being installed. Prints out a line of # hash marks as a delimiter, a message and calculates where the # hash mark should be placed at the end of the line. ####################################################################### set dlim = "##########################################################" set mess = "# Installing files for $current" set mess_len = `expr length "$mess"` set dlim_len = `expr length $dlim` @ dlim_len -= $mess_len @ dlim_len-- echo $dlim echo -n "$mess" repeat $dlim_len echo -n " " echo "#" echo $dlim # BEGIN FILE INSTALL LOOP foreach file ( * ) ####################################################################### # # Switch on the file ending. Possible cases are; # # Ending Action # -------------------------------- # .diff Apply diff patch # # .c .o .h install new source or object. # # default complain and do nothing # ####################################################################### switch ( $file:e ) case "diff": if ( -e $INSTALL_ROOT/$current/$file:r ) then echo "" echo -n "Patching " echo -n $INSTALL_ROOT/$current/$file:r echo " with $file" echo "" $PATCH_PROG -N\ $INSTALL_ROOT/$current/$file:r \ $file set patched = $file:r if ( $patched:e == "h" ) then echo "Updating /usr/include/$current/$patched" if ( -e /usr/include/$current/$patched ) then echo -n "Original moved to " echo -n "/usr/include/" echo "$current/$patched.orig.$TSTAMP" mv /usr/include/$current/$patched \ /usr/include/$current/$patched.orig.$TSTAMP endif cp $INSTALL_ROOT/$current/$patched \ /usr/include/$current/$patched endif else echo -n "WARNING: Attempt to patch " echo -n $INSTALL_ROOT/$current/$file:r echo " failed." echo "File did not exist." endif breaksw case "h": if ( -e /usr/include/$current/$file ) then echo "Updating /usr/include/$current/$file" echo -n "Original moved to " echo "/usr/include/$current/$file.orig.$TSTAMP" mv /usr/include/$current/$file \ /usr/include/$current/$file.orig.$TSTAMP cp $file /usr/include/$current/$file endif case "c": case "o": if ( -e $INSTALL_ROOT/$current/$file ) then echo "" echo "Replacing:" echo $INSTALL_ROOT/$current/$file echo "With:" echo `pwd`/$file. echo -n "** Backup made to " echo $INSTALL_ROOT/$current/$file.orig.$TSTAMP \*\* cp $INSTALL_ROOT/$current/$file \ $INSTALL_ROOT/$current/$file.orig.$TSTAMP endif cp $file $INSTALL_ROOT/$current/$file breaksw default: echo -n "Unrecognized file extension " echo $file:e. endsw end # END FILE INSTALL LOOP popd >&! /dev/null shift dirlist end # END DIRECTORY INSTALL LOOP ##################################################################### # If we are supporting mrouting, install the mrouted.conf file. ##################################################################### echo "" if ( $MROUTING_FLAG == 1 ) then echo "Installing and configuring mrouted......" # Get IP address for local host. # set ypup = `ypwhich` set ypup = `ps ax | grep ypbind | grep -v grep` set tmp = `hostname` if ( $#ypup > 0 ) then set localip = `ypcat hosts | grep $tmp | awk '{print $1}'` else set localip = `cat /etc/hosts | grep $tmp | awk '{print $1}'` endif echo -n "Enter local tunnel endpoint address [$localip]: " set resp = $< if ( $resp != "" ) set localip = $resp echo -n "Enter peer address providing tunnel: " set mcast_peer = $< set METRIC = 3 echo -n "Enter tunnel metric for $localip <=> $mcast_peer tunnel " echo -n "[$METRIC]: " set resp = $< if ( $resp != "" ) set METRIC = $resp set THRESH = 1 echo -n "Enter tunnel threshold for $localip <=> $mcast_peer tunnel " echo -n "[$THRESH]: " set resp = $< if ( $resp != "" ) set THRESH = $resp ##################################################################### # Use the example file in mrouted directory to build user's new # configuration. Relies on there being one line in the example # with the keyword "REPLACE" in it!!!! ##################################################################### if ( -e /etc/mrouted.conf ) then echo -n "Found a mrouted.conf in /etc. Moving to " echo mrouted.conf.orig.$TSTAMP mv /etc/mrouted.conf /etc/moroutd.conf.orig.$TSTAMP endif if ( ! -e $MCAST_DIR/mrouted/mrouted.conf ) then echo -n "Could not find template mrouted.conf in" echo " $MCAST_DIR/mrouted. Build yourself. Sorry." else cat $MCAST_DIR/mrouted/mrouted.conf | sed "/REPLACE/ c\\ tunnel $localip $mcast_peer metric $METRIC threshold $THRESH" >! /etc/mrouted.conf endif # Sanity. If distribution changes example so that the REPLACE key # is missing, automatic installation of mrouted.conf will not work. # Need to check for this and warn the user if it happens. set tmp = `diff $MCAST_DIR/mrouted/mrouted.conf /etc/mrouted.conf` if ( "$tmp" == "" ) then echo WARNING: Did not find keyword \"REPLACE\" in example. echo Manually edit /etc/mrouted.conf file. endif ##################################################################### # Install mrouted program. ##################################################################### set MROUTED_LOC = /usr/local echo -n "Enter location for installation of mrouted program " echo -n "[$MROUTED_LOC]: " set resp = $< if ( $resp != "" ) set MROUTED_LOC = $resp if ( ! -e $MCAST_DIR/mrouted/mrouted ) then echo -n "Could not locate " echo $MCAST_DIR/mrouted/mrouted executable. Install yourself. else echo Installing mrouted in $MROUTED_LOC # cp $MCAST_DIR/mrouted/mrouted $MROUTED_LOC endif echo "NOTE: User should modify rc.local to run mrouted on reboots." echo "Files installed. Building kernel." ##################################################################### # All the object have been installed, and the .h and .c files # have been patched. Build that sucker. ##################################################################### #first generate a config file. set MCAST_TEMPL = GENERIC echo -n "Kernel configuration template [$MCAST_TEMPL]: " set resp = $< if ( $resp != "" ) then if ( ! -e $INSTALL_ROOT/$karch/conf/$resp ) then echo "Unable to locate configuration template:" echo $INSTALL_ROOT/$karch/conf/$resp echo using GENERIC else set MCAST_TEMPL = $resp endif endif # Generate a kernel identifier set KNAME = MULTICAST-$OS_REL echo -n "Enter ident for new kernel [$KNAME]: " set resp = $< if ( $resp != "" ) set KNAME = $resp # Move into the system directory for your kernel architecture popd >&! /dev/null pushd $INSTALL_ROOT/$karch >&! /dev/null # Do the config stuff cd conf # Safety precaution. if ( -e $KNAME ) then echo "Old config file $KNAME found. Moving to $KNAME.orig.$TSTAMP" mv $KNAME $KNAME.orig.$TSTAMP endif ##################################################################### # All sun kernels need the INET option set. This is standard # practice (see the README in the config dir). # Look for the INET option entry in the template config file and # and insert new multicasting entries in the output config file. # Change the identifier to the new identifier. ##################################################################### if ( $MROUTING_FLAG == 1 ) then set ROUTING_OPTION = "options MROUTING" else set ROUTING_OPTION = "" endif set IDENT = \"$KNAME\" cat $MCAST_TEMPL | sed -e "/options[\ \ ]INET/ a\\ options MULTICAST # multicast kernel extension\\ $ROUTING_OPTION" -e "/ident/ c\\ ident $IDENT" >! $KNAME # If we don't have a new config file, something went wrong! if ( ! -e $KNAME ) then echo "Config file build failed. Aborting." goto ABORT endif # Run config for the new kernel. echo Running config for new kernel. /etc/config $KNAME # Config will create the build directory when executed. If it isn't # found, something failed in config. if ( ! -d $INSTALL_ROOT/$karch/$KNAME ) then echo "Unable to locate $INSTALL_ROOT/$karch/$KNAME" echo "Problem during config? ABORT" goto ABORT endif ##################################################################### # If we find the directory, go there and build the kernel ##################################################################### cd ../$KNAME echo Making new vmunix..... make if ( ! -e vmunix ) then echo "make failed. go figure...." echo ABORT goto ABORT endif ##################################################################### # If we make it here, we have a new kernel. We prompt the user # as to whether she wants to install it or not. Optionally # reboot after install. ##################################################################### echo "Install and build complete." echo -n "Install new kernel? (y/n) [y]: " set resp = $< if ( $resp != "n" ) then mv /vmunix /vmunix.orig.$TSTAMP cp vmunix /vmunix echo New vmunix installed. echo -n "Reboot? (y/n) [y]: " set resp = $< if ( $resp != "n" ) then /etc/reboot endif else echo "Install new kernel manually and reboot." endif DONE: exit 0 ABORT: exit 1 From list-mgr@ISI.EDU Thu Jun 29 07:43:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 14:45:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 14:43:37 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 14:43:36 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14945(4)>; Thu, 29 Jun 1995 14:43:20 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49860>; Thu, 29 Jun 1995 14:43:15 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Mark Chorak Cc: mbone Subject: Re: REPOST SunOS mbone install script In-Reply-To: Your message of "Thu, 29 Jun 95 14:07:14 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Jun 1995 14:43:01 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun29.144315pdt.49860@crevenia.parc.xerox.com> In message you writ e: >Here is the script... Note that a much-updated version of this script is included with the 3.5 multicast release. You should use the version included in the tar file instead of this one. Bill From list-mgr@ISI.EDU Thu Jun 29 08:41:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 15:48:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 15:47:27 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 29 Jun 1995 15:47:26 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14844(5)>; Thu, 29 Jun 1995 15:41:48 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49860>; Thu, 29 Jun 1995 15:41:39 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: mbone Subject: Re: Mbone lossage In-Reply-To: Your message of "Wed, 28 Jun 95 14:40:37 PDT." <9506282140.AA00734@mailer.psc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Jun 1995 15:41:32 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun29.154139pdt.49860@crevenia.parc.xerox.com> In message <9506282140.AA00734@mailer.psc.edu> Matt Mathis writes: >The tunnel between oday.psc.edu and mbone.nsi.nasa.gov seems to have truly >massive congestion problems right at mbone.nsi.nasa.gov. I have been seeing this problem for over two weeks; it has been extremely difficult for me to track down on my own. I have a wonderful tool, called "mtrace", that would have let me isolate these packet losses long ago, if any of the major routers connected to mbone.nsi.nasa.gov ran a recent version of mrouted (3.3 or better, and preferably 3.6). Problems like this one are inevitable. We had a similar problem inside of PARC recently, which was some kind of physical layer ethernet problem. I used mtrace to isolate the link with the trouble and got it fixed ASAP. If more MBONE routers supported multicast traceroute, I wouldn't have been floundering for two weeks waiting for there to be a big enough session to get enough info from enough people to be sure about where the problem was. Just as a unicast provider would probably never run a unicast router that didn't return ICMP time exceeded messages (i.e. didn't support unicast traceroute), MBONE providers should not run multicast routers that don't support multicast traceroute. The MBONE is quickly outgrowing itself, and without this kind of tool it's getting harder and harder to debug the problems. I'll get off my soapbox now. Bill From list-mgr@ISI.EDU Sat Jul 1 08:24:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 05:27:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 05:24:19 -0700 Received: from vitruvius.arbld.unimelb.EDU.AU by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 05:24:17 -0700 Received: (from darrenr@localhost) by vitruvius.arbld.unimelb.EDU.AU (8.6.12/8.6.12) id WAA17505 for mbone@isi.edu; Fri, 30 Jun 1995 22:24:15 +1000 From: Darren Reed Message-Id: <199506301224.WAA17505@vitruvius.arbld.unimelb.EDU.AU> Subject: 3.6 & 3.5... To: mbone Date: Fri, 30 Jun 1995 22:24:14 +1000 (EST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1021 Using mrouted3.6 over multicast3.5, I had SunOS 4.1.4 reboot today: ran out of mbufs :-/ Sparc5-85, running 4.1.4, multicast3.5 + bpf Should this be expected or is it largely to do with the shuttle ? Jun 30 11:17:01 borromini vmunix: ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue fullle0: WARNING: no mbufs Jun 30 11:17:01 borromini vmunix: le0: out of mbufs - packet dropped Jun 30 11:17:01 borromini vmunix: le0: WARNING: no mbufs Jun 30 11:17:04 borromini vmunix: le0: out of mbufs - packet dropped Jun 30 11:43:00 borromini syslogd: restart Jun 30 11:43:00 borromini vmunix: VAC ENABLED ... Jun 30 11:43:00 borromini vmunix: le0 at SBus slot 5 0x8c00000 pri 6 (onboard) Jun 30 11:43:00 borromini vmunix: le0: AUI Ethernet darren p.s. that syslog message ! From list-mgr@ISI.EDU Fri Jun 30 15:03:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 06:09:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 06:03:32 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 06:03:26 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id OAA07684; Fri, 30 Jun 1995 14:03:07 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id OAA02593; Fri, 30 Jun 1995 14:03:06 +0100 Date: Fri, 30 Jun 1995 14:03:05 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Darren Reed Cc: mbone Subject: Re: 3.6 & 3.5... In-Reply-To: <199506301224.WAA17505@vitruvius.arbld.unimelb.EDU.AU> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 30 Jun 1995, Darren Reed wrote: > Using mrouted3.6 over multicast3.5, I had SunOS 4.1.4 reboot today: > ran out of mbufs :-/ > Sparc5-85, running 4.1.4, multicast3.5 + bpf Have you been reading your mail from this list recently? A mail message was sent out at the beginning of this week regarding precisely this problem and providing a patch for it. I include the mail message below. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From jaw@ucs.ed.ac.uk Fri Jun 27 02:44:50 1995 Status: RO X-Status: Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with SMTP id CAA14424 for ; Tue, 27 Jun 1995 02:44:46 +0100 Received: from sics.se by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 27 Jun 1995 02:44:18 +0100 Received: by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) id AA27241; Tue, 27 Jun 95 03:37:11 +0200 Received: from venera.isi.edu by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA27235; Tue, 27 Jun 95 03:37:07 +0200 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 26 Jun 1995 18:37:03 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 26 Jun 1995 18:37:02 -0700 Received: from gratiano.parc.xerox.com ([13.2.116.55]) by alpha.xerox.com with SMTP id <16987(2)>; Mon, 26 Jun 1995 18:36:58 PDT Received: by gratiano.parc.xerox.com id <177863>; Mon, 26 Jun 1995 18:36:48 -0700 From: Bill Fenner To: mbone@ISI.EDU Subject: Announcing the 3.6 mrouted-only release, and the 3.5June kernel release Message-Id: <95Jun26.183648pdt.177863@gratiano.parc.xerox.com> Date: Mon, 26 Jun 1995 18:36:47 PDT As always ends up happening, there were bugs in the 3.5 multicast code that I released in May. This is to announce a bugfix release of mrouted, as well as some kernel bug fixes. The 3.5June kernel release includes working if_bqe.o files, as well as some .o's with some requested sun patches applied, and a resource depletion fix for ip_mroute.c . The files required to upgrade from the original 3.5 kernel release are available from ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/3.5june-upgrade.tar.Z You do not need to upgrade if you don't want the sun patches or the quad ethernet patches, and if you aren't having mbuf usage problems. The "standard" 3.5 release in ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/ipmulti3.5-sunos41x.tar.Z has been upgraded to include these files as well, so if you were waiting for the sun patches to install, now is the time to install. The 3.6 mrouted runs over a 3.5 kernel. SunOS binaries are available from ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.6-sparc-sunos41x.tar.Z and the source code is available from ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.6.tar.Z You are strongly encouraged to upgrade to 3.6, as it had some multicast traceroute bugs that could hang or kill mrouted. Since there is no kernel upgrade required, upgrading to 3.6 is as simple as ftp'ing the binaries or building the source, killing mrouted and restarting the new one. As always, please let me know of any troubles you might have. Bill From list-mgr@ISI.EDU Sat Jul 1 09:40:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 06:47:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 06:44:09 -0700 Received: from vitruvius.arbld.unimelb.EDU.AU by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 06:44:07 -0700 Received: (from darrenr@localhost) by vitruvius.arbld.unimelb.EDU.AU (8.6.12/8.6.12) id XAA17595; Fri, 30 Jun 1995 23:40:57 +1000 From: Darren Reed Message-Id: <199506301340.XAA17595@vitruvius.arbld.unimelb.EDU.AU> Subject: Re: 3.6 & 3.5... To: Graeme.Wood@ucs.ed.ac.uk Date: Fri, 30 Jun 1995 23:40:56 +1000 (EST) Cc: mbone In-Reply-To: from "Graeme Wood" at Jun 30, 95 02:03:05 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 913 In some email I received from Graeme Wood, sie wrote: > > On Fri, 30 Jun 1995, Darren Reed wrote: > > > Using mrouted3.6 over multicast3.5, I had SunOS 4.1.4 reboot today: > > ran out of mbufs :-/ > > Sparc5-85, running 4.1.4, multicast3.5 + bpf > > Have you been reading your mail from this list recently? A mail message > was sent out at the beginning of this week regarding precisely this > problem and providing a patch for it. I include the mail message below. Hmmm, given that I hadn't seen this problem before, I wasn't expecting it to show up quite like it did. I'm not sure, but it seems like mrouted 3.6 doesn't work that well over multicast3.5 in busy conditions...I wasn't having mbuf problems before today, or more precisely, before changing to mrouted 3.6. If the release for 3.6 had of said that 3.6 over 3.5 wasn't safe, I would have upgraded kernel & mrouted together...(already) darren From list-mgr@ISI.EDU Fri Jun 30 07:29:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 08:32:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 08:29:34 -0700 Received: from oit.gatech.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 08:29:33 -0700 Received: (from ccoprmm@localhost) by oit.gatech.edu (8.6.12/8.6.12) id LAA20199 for mbone@isi.edu; Fri, 30 Jun 1995 11:29:33 -0400 From: Michael.Mealling@oit.gatech.edu (Michael Mealling) Message-Id: <199506301529.LAA20199@oit.gatech.edu> Subject: SGI Vat problem: vat: unknown host 'robin' To: mbone Date: Fri, 30 Jun 1995 11:29:33 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 585 This is the first SGI I've setup MBONE tools on so if this is a FAQ please beat me about the head. All the other tools run fine except for vat which gives me this error: vat: unknown host 'robin' robin is the name of the machine that vat is running on. It is also the nameserver for the whole domain: fernbank.edu. Does this sound familiar to anyone? Thanks! -- ------------------------------------------------------------------------------ Life is a game. Someone wins and someone loses. Get used to it.

Michael Mealling From list-mgr@ISI.EDU Fri Jun 30 03:51:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 10:55:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 10:52:54 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 10:52:52 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14480(2)>; Fri, 30 Jun 1995 10:52:39 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49860>; Fri, 30 Jun 1995 10:51:36 -0700 To: Darren Reed Cc: Graeme.Wood@ucs.ed.ac.uk, mbone Subject: Re: 3.6 & 3.5... In-Reply-To: Your message of "Fri, 30 Jun 95 06:40:56 PDT." <199506301340.XAA17595@vitruvius.arbld.unimelb.EDU.AU> Date: Fri, 30 Jun 1995 10:51:16 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jun30.105136pdt.49860@crevenia.parc.xerox.com> In message <199506301340.XAA17595@vitruvius.arbld.unimelb.EDU.AU> you write: >If the release for 3.6 had of said that 3.6 over 3.5 wasn't safe, I >would have upgraded kernel & mrouted together...(already) 3.6 works exactly as well (poorly) as 3.5 under busy conditions. The problem is the startup transient, which is worse when there is a lot of MBONE traffic (or a lot of load on the machine). Bill From list-mgr@ISI.EDU Fri Jun 30 04:53:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 11:56:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 11:53:50 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 11:53:48 -0700 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with SMTP id LAA05855 for ; Fri, 30 Jun 1995 11:53:41 -0700 Message-Id: <199506301853.LAA05855@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6delta 4/7/95 To: mbone Subject: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Jun 1995 11:53:40 -0700 From: Amancio Hasty subscribe mbone From list-mgr@ISI.EDU Fri Jun 30 09:15:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 14:03:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 14:01:03 -0700 Received: from apollo.hq.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 14:01:02 -0700 Received: from localhost (cshenton@localhost) by apollo.hq.nasa.gov (8.6.12/8.6.12) with SMTP id RAA02519; Fri, 30 Jun 1995 17:15:13 GMT Message-Id: <199506301715.RAA02519@apollo.hq.nasa.gov> X-Authentication-Warning: apollo.hq.nasa.gov: Host localhost didn't use HELO protocol To: Michael.Mealling@oit.gatech.edu (Michael Mealling) Cc: mbone Subject: Re: SGI Vat problem: vat: unknown host 'robin' In-Reply-To: Your message of "Fri, 30 Jun 1995 11:29:33 EDT." <199506301529.LAA20199@oit.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <2515.804532512.1@apollo> Date: Fri, 30 Jun 1995 13:15:13 -0400 From: Chris Shenton On Fri, 30 Jun 1995 11:29:33 -0400 (EDT), Michael.Mealling@oit.gatech.edu (Michael Mealling) said: Michael> All the other tools run fine except for vat which gives me Michael> this error: Michael> vat: unknown host 'robin' Michael> robin is the name of the machine that vat is running on. Michael> Does this sound familiar to anyone? I seem to recall running into this under Irix 4.0.5 when the machine's name was unqualified, eg: `robin'. Problem went away when I changed the machine's name to the FQDN, eg: `robin.oit.gatech.edu'. From list-mgr@ISI.EDU Fri Jun 30 08:20:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 15:23:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 15:20:55 -0700 Received: from eitech.eit.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 15:20:54 -0700 Received: from collage (collage.eit.COM) by eitech.eit.com (4.1/SMI-4.1) id AA19363; Fri, 30 Jun 95 15:20:38 PDT Date: Fri, 30 Jun 95 15:20:38 PDT From: vinay@eit.COM (Vinay Kumar) Message-Id: <9506302220.AA19363@eitech.eit.com> To: fenner@parc.xerox.com Subject: Re: URL for multicast channels? Cc: dmose@neon.netscape.com, mbone Well ! This is what is done using 'mmphone'. It is a MIME multipart parallel+alternate message and each part handles different media type and the application type to launch. Metamail parses the msg. just fine. I had promised Bill at the last IETF to integrate applcation/x-sd into 'mmphone' as well, but haven't gotten around to doing it. Maybe it's time....:) Feel free to send me email personally if you would like to discuss this further. Regards --- Vinay Kumar vinay@eit.com > From list-mgr@ISI.EDU Sun Jun 25 21:55:36 1995 > Delivery-Date: Sun, 25 Jun 1995 21:55:38 -0700 > To: dmose@neon.netscape.com (Dan Mosedale) > Cc: mbone@ISI.EDU > Subject: Re: URL for multicast channels? > Date: Sun, 25 Jun 1995 21:38:35 PDT > Sender: Bill Fenner > From: Bill Fenner > Content-Length: 719 > > In message <3shhkm$25p@flop.mcom.com> you write: > >I'd suggest either changing the default semantics of x-sd to be > >"display the info along with a button to launch", or using x-sd to > >simply provide the info for formatting as a browser sees fit, and then > >having URLs for launching. > > That's a reasonable idea. I had assumed that sdp stuff passed around by > email would come with an explanation, and metamail's "Would you like to > view this data using sd-launch?" would be a sufficient question. > > >One nice feature about leaving the % escapes in place is that one can > >then call the "unescape URL" function... > > Yeah, that's why I proposed it first even though I knew that people were going > to say it was too ugly. > > Bill > From list-mgr@ISI.EDU Fri Jun 30 15:00:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 16:03:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 16:00:38 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 16:00:36 -0700 Received: from BILL-THE-CAT.MIT.EDU by MIT.EDU with SMTP id AA27467; Fri, 30 Jun 95 19:00:34 EDT Received: by bill-the-cat.MIT.EDU (5.0/4.7) id AA03871; Fri, 30 Jun 1995 19:00:34 -0400 Date: Fri, 30 Jun 1995 19:00:34 -0400 Message-Id: <9506302300.AA03871@bill-the-cat.MIT.EDU> To: Chris Shenton Subject: Re: SGI Vat problem: vat: unknown host 'robin' Cc: mbone, Michael.Mealling@oit.gatech.edu (Michael Mealling) From: John Hawkinson Content-Length: 419 > I seem to recall running into this under Irix 4.0.5 when the machine's > name was unqualified, eg: `robin'. Problem went away when I changed > the machine's name to the FQDN, eg: `robin.oit.gatech.edu'. The correct solution is to symlink /usr/etc/resolv.conf to /etc/resolv.conf, since the former is used by IRIX 4 binaries, such as vat. THis generally makes that problem go away. --jhawk@mit.edu John Hawkinson From list-mgr@ISI.EDU Fri Jun 30 10:03:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 18:17:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 18:12:07 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 18:12:02 -0700 Received: from eitech.eit.COM by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 30 Jun 1995 17:05:31 -0700 Received: from collage (collage.eit.COM) by eitech.eit.com (4.1/SMI-4.1) id AA23424; Fri, 30 Jun 95 17:03:51 PDT Date: Fri, 30 Jun 95 17:03:50 PDT From: vinay@eit.COM (Vinay Kumar) Message-Id: <9507010003.AA23424@eitech.eit.com> To: rem-conf@es.net Subject: Imaging On The Internet: Call..... Cc: mbone [Apologize if you are seeing multiple copies] Thought some of you might be interested. Just an FYI. Regards ---- Vinay Kumar vinay@eit.com http://www.eit.com/techinfo/mbone/ CALL FOR PAPERS (Please redistribute) --------------- IMAGING ON THE INTERNET Part of the IS&T/SPIE Symposium on Electronic Imaging: Science And Technology San Jose, California Jan 29 - 31, 1996 ============================================================================ Conference Chairs: Brian C. Smith, Cornell University Lawrence A. Rowe, University of California at Berkeley Program Committee: Shih-Fu Chang Columbia University Wolfgang Effelsberg University of Mannheim Chad Fogg Chromatic Research Ed Fox Virginia Tech Arding Hsu Siemans Research Howard Katseff AT&T Fred Kitson HP Labs Vinay Kumar Enterprise Integration Technologies Tom Little Boston University Sandy Pentland MIT R. P. C. Rogers U.S. National Library of Medicine, NIH Raj Yavatkar University of Kentucky Ramin Zabih Cornell University Polle Zellweger Xerox PARC The proliferation of applications like the World-Wide Web and the Internet Multimedia Backbone (the MBone) has resulted in vast amounts of image and video data traffic on the Internet. This, in turn, has given rise to a host of technical, social, and legal problems relating to creating, publishing, storing, indexing, transmitting, and viewing image and video material on the network. This conference serves as a forum where practitioners and researchers can present and discuss state-of-the-art research, development, and applications that use image and video on the Internet. Papers are solicited in the following areas related to Internet imaging and video, including, but not limited to: o Communication and Operating system issues for Internet image and video o Compression and processing o Language and Environments for Internet image and video applications o Security, including encryption, and copy protection o Applications of images and video on the Internet o Content issues, such as indexing and retrieval o World-Wide Web browsing and authoring tools o User Interfaces for on-line materials o Billing models for accessing and publishing on-line material o Legal issues, including copyright and privacy o Social impact IMPORTANT INFORMATION FOR AUTHORS: --------------------------------- Please submit an extended abstract for review. Submissions should be 500 words or less and no more than 4 pages, including figures, tables, and references. Your extended abstract should include a cover page with the following information: 1. Title of paper 2. Author names and affiliations, principal author first 3. Correspondence address (both postal and electronic) for EACH author 4. Submit to: (Conference Title -- Imaging on the Internet, Conference Chair -- Brian C. Smith) 5. Keywords 6. Brief biography: 50 to 100 words (principal author only) If possible, please print the abstract double sided, to save trees and mailing costs. Please send 5 hard copies of your extended abstract to: Professor Brian C. Smith Department of Computer Science Upson Hall Cornell University Ithaca, NY, 14853 Phone: (607) 257-8120 E-mail: spie96@cs.cornell.edu In addition, send your extended abstract to SPIE in one of the following ways: o Electronic mail: one copy (ASCII format) to abstracts@mom.spie.org o Fax: one copy to SPIE at 360-647-1445 o Surface Mail: 4 hard copies to: IS&T/SPIE EI '96 SPIE, PO Box 10, Bellingham, WA, 98225 Telephone: 360-676-3290; FAX: 360-647-1445 Each extended abstract will be reviewed by at least three members of the program committee. Authors of accepted papers will be asked to submit a camera-ready manuscript (not exceeding 12 pages) that will appear in the conference proceedings. The Conference Chairs and Program Committee will also ask authors of the best papers to enhance their papers and make journal form submissions to the ACM/Springer Verlag Multimedia Systems Journal or tutorial style submissions for IEEE Multimedia Magazine. IMPORTANT DATES: --------------- Submission deadline: July 3, 1995 Notification of acceptance: September 15, 1995 Camera-ready abstracts due: November 13, 1995 Camera-ready manuscripts due: January 2, 1996 From list-mgr@ISI.EDU Fri Jun 30 15:00:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 16:03:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 16:00:38 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU) by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 30 Jun 1995 16:00:36 -0700 Received: from BILL-THE-CAT.MIT.EDU by MIT.EDU with SMTP id AA27467; Fri, 30 Jun 95 19:00:34 EDT Received: by bill-the-cat.MIT.EDU (5.0/4.7) id AA03871; Fri, 30 Jun 1995 19:00:34 -0400 Date: Fri, 30 Jun 1995 19:00:34 -0400 Message-Id: <9506302300.AA03871@bill-the-cat.MIT.EDU> To: Chris Shenton Subject: Re: SGI Vat problem: vat: unknown host 'robin' Cc: mbone, Michael.Mealling@oit.gatech.edu (Michael Mealling) From: John Hawkinson Content-Length: 419 > I seem to recall running into this under Irix 4.0.5 when the machine's > name was unqualified, eg: `robin'. Problem went away when I changed > the machine's name to the FQDN, eg: `robin.oit.gatech.edu'. The correct solution is to symlink /usr/etc/resolv.conf to /etc/resolv.conf, since the former is used by IRIX 4 binaries, such as vat. THis generally makes that problem go away. --jhawk@mit.edu John Hawkinson From list-mgr@ISI.EDU Sun Jul 2 17:09:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 2 Jul 1995 04:11:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 2 Jul 1995 04:10:30 -0700 Received: from mits.mdata.fi by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 2 Jul 1995 04:10:09 -0700 Received: (setala@localhost) by mits.mdata.fi (8.6.12/8.6.5) id OAA15386 for mbone@isi.edu; Sun, 2 Jul 1995 14:09:57 +0300 From: Saku Setala Message-Id: <199507021109.OAA15386@mits.mdata.fi> Subject: Packet duplication on NASA session To: mbone Date: Sun, 2 Jul 1995 14:09:57 +0300 (EET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 107 Currently, my nv reports ~ 200kbps on Nasa session, with up to ~ -45% loss. Pretty strange, huh? --Saku From list-mgr@ISI.EDU Mon Jul 3 10:54:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 01:56:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 01:54:52 -0700 Received: from tamdhu.dcs.st-andrews.ac.uk (tamdhu.dcs.st-and.ac.uk) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 01:54:43 -0700 Received: from bushmills.dcs.st-and.ac.uk by tamdhu.dcs.st-andrews.ac.uk (4.1/SMI-4.1) id AA20988; Mon, 3 Jul 95 09:56:05 BST Message-Id: <9507030856.AA20988@tamdhu.dcs.st-andrews.ac.uk> To: mbone Subject: Strange problem with mrouted machine Date: Mon, 03 Jul 1995 09:54:39 +0100 From: "Paul Harrington" {powers,turret}.dcs.st-and.ac.uk is a mrouter running 3.5 (haven't got around to upgrading it yet). It also runs as an nn 'headers only' news server which gets its feed from a local computing services machine which can spew out headers at wildly varying rates: often the lab machine crashes, loses its history and takes articles from anywhere. My setup runs a short exprire on the headers and can often get floods of old articles. So what has this to do with mrouted? Well, as you can see from the following trace, mrouted gets a fault which causes a panic. These panics are always preceded by the optimisation messages and these messages appear to be caused by swings in the disk consumption on var of nn. I don't have any swapping configured on var. The var partition does not overlap with any other. I have not yet tried a newfs with optimisation set one way or another. Any ideas? pjjH Paul Harrington, phrrngtn@dcs.st-andrews.ac.uk +44 1334 463261 Division of Computer Science, St Andrews University, Scotland KY16 9SS SunOS powers 4.1.3 1 sun4c System Model : SPARCstation 1+ (4/65) Main Memory : 24 MB Virtual Memory : 71 MB ROM Version : 1.3 /var: optimization changed from SPACE to TIME /var: optimization changed from TIME to SPACE /var: optimization changed from SPACE to TIME BAD TRAP pid 194, `mrouted': Data fault kernel read fault at addr=0x390, pme=0x0 Sync Error Reg 80 pc=0xf81147ac, sp=0xf8361c28, psr=0x4000c1, context=0x5 g1-g7: 0, 0, ffffff80, 3, f8362000, f8184000, f8184000 Begin traceback... sp = f8361c28 Called from f8049dcc, fp=f8361c88, args=800ae3 f8242438 f8157c00 0 3 f7ffff4c Called from f8066514, fp=f8361ce8, args=f8190040 1a f7ffffbc 100 1a f8244198 Called from f8064f5c, fp=f8361d48, args=ff64bc38 0 0 0 1 240 Called from f806813c, fp=f8361da8, args=ff64bc0c f8361e0c f8361e20 0 4000 1000 Called from f8067f10, fp=f8361e38, args=240 f8240bac 240 240 1 f8361e9c Called from f812d120, fp=f8361ec0, args=f8361fe0 3e8 f8166168 f8166550 f8362000 f8361fe0 Called from f8005a54, fp=f8361f58, args=f8362000 f8361fb4 f8361fe0 f8362000 f8362000 f8361fb4 Called from 4810, fp=f7fffee8, args=4 e508 240 0 0 f7ffff4c End traceback... panic: Data fault syncing file systems... done From list-mgr@ISI.EDU Mon Jul 3 00:44:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 07:44:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 07:43:51 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 07:43:50 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id HAA07655; Mon, 3 Jul 1995 07:44:09 -0700 Message-Id: <199507031444.HAA07655@rx7.ee.lbl.gov> To: Saku Setala Cc: mbone Subject: Re: Packet duplication on NASA session In-Reply-To: Your message of Sun, 02 Jul 95 14:09:57 JDT. Date: Mon, 03 Jul 95 07:44:09 PDT From: Van Jacobson > Currently, my nv reports ~ 200kbps on Nasa session, with up to > ~ -45% loss. > > Pretty strange, huh? I wish it were unusual. Ever since cisco's PIM got widely deployed, the number of duplicate packets on the MBone has skyrocketed & a 45% dup rate is actually lower than normal. I find that almost all the traffic coming from Europe & the UK is duplicated at least once. The duplicates you're seeing are probably due to either - A PIM cloud hooked to the MBone at two or more topologically distinct points or - Someone trying to use a PIM cloud as an MBone transit net. Neither of these things will work. But, despite numerous pious claims from cisco that they have told their customers these things won't work, several major providers & backbone sites keep trying them. I would guess that the duplicates you're seeing are happening either in Stockholm or near mae-east in the US (there are pim routers both places). Someone needs to look at the traffic going into & coming out of the international links to localize it better. FYI, I'm not seeing any duplicates on the NASA session but, of course, there aren't any pim routers between NASA & my workstation. - Van From list-mgr@ISI.EDU Mon Jul 3 19:24:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 08:27:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 08:26:50 -0700 Received: from www.fh-lueneburg.de (rzserv5.fh-lueneburg.de) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 08:26:16 -0700 Received: by www.fh-lueneburg.de (AIX 3.2/UCB 5.64/4.03) id AA25013; Mon, 3 Jul 1995 17:24:50 +0200 Date: Mon, 3 Jul 1995 17:24:50 +0200 From: seen@www.fh-lueneburg.de Message-Id: <9507031524.AA25013@www.fh-lueneburg.de> To: mbone Subject: unsubscribe Cc: seen@www.fh-lueneburg.de Please unsubscribe me from the mailing-list ! From list-mgr@ISI.EDU Mon Jul 3 10:03:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 11:05:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 11:04:02 -0700 Received: from mailer.jhuapl.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 11:04:01 -0700 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA26776; Mon, 3 Jul 1995 14:03:16 -0400 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA25184; Mon, 3 Jul 1995 14:03:14 -0400 Date: Mon, 3 Jul 1995 14:03:14 -0400 (EDT) From: Jim Bogard BIX To: Van Jacobson Cc: Saku Setala , mbone Subject: Re: Packet duplication on NASA session In-Reply-To: <199507031444.HAA07655@rx7.ee.lbl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 652 > The duplicates you're seeing are probably due to either > > - A PIM cloud hooked to the MBone at two or more topologically > distinct points or This I understand. > - Someone trying to use a PIM cloud as an MBone transit net. This, I do not. Although it doesn't seem terribly sensible, Why would this cause duplicate packets? (I assume you mean the following:) tunnel--->machine a--[ PIM cloud ]---machine b---> tunnel out with no unicast tunnel through the PIM cloud... J-. ---- Jim Bogard JHU/APL BIX Group "This is my banjo. There are many Backbone Network Engineer like it, but this one is mine." From list-mgr@ISI.EDU Mon Jul 3 11:07:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 12:14:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 12:07:50 -0700 Received: from wizard.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 12:07:49 -0700 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA08849; Mon, 3 Jul 95 15:07:41 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9507031907.AA08849@wizard.gsfc.nasa.gov> Subject: Re: Strange problem with mrouted machine To: phrrngtn@dcs.st-and.ac.uk (Paul Harrington) Date: Mon, 3 Jul 1995 15:07:40 -0400 (EDT) Cc: mbone In-Reply-To: <9507030856.AA20988@tamdhu.dcs.st-andrews.ac.uk> from "Paul Harrington" at Jul 3, 95 09:54:39 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5459 I am getting similar errors on mbone-cf.gsfc.nasa.gov which is running mrouted 3.4, but they aren't being seen on mbone2-f.gsfc.nasa.gov. They first started showing up on June 16, and here are the dates and times they have occurred (all times are EDT): Jun 16 15:26:06 Jun 16 20:11:14 Jun 19 09:36:06 Jun 19 18:35:53 Jun 20 14:07:35 Jun 20 14:49:32 Jun 22 09:23:01 Jun 22 11:51:52 Jun 26 20:41:37 Jun 28 00:50:46 Jun 28 01:13:34 Jun 28 07:30:23 Jun 28 17:02:39 Jun 29 09:46:40 Jun 29 15:56:51 Jun 29 18:32:11 Jun 30 05:53:55 Jun 30 12:21:44 Jun 30 17:51:50 Jul 1 00:35:17 Jul 1 05:55:23 Jul 1 12:57:10 Jul 2 12:58:56 Jul 3 01:37:42 Jul 3 05:44:50 Jul 3 13:53:59 And here's the most recent error message: Jul 3 13:53:59 mbone vmunix: BAD TRAP Jul 3 13:53:59 mbone vmunix: pid 124, `mrouted': Data fault Jul 3 13:53:59 mbone vmunix: kernel read fault at addr=0xa, pme=0x0 Jul 3 13:53:59 mbone vmunix: Sync Error Reg 80 Jul 3 13:53:59 mbone vmunix: pc=0xf801d938, sp=0xf8152e80, psr=0x908007c7, context=0x2 Jul 3 13:53:59 mbone vmunix: g1-g7: 908007e0, f8191c00, fce22d78, fce52d68, f82ab000, f8186000, f8186000 Jul 3 13:53:59 mbone vmunix: Begin traceback... sp = f8152e80 Jul 3 13:53:59 mbone vmunix: Called from f8042030, fp=f8152ee0, args=ff64ff00 86 ff64d300 2e ff64f900 0 Jul 3 13:53:59 mbone vmunix: Called from f804ad84, fp=f8152f40, args=40 f801d838 0 ff64ff00 908001e1 f82411a0 Jul 3 13:53:59 mbone vmunix: Called from f8005ca8, fp=f8152fa0, args=1 ff007000 f8041fb0 40 908001e2 f81925cc Jul 3 13:53:59 mbone vmunix: Called from 52dc, fp=f82aac28, args=4 103d8 240 0 0 f7ffff28 Jul 3 13:53:59 mbone vmunix: End traceback... Jul 3 13:53:59 mbone vmunix: panic: Data fault Jul 3 13:53:59 mbone vmunix: syncing file systems... done Jul 3 13:53:59 mbone vmunix: 00000 low-memory static kernel pages Jul 3 13:53:59 mbone vmunix: 00907 additional static and sysmap kernel pages Jul 3 13:53:59 mbone vmunix: 00000 dynamic kernel data pages Jul 3 13:53:59 mbone vmunix: 00084 additional user structure pages Jul 3 13:53:59 mbone vmunix: 00000 segmap kernel pages Jul 3 13:53:59 mbone vmunix: 00000 segvn kernel pages Jul 3 13:53:59 mbone vmunix: 00239 current user process pages Jul 3 13:53:59 mbone vmunix: 00041 user stack pages Jul 3 13:53:59 mbone vmunix: 01271 total pages (1271 chunks) Jul 3 13:53:59 mbone vmunix: Jul 3 13:53:59 mbone vmunix: dumping to vp fce0cb2c, offset 69728 Jul 3 13:53:59 mbone vmunix: 1271 total pages, dump succeeded Jul 3 13:53:59 mbone vmunix: rebooting... mrouted is usually the process which experiences the data fault, but occasionally it's another process which is using /dev/nit and once it was tcpdump which also uses /dev/nit. The same kernel has been running since January 17, and as indicated earlier, the kernel crashing problem didn't start until June 16, and has occurred semi-regularly since then. Have others also seen these 'Data fault' kernel panics or have any idea what might be causing them? -Bill P.S. mbone-cf.gsfc.nasa.gov is a Sun SPARCstation-IPX (sun4c) running SunOS 4.1.3. > {powers,turret}.dcs.st-and.ac.uk is a mrouter running 3.5 (haven't got > around to upgrading it yet). It also runs as an nn 'headers only' news > server which gets its feed from a local computing services machine > which can spew out headers at wildly varying rates: often the lab > machine crashes, loses its history and takes articles from anywhere. > My setup runs a short exprire on the headers and can often get floods > of old articles. > > So what has this to do with mrouted? Well, as you can see from the > following trace, mrouted gets a fault which causes a panic. These > panics are always preceded by the optimisation messages and these > messages appear to be caused by swings in the disk consumption on var > of nn. > > I don't have any swapping configured on var. > The var partition does not overlap with any other. > I have not yet tried a newfs with optimisation set one way or another. > > Any ideas? > > pjjH > Paul Harrington, phrrngtn@dcs.st-andrews.ac.uk +44 1334 463261 > Division of Computer Science, St Andrews University, Scotland KY16 9SS > > > SunOS powers 4.1.3 1 sun4c > System Model : SPARCstation 1+ (4/65) > Main Memory : 24 MB > Virtual Memory : 71 MB > ROM Version : 1.3 > > /var: optimization changed from SPACE to TIME > /var: optimization changed from TIME to SPACE > /var: optimization changed from SPACE to TIME > BAD TRAP > pid 194, `mrouted': Data fault > kernel read fault at addr=0x390, pme=0x0 > Sync Error Reg 80 > pc=0xf81147ac, sp=0xf8361c28, psr=0x4000c1, context=0x5 > g1-g7: 0, 0, ffffff80, 3, f8362000, f8184000, f8184000 > Begin traceback... sp = f8361c28 > Called from f8049dcc, fp=f8361c88, args=800ae3 f8242438 f8157c00 0 3 f7ffff4c > Called from f8066514, fp=f8361ce8, args=f8190040 1a f7ffffbc 100 1a f8244198 > Called from f8064f5c, fp=f8361d48, args=ff64bc38 0 0 0 1 240 > Called from f806813c, fp=f8361da8, args=ff64bc0c f8361e0c f8361e20 0 4000 1000 > Called from f8067f10, fp=f8361e38, args=240 f8240bac 240 240 1 f8361e9c > Called from f812d120, fp=f8361ec0, args=f8361fe0 3e8 f8166168 f8166550 f8362000 f8361fe0 > Called from f8005a54, fp=f8361f58, args=f8362000 f8361fb4 f8361fe0 f8362000 f8362000 f8361fb4 > Called from 4810, fp=f7fffee8, args=4 e508 240 0 0 f7ffff4c > End traceback... > panic: Data fault > syncing file systems... done From list-mgr@ISI.EDU Mon Jul 3 11:27:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 12:24:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 12:23:58 -0700 Received: from igate1.hac.com by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 3 Jul 1995 12:23:53 -0700 Received: from EDEN1.HAC.COM by igate1.hac.com (4.1/SMI-4.1) id AA22875; Mon, 3 Jul 95 12:21:57 PDT Received: from eos.hitc.com by EDEN1.HAC.COM (PMDF V4.3-13 #5884) id <01HSFM2MA7DC008LN3@EDEN1.HAC.COM>; Mon, 03 Jul 1995 12:23:42 -0800 (PST) Received: from shark.HITC.COM.eosdis by eos.hitc.com (4.1/SMI-4.1) id AA04102; Mon, 3 Jul 95 15:28:30 EDT Date: Mon, 03 Jul 1995 15:27:05 -0400 (EDT) From: cttsai@eos.hitc.com (Ching-Tien Tsai) Subject: API for group communication To: mbone Message-Id: <9507031928.AA04102@eos.hitc.com> X-Mailer: ELM [version 2.2 PL0] Content-Transfer-Encoding: 7BIT Hi, Can anyone tell me where I can find APIs or example programs to support group communications. This API should be able to receive and send IGMP multicast packets, and allow a non-multicast host to join the group. That is the API shall allow unicast and multicast communication within a single group. Any host should be able to join or leave a group without interrupting the group communications. The data received from this group can be unreliable and unordered. Thanks. Ching Hughes Information Technology Corp. cttsai@eos.hitc.com From list-mgr@ISI.EDU Wed Jul 5 21:08:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 4 Jul 1995 20:11:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 4 Jul 1995 20:06:20 -0700 Received: from garam.kreonet.re.kr by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 4 Jul 1995 20:06:06 -0700 Received: (from chkim@localhost) by garam.kreonet.re.kr (8.6.9H1/8.6.9) id MAA23117; Wed, 5 Jul 1995 12:08:45 +0900 From: System Administrator# Message-Id: <199507050308.MAA23117@garam.kreonet.re.kr> Subject: help me To: staff Date: Wed, 5 Jul 1995 12:08:44 +0900 (KST) Cc: chkim@garam.kreonet.re.kr (System Administrator#), mbone X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 1184 Dear Staffs; I have some problem. I need your help. I'm a staff in KREONet( Korea Research Environment Open Network ), which is one of the largest research network in Korea. I'm trying to use mbone service, i got the following error message. #mrouted :can't forward: only one enabled vif ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cf) Our host spec. IP Address : 134.75.30.5 SYSTEM; Sun SPARC Station 10/51 Main Memory: 64Mb Release: 5.4 Kernel architecture: sun4m Application architecture: sparc Hardware provider: Sun_Microsystems Domain: kreonet.re.kr Kernel version: SunOS 5.4 prefcs4_a June 1994 Sunvideo : Multimedia kit Sun speaker/Sun Camera/Sun Microphone Environment; #ls -alx /etc/mr* $)C -r-xr-xr-x 1 root other 224184 7?y 3 10:18 /etc/mrouted -r-xr-xr-x 1 root other 173 7?y 5 10:17 /etc/mrouted.conf -rw-r--r-- 1 root other 6 7?y 5 10:17 /etc/mrouted.pid #ls -alx ivs -rwx------ 1 root staff 1575184 7?y 4 11:14 ivs ----> ivs3.5 #cat /etc/mrouted.conf tunnel 134.75.30.5 134.75.30.71 metric 1 threshold 190 Thanks for your help. ------------------------------------------------------------------------------ From list-mgr@ISI.EDU Wed Jul 5 21:13:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 4 Jul 1995 20:15:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 4 Jul 1995 20:10:42 -0700 Received: from garam.kreonet.re.kr by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 4 Jul 1995 20:10:24 -0700 Received: (from chkim@localhost) by garam.kreonet.re.kr (8.6.9H1/8.6.9) id MAA23215 for mbone@isi.edu; Wed, 5 Jul 1995 12:13:05 +0900 From: System Administrator# Message-Id: <199507050313.MAA23215@garam.kreonet.re.kr> Subject: help me (fwd) To: mbone Date: Wed, 5 Jul 1995 12:13:05 +0900 (KST) X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 1731 Forwarded message: > From chkim Wed Jul 5 12:09 KST 1995 > From: System Administrator# > Message-Id: <199507050308.MAA23117@garam.kreonet.re.kr> > Subject: help me > To: staff@ISI.EDU > Date: Wed, 5 Jul 1995 12:08:44 +0900 (KST) > Cc: chkim (System Administrator#), mbone@ISI.EDU > X-Mailer: ELM [version 2.4 PL21-h4] > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; charset=iso-2022-kr > Content-Length: 1184 > > Dear Staffs; > > I have some problem. > I need your help. > I'm a staff in KREONet( Korea Research Environment Open Network ), > which is one of the largest research network in Korea. > I'm trying to use mbone service, i got the following error message. > > #mrouted > > :can't forward: only one enabled vif > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > cf) Our host spec. > > IP Address : 134.75.30.5 > > SYSTEM; Sun SPARC Station 10/51 > Main Memory: 64Mb > Release: 5.4 > Kernel architecture: sun4m > Application architecture: sparc > Hardware provider: Sun_Microsystems > Domain: kreonet.re.kr > Kernel version: SunOS 5.4 prefcs4_a June 1994 > > Sunvideo : Multimedia kit > Sun speaker/Sun Camera/Sun Microphone > > Environment; > > #ls -alx /etc/mr* $)C > -r-xr-xr-x 1 root other 224184 7?y 3 10:18 /etc/mrouted > -r-xr-xr-x 1 root other 173 7?y 5 10:17 /etc/mrouted.conf > -rw-r--r-- 1 root other 6 7?y 5 10:17 /etc/mrouted.pid > #ls -alx ivs > -rwx------ 1 root staff 1575184 7?y 4 11:14 ivs ----> ivs3.5 > #cat /etc/mrouted.conf > tunnel 134.75.30.5 134.75.30.71 metric 1 threshold 190 > > Thanks for your help. > > ------------------------------------------------------------------------------ > > From list-mgr@ISI.EDU Wed Jul 5 10:58:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 5 Jul 1995 00:04:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 4 Jul 1995 23:59:12 -0700 Received: from bosun.wblab.lu.se by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 4 Jul 1995 23:59:09 -0700 Received: from bosun.wblab.lu.se (localhost [127.0.0.1]) by bosun.wblab.lu.se (8.7.Beta.7/8.7.Beta.7) with ESMTP id IAA15178; Wed, 5 Jul 1995 08:58:40 +0200 (CED) Message-Id: <199507050658.IAA15178@bosun.wblab.lu.se> X-Mailer: exmh version 1.6.1 5/23/95 To: System Administrator# Cc: staff, mbone Subject: Re: help me In-Reply-To: Your message of "Wed, 05 Jul 1995 12:08:44 +0900." <199507050308.MAA23117@garam.kreonet.re.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Jul 1995 08:58:40 +0200 From: Tomas Gradin >#mrouted > >:can't forward: only one enabled vif >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >#cat /etc/mrouted.conf >tunnel 134.75.30.5 134.75.30.71 metric 1 threshold 190 My educated guess would be that your host's netmask is 255.255.0.0. Try 255.255.255.0 instead. With 0xffff0000, mrouted assumes that 134.75.30.71 is local, and thus needs no tunneling. Hence, that vif coincides with your physical interface, and no traffic occurs. BTW., I would suggest lowering that threshold quite a bit. 190 doesn't make any sense, since that means that NO traffic will pass the tunnel, unless it has a TTL of at least 191. TTL 191 = galaxy-wide broadcast :-) Best Regards, Tomas G. From list-mgr@ISI.EDU Wed Jul 5 16:05:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 5 Jul 1995 07:07:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 5 Jul 1995 07:05:39 -0700 Received: from swan.cl.cam.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 5 Jul 1995 07:05:34 -0700 Received: from bescot.cl.cam.ac.uk (user pb (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Wed, 5 Jul 1995 15:05:15 +0100 X-Mailer: exmh version 1.6.1-TEST 28/6/95 To: mbone Subject: new URL to look at the versions of mrouted out there .... X-Uri: X-Face: &@N3QE9h|>f`igFCkZ'a1`z=nNLXb}k>H(79G"V?@!&*yn)uhPBctF1vc}LD'{OA%$bs X+l[wN,I^G8kKj2NFxQrr@1C4QBC]hq5-%ZkV,^Zl/qE<0`zCQ1nM+]-N<^WG[H)]?d) A:L9AFgOU[BjbaY)uBAMz}h!fm^O0# Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Jul 1995 15:05:07 +0100 From: Piete Brooks Message-Id: <"swan.cl.cam.:254060:950705140520"@cl.cam.ac.uk> After a simple looking request last night: Would it be possible to include a version statistic page to the statistics available from the www-server you administer? (you seem to poll all the mrouteds anyway) I'm looking for something like: 25% 2.2 20% 3.0 5% 3.3 the spec has grown and grown, adding things like the ability to select the domain, to enumerate the hosts [ d*mn users are never satisfied :-) ]. Still to come is sorting of the enumerated list of mrouted's. However, I thought I'd let people have a play with it in its present form to get some feedback as to whether is wandering in the right direction. It is in a state of flux, so please do not save copies of the referenced URLs, but please indirect through http://www.cl.cam.ac.uk/mbone/#mr-vers until it is no longer a "NEW: " entry at the top of the page. Being a lynx user most of the time, a Mosaic user when using exmh (etc), and a netscape user when playing, it has table and non-table versions in the page. From list-mgr@ISI.EDU Wed Jul 5 09:36:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 5 Jul 1995 16:40:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 5 Jul 1995 16:37:37 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 5 Jul 1995 16:37:35 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14436(4)>; Wed, 5 Jul 1995 16:37:25 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49860>; Wed, 5 Jul 1995 16:37:12 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Tomas Gradin Cc: System Administrator# , mbone, fenner@parc.xerox.com Subject: Re: help me In-Reply-To: Your message of "Tue, 04 Jul 95 23:58:40 PDT." <199507050658.IAA15178@bosun.wblab.lu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 5 Jul 1995 16:36:59 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jul5.163712pdt.49860@crevenia.parc.xerox.com> In message <199507050658.IAA15178@bosun.wblab.lu.se> you write: >>#cat /etc/mrouted.conf >>tunnel 134.75.30.5 134.75.30.71 metric 1 threshold 190 > >My educated guess would be that your host's netmask is 255.255.0.0. Try >255.255.255.0 instead. In fact, even with a netmask of 255.255.255.0, the hosts 134.75.30.5 and 134.75.30.71 are on the same subnet. What is the output of "mrouted -d 3"? How about "ifconfig -a"? And why are you trying to run a tunnel between two hosts on the same subnet? Bill From list-mgr@ISI.EDU Thu Jul 6 13:49:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 03:36:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 03:30:43 -0700 Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 03:30:29 -0700 Message-Id: <199507061030.AA07582@venera.isi.edu> Received: from rockmaster (actually rockmaster.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Thu, 6 Jul 1995 11:52:06 +0200 X-Mailer: exmh version 1.6.1 5/23/95 To: mbone Subject: Wrapped German Reichstag: Christo & Jean-Claude press conference Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Jul 1995 11:49:57 +0200 From: Bernd Deffner Announcement: ------------- On July 10, 16:00 -18:00 GMT, we will retransmit the press conference of Christo & Jeanne-Claude who wrapped the German Reichstag. The Wrapped Reichstag art project is an outstanding cultural event for Berlin, Germany and maybe you. MBone Tools: ----------------- Video: vic (h261 (maybe nv), 128 kbit/s) Audio: nevot (vat-Protocol, PCM, 64 kbit/s) used TTL 127 More Information: ----------------- For more information about the Wrapped Reichstag and the press conference Mbone transmission (this is under construction) look at http://www.kulturbox.de/christo/reichs_d.html The transmission is also announced in the sd session directory: multicast address: 224.2.183.135 audio port : 65393 video port : 38142 Regards Bernd Deffner --- Bernd Deffner email: deffner@fokus.gmd.de GMD-Fokus phone: +49 30 25499 170 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin URL: http://www.fokus.gmd.de/step/employees/def From list-mgr@ISI.EDU Thu Jul 6 08:14:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:17:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:16:56 -0700 Received: from prom.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:16:55 -0700 Received: (dschluss@localhost) by prom.engin.umich.edu (8.6.12/8.6.4) id MAA19434; Thu, 6 Jul 1995 12:16:32 -0400 Date: Thu, 6 Jul 1995 12:14:46 -0400 (EDT) From: "david a. schlussel" Subject: Re: help me To: Bill Fenner Cc: Tomas Gradin , System Administrator# , mbone, fenner@parc.xerox.com In-Reply-To: <95Jul5.163712pdt.49860@crevenia.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Jul 1995, Bill Fenner wrote: > In message <199507050658.IAA15178@bosun.wblab.lu.se> you write: > >>#cat /etc/mrouted.conf > >>tunnel 134.75.30.5 134.75.30.71 metric 1 threshold 190 > > > >My educated guess would be that your host's netmask is 255.255.0.0. Try > >255.255.255.0 instead. > > In fact, even with a netmask of 255.255.255.0, the hosts 134.75.30.5 and > 134.75.30.71 are on the same subnet. > > What is the output of "mrouted -d 3"? How about "ifconfig -a"? And why are > you trying to run a tunnel between two hosts on the same subnet? > > Bill > > Why shouldn't you try to run a tunnel between two hosts on the same subnet. I was given a feed, and, time permitting, wanted to set up a separate multicasting reflector on another machine on our subnet. Should i not do this? why? From list-mgr@ISI.EDU Thu Jul 6 02:39:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:40:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:39:35 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:39:35 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15455(5)>; Thu, 6 Jul 1995 09:39:20 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49860>; Thu, 6 Jul 1995 09:39:09 -0700 To: "david a. schlussel" Cc: mbone Subject: Re: tunnel between hosts on the same subnet In-Reply-To: Your message of "Thu, 06 Jul 95 09:14:46 PDT." Date: Thu, 6 Jul 1995 09:39:05 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jul6.093909pdt.49860@crevenia.parc.xerox.com> In message you write: >Why shouldn't you try to run a tunnel between two hosts on the same >subnet. If you have two multicast routers on the same subnet, they will use the native multicasting of the subnet to communicate with each other, thus no need to configure a tunnel. For this reason, mrouted will ignore any tunnel between machines on the same subnet. This means you can still install another multicast router on the subnet, it just means that you don't have to configure a tunnel for it. Bill From list-mgr@ISI.EDU Fri Jul 7 10:30:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 23:36:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 23:30:51 -0700 Received: from pobox.cscs.ch by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 23:30:49 -0700 Received: from cscs.ch by pobox.cscs.ch with SMTP inbound id <13849-0@pobox.cscs.ch>; Fri, 7 Jul 1995 08:30:30 +0200 Received: from monte (monte [148.187.160.20]) by piora-ether.cscs.ch (8.6.10/8.6.10) with SMTP id IAA00685 for ; Fri, 7 Jul 1995 08:30:28 +0200 From: Stefano Klett Received: by monte (5.x) id AA02935; Fri, 7 Jul 1995 08:30:27 +0200 Date: Fri, 7 Jul 1995 08:30:27 +0200 Message-Id: <9507070630.AA02935@monte> To: mbone Subject: Re: NP FDDI SBus card & Multicast 3.5 X-Sun-Charset: US-ASCII I have the same problem. Please help me. Tanks Stefano > > > Hi everybody, > > we have run the np_install script to install a NP's S-Bus FDDI card on our > SPARCstation 10. The machine is running SunOS-4.1.3, with the 3.5 multicasting code > installed. During the installation we replied "y" the question: > > "Has your system been modified to use IP MULTICAST applications [y|n]?" > > At the end, in the np_install.log file we got the following messages: > > ........... > Making new vmunix ... > > > ld: Undefined symbol > _addmultiaddr > _delmultiaddr > *** Error code 2 > make: Fatal error: Command failed for target `vmunix' > > ........... > > The vmunix produced is ok, but we can't see the other machines on the FDDI net. > > I'd appreciate any help to fix the problem. > Thank you in advance. > > From list-mgr@ISI.EDU Fri Jul 7 02:21:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 02:26:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 02:21:22 -0700 Received: from Bulldog.Stupi.SE (Relay.Stupi.SE) by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 02:21:17 -0700 Received: from junk.stupi.se(192.108.198.200) by Bulldog.Stupi.SE id sma021264; Fri Jul 7 11:20:58 1995 Date: Fri, 7 Jul 95 11:20:56 MET DST From: Peter Lothberg To: mbone Subject: Mcast driver for cisco S-Bus FDDI adapter Message-Id: Does anyone have a pointer to a SunOS 4.1 driver for this card that supports multicast? --Peter From list-mgr@ISI.EDU Sat Jul 8 05:24:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 04:30:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 04:25:20 -0700 Received: from glory.kaist.ac.kr by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 04:25:13 -0700 Received: (from joyoon@localhost) by glory.kaist.ac.kr (8.6.9H1/8.6.9) id UAA29250 for mbone@ISI.EDU; Fri, 7 Jul 1995 20:24:48 +0900 From: Joong-One Yoon Message-Id: <199507071124.UAA29250@glory.kaist.ac.kr> Subject: unsubscribe To: mbone Date: Fri, 7 Jul 1995 20:24:48 +0900 (JST) X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 11 unsubscribe From list-mgr@ISI.EDU Fri Jul 7 18:33:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 11:40:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 11:34:47 -0700 Received: from pumas.iingen.unam.mx by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 11:34:46 -0700 Message-Id: <199507071834.AA13300@venera.isi.edu> Received: from standard-input by pumas.iingen.unam.mx; Fri, 7 Jul 1995 12:33:45 +0600 Date: Fri, 7 Jul 1995 12:33:45 +0600 Sender: crisc@pumas.iingen.unam.mx From: root@pumas.iingen.unam.mx To: mbone Subject: Subscribe Content-Length: 21 Please subscribe me. From list-mgr@ISI.EDU Sat Jul 8 04:04:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 15:04:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 15:04:29 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 15:04:24 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.11/8.6.9) id BAA20294; Sat, 8 Jul 1995 01:04:07 +0300 Date: Sat, 8 Jul 1995 01:04:07 +0300 Message-Id: <199507072204.BAA20294@silver.sms.fi> From: Petri Helenius To: mbone Subject: vat is chatty Is there currently anything that can be done about vat being frequently sending membership information on a channel with hundreds of participants? The volume of this easily exceeds the actual payload of the group. Pete From list-mgr@ISI.EDU Fri Jul 7 09:29:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 16:30:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 16:30:30 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 16:30:29 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16101(1)>; Fri, 7 Jul 1995 16:30:03 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49860>; Fri, 7 Jul 1995 16:29:53 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Petri Helenius Cc: mbone Subject: Re: vat is chatty In-Reply-To: Your message of "Fri, 07 Jul 95 15:04:07 PDT." <199507072204.BAA20294@silver.sms.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 7 Jul 1995 16:29:44 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jul7.162953pdt.49860@crevenia.parc.xerox.com> In message <199507072204.BAA20294@silver.sms.fi> you write: >Is there currently anything that can be done about vat being frequently >sending membership information on a channel with hundreds of participants? >The volume of this easily exceeds the actual payload of the group. I find this hard to believe (assuming that by "actual payload" you mean "audio data"). I monitored the 60-member shuttle audio session for 5 minutes. The session messages averaged 1.6kbps, and the data traffic used 66kbps. (both excluding IP headers) Perhaps if you have 2500 group members, and vat doesn't scale back (I thought that vat scaled its session message period based upon the number of members in the session), you might exceed 66kbps for session message data... Bill From list-mgr@ISI.EDU Fri Jul 7 18:46:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 21:50:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 21:47:33 -0700 Received: from chandra.astro.indiana.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 7 Jul 1995 21:47:32 -0700 Received: by chandra.astro.indiana.edu (940816.SGI.8.6.9/930416.SGI.AUTO) for mbone@isi.edu id XAA18839; Fri, 7 Jul 1995 23:46:47 -0400 From: anurag@chandra.astro.indiana.edu (Anurag Shankar) Message-Id: <199507080346.XAA18839@chandra.astro.indiana.edu> To: mbone Date: Fri, 7 Jul 1995 23:46:47 -0500 (EST) Reply-To: anurag@chandra.astro.indiana.edu Organization: Dept. of Astronomy, Indiana Univ.-Bloomington X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 309 Please subscribe. Thanks. -- Anurag Shankar, Visiting Research Associate (anurag@chandra.astro.indiana.edu) Astronomy Department, Indiana University 812-855-4838 (work) Swain West 319, Bloomington, IN, 47405, USA 812-855-8725 (fax) WWW home page: http://chandra.astro.indiana.edu/ From list-mgr@ISI.EDU Sat Jul 8 12:48:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 8 Jul 1995 03:50:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 8 Jul 1995 03:48:52 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 8 Jul 1995 03:48:49 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Sat, 8 Jul 1995 03:48:47 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 8 Jul 1995 11:48:34 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: Petri Helenius Cc: mbone Subject: Re: vat is chatty In-Reply-To: Your message of "Sat, 08 Jul 95 01:04:07 +0200." <199507072204.BAA20294@silver.sms.fi> Date: Sat, 08 Jul 95 11:48:29 +0100 Message-Id: <18866.805200509@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >Is there currently anything that can be done about vat being frequently >sending membership information on a channel with hundreds of participants? >The volume of this easily exceeds the actual payload of the group. Vat backs off the rate of session annoucements according to the number of participants to try and keep the session announcement data rate constant. Currently Mbone audio is the largest vat conf I can see - there's 25 participants. A quick tcpdump shows there's about 4.5 announcements per second, and the mean announcement size is about 40 bytes payload. Allowing for IP/UDP headers, this still equates to less that 3Kbps - way less that a single person speaking using PCM audio. Mark From list-mgr@ISI.EDU Sat Jul 8 05:28:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 8 Jul 1995 08:30:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 8 Jul 1995 08:29:10 -0700 Received: from chandra.astro.indiana.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 8 Jul 1995 08:29:09 -0700 Received: by chandra.astro.indiana.edu (940816.SGI.8.6.9/930416.SGI.AUTO) for mbone@isi.edu id KAA20088; Sat, 8 Jul 1995 10:28:24 -0400 From: anurag@chandra.astro.indiana.edu (Anurag Shankar) Message-Id: <199507081428.KAA20088@chandra.astro.indiana.edu> Subject: mrouted3.4 problem on SGI To: mbone Date: Sat, 8 Jul 1995 10:28:24 -0500 (EST) Reply-To: anurag@chandra.astro.indiana.edu Organization: Dept. of Astronomy, Indiana Univ.-Bloomington X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 760 Hi mbone gurus, I tried to set up mrouted3.4 on my SGI Indy running Irix 5.3 (using the mrouted3.4 package at sgi.com). After copying the bsd.a and ip_mroute.o to /var/sysgen/boot, I did an autoconfig (to rebuild the kernel). Here is what I get: /var/sysgen/root/usr/bin/ld: Error: Undefined: somaxconn tcp_keepidle tcp_keepintvl tcp_keep_timer_in_close Automatically reconfiguring the operating system. lboot: ld returned 256--failed Does anyone know what the problem is? -- Anurag Shankar, Visiting Research Associate (anurag@chandra.astro.indiana.edu) Astronomy Department, Indiana University 812-855-4838 (work) Swain West 319, Bloomington, IN, 47405, USA 812-855-8725 (fax) WWW home page: http://chandra.astro.indiana.edu/ From list-mgr@ISI.EDU Sun Jul 9 10:57:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 9 Jul 1995 03:59:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 9 Jul 1995 03:57:52 -0700 Received: from goethe.csl.sony.co.jp by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 9 Jul 1995 03:57:49 -0700 Received: from [133.138.173.1] (fred.csl.sony.co.jp [133.138.173.1]) by goethe.csl.sony.co.jp (8.6.12+2.5Wb4/3.3W3) with SMTP id KAA00878; Sun, 9 Jul 1995 10:57:37 GMT Date: Sun, 9 Jul 1995 10:57:37 GMT Message-Id: <199507091057.KAA00878@goethe.csl.sony.co.jp> X-Sender: rodger@133.138.190.61 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: anurag@chandra.astro.indiana.edu From: rodger@csl.sony.co.jp (Rodger Lea) Subject: Re: mrouted3.4 problem on SGI Cc: mbone >Hi mbone gurus, > >I tried to set up mrouted3.4 on my SGI Indy running Irix 5.3 (using the >mrouted3.4 package at sgi.com). After copying the bsd.a and ip_mroute.o >to /var/sysgen/boot, I did an autoconfig (to rebuild the kernel). Here >is what I get: > >/var/sysgen/root/usr/bin/ld: >Error: Undefined: >somaxconn >tcp_keepidle >tcp_keepintvl >tcp_keep_timer_in_close >Automatically reconfiguring the operating system. >lboot: ld returned 256--failed > >Does anyone know what the problem is? Hi Anurag, I'm no mbone guru but, I had this problem last week - the solution for me was to install the 'prepatch' versions of the same files. They are in the same directory I think. The clue is in the README file which makes a fleeting reference to patch 560 or some such number. Unless you have this patch installed I think you will see the errors you quote. As far as I can make out, vanilla 5.3 of the CD's is prepatch ! Let me know if it works, regards rodger From list-mgr@ISI.EDU Sun Jul 9 03:57:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 9 Jul 1995 10:57:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 9 Jul 1995 10:57:08 -0700 Received: from musings.com by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 9 Jul 1995 10:57:05 -0700 Received: by musings.com (5.0/SMI-SVR4) id AA13658; Sun, 9 Jul 1995 10:57:05 -0700 Date: Sun, 9 Jul 1995 10:57:05 -0700 From: bwalker@musings.com (Brad Walker) Message-Id: <9507091757.AA13658@musings.com> To: mbone Subject: need a tunnel feed X-Sun-Charset: US-ASCII Content-Length: 176 Could someone please give a location of the nearest tunnel field. I believe that MCI or someone connected to BarrNet would be best. Any contacts. Thanks very much. -brad w. From list-mgr@ISI.EDU Mon Jul 10 16:08:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 9 Jul 1995 23:13:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 9 Jul 1995 23:08:35 -0700 Received: from vx23.cc.monash.edu.au by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 9 Jul 1995 23:08:33 -0700 Received: from "port 3850"@basil.eng.monash.edu.au by vaxc.cc.monash.edu.au (PMDF V4.3-12 #8933) id <01HSPLXLU0GW94E8MX@vaxc.cc.monash.edu.au>; Mon, 10 Jul 1995 16:08:20 +1000 Received: from BASIL/SpoolDir by basil.eng.monash.edu.au (Mercury 1.20) ; 10 Jul 95 16:08:21 -1000 Received: from SpoolDir by BASIL (Mercury 1.20); 10 Jul 95 16:08:02 -1000 Date: Mon, 10 Jul 1995 16:08:01 GMT+1100 From: JOHN PSALLIDAS Subject: NVv3.3 and small size image transmission, problem ? To: mbone Message-Id: <5D81A8814D4@basil.eng.monash.edu.au> X-Mailer: Pegasus Mail/Windows (v1.22) Content-Transfer-Encoding: 7BIT Priority: normal Hello mboners. I have installed the NVv3.3beta Solaris binary on a 128 Mbytes RAM Sun Sparc 20 , running Solaris 2.4, which is equiped with the SunVideo capture board. I noticed the following strange behaviour. When I elect to send small size nv encoded video the transmitter works only half the time, i.e it will work for 30 seconds and it will stop for approx 30 seconds. The cycle is repeated.The buttons do not respond immadiately and the frames are not updated for the duration of the second half of the cycle. This does not happen when I send normal size nv encoded video. This behaviour is not observed when sending small size CELL B encoded video. Has anyone else seen this or is it just us? Thanks in advance. --------------------------------------------------- John Psallidas Postgraduate student. Monash Uni., Melbourne, Australia. E-mail : yannis@basil.eng.monash.edu.au Phone : (03) 9055350 /-\_/-\ / \ \_/---\*_/ \/ From list-mgr@ISI.EDU Mon Jul 10 12:02:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 01:02:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 01:02:08 -0700 Received: from cismsun.univ-lyon1.fr by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 01:02:05 -0700 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id KAA19569 for mbone@isi.edu; Mon, 10 Jul 1995 10:02:03 +0200 Message-Id: <199507100802.KAA19569@cismsun.univ-lyon1.fr> Subject: rsvp for OSF1 To: mbone Date: Mon, 10 Jul 1995 10:02:02 +0200 (MET DST) From: "Lucia Gradinariu" X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 234 Hi, i'm wondering if there is an experimental implementation of RSVP for Dec Alpha with OSF1/V3.x or some sources to port to this environment. Thank for any information, Lucia GRADINARIU CISM-Univ. Lyon1 FRANCE lucia@univ-lyon1.fr From list-mgr@ISI.EDU Mon Jul 10 12:35:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 01:37:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 01:36:03 -0700 Received: from mons.uio.no by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 01:36:00 -0700 Received: from ulrik.uio.no by mons.uio.no with local-SMTP (PP) id <28593-0@mons.uio.no>; Mon, 10 Jul 1995 10:35:35 +0200 Received: from [193.212.204.41] by ask.uio.no ; Mon, 10 Jul 1995 10:35:33 +0200 From: pal.kirkebo@usit.uio.no X-Sender: paalk@ask.uio.no Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Jul 1995 10:35:42 +0200 To: mbone Subject: unsubscribe unsubscribe From list-mgr@ISI.EDU Sun Jul 9 16:19:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 05:23:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 05:20:46 -0700 Received: from mpg.phys.Hawaii.Edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 05:20:43 -0700 Received: by mpg.phys.hawaii.edu (4.1/SMI-4.1) id AA11105; Mon, 10 Jul 95 02:19:04 HST Date: Mon, 10 Jul 1995 02:19:03 -1000 (HST) From: Antonio Querubin To: mbone Subject: Cisco/mrouted equivalence? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm having trouble getting a Cisco router talking to a Sun running mrouted. Suppose I have a net with a Sun running mrouted. Let's say it has an IP address of 1.2.3.4 and it gets a feed from 5.6.7.8. The mrouted.conf would something like: tunnel 1.2.3.4 5.6.7.8 metric 1 threshold 64 Suppose I now have a Cisco router with an address of 1.2.3.1 and I want it to replace the Sun as the mrouted tunnel endpoint. Shouldn't the following additions to the config be enough? ip multicast interface tunnel 0 tunnel source 1.2.3.1 tunnel destination 5.6.7.8 tunnel mode dvmrp Antonio Querubin tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org From list-mgr@ISI.EDU Mon Jul 10 17:17:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 06:25:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 06:18:01 -0700 Received: from vax3.sara.nl by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 06:17:56 -0700 Received: from horus.sara.nl by SARA.NL (PMDF V4.2-15 #2498) id <01HSPKAUJLV4AM30RH@SARA.NL>; Mon, 10 Jul 1995 15:21:00 +0200 (MET-DST) Received: from localhost.sara.nl by horus.sara.nl (AIX 3.2/UCB 5.64/4.03) id AA148576; Mon, 10 Jul 1995 15:17:08 +0200 Date: Mon, 10 Jul 1995 15:17:03 +0200 From: Jan Hondebrink Subject: hardware change on broodjeham Sender: janh@sara.nl To: mbone, SNET-IP@nic.surfnet.nl Cc: nic@SARA.NL Reply-To: SARA Network Information Centre Message-Id: <9507101317.AA148576@horus.sara.nl> X-Envelope-To: mbone@isi.edu Mime-Version: 1.0 X-Mailer: exmh version 1.5.3 12/28/94 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT Tuesday July 11th at 18:00 there will be a hardware change on the mbone machine broodjeham.surfnet.nl. The machine will be down for a short time. Jan Hondebrink SARA NIC From list-mgr@ISI.EDU Mon Jul 10 17:19:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 06:25:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 06:20:34 -0700 Received: from castor.LKN.E-Technik.TU-Muenchen.DE ([129.187.222.4]) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 06:20:27 -0700 Received: from neptun.LKN.E-Technik.TU-Muenchen.DE (jochen@neptun.LKN.E-Technik.TU-Muenchen.DE [129.187.222.9]) by castor.LKN.E-Technik.TU-Muenchen.DE (8.6.12/LKN) with ESMTP id PAA00881 for ; Mon, 10 Jul 1995 15:19:53 +0200 From: Jochen Frings Received: (jochen@localhost) by neptun.LKN.E-Technik.TU-Muenchen.DE (8.6.12/LKN) id PAA03329 for mbone@ISI.EDU; Mon, 10 Jul 1995 15:19:46 +0200 Date: Mon, 10 Jul 1995 15:19:46 +0200 Message-Id: <199507101319.PAA03329@neptun.LKN.E-Technik.TU-Muenchen.DE> To: mbone Subject: MBONE for LINUX X-Sun-Charset: US-ASCII A few weeks ago there was a discussion about MBONE and Linux. I fetched the tools an tried them, but got immediatly the error: vat: IP_MULTICAST_LOOP: Protocol not available Kernel version is 1.2.8 Could please anybody give me a hint, how to get a running configuration? (Any patches for Linux?) Thanks in advance Jochen Frings ------------------------------------------------------------- Phone: +49 (0)89 2105 - 3507 Jochen Frings Fax: +49 (0)89 2105 - 63507 Internet: frings@lkn.e-technik.tu-muenchen.de ------------------------------------------------------------- From list-mgr@ISI.EDU Mon Jul 10 19:50:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 06:51:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 06:50:40 -0700 Received: from castor.cc.utu.fi by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 06:50:31 -0700 Received: by utu.fi id <173987-2>; Mon, 10 Jul 1995 16:50:16 +0300 Subject: Re: MBONE for LINUX From: Matti Aarnio To: jochen@LKN.E-Technik.TU-Muenchen.DE (Jochen Frings) Date: Mon, 10 Jul 1995 16:50:08 +0300 (EET DST) Cc: mbone In-Reply-To: <199507101319.PAA03329@neptun.LKN.E-Technik.TU-Muenchen.DE> from "Jochen Frings" at Jul 10, 95 03:19:46 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 943 Message-Id: <95Jul10.165016+0300_eet_dst.173987-2+110@utu.fi> > A few weeks ago there was a discussion about MBONE and Linux. > I fetched the tools an tried them, but got immediatly the error: > > vat: IP_MULTICAST_LOOP: Protocol not available > > Kernel version is 1.2.8 > > Could please anybody give me a hint, > how to get a running configuration? > (Any patches for Linux?) Most likely your kernel is not configured with IP-multicast support in it. Reconfigure, compile, install, and reboot. There are quite a lot of patches, though not that many from the authors of VAT.. The latest (last?) "stable" Linux release is 1.2.11, while the developement version is now going on at 1.3.8. > Thanks in advance > > Jochen Frings > > ------------------------------------------------------------- > Phone: +49 (0)89 2105 - 3507 > Jochen Frings Fax: +49 (0)89 2105 - 63507 > Internet: frings@lkn.e-technik.tu-muenchen.de /Matti Aarnio From list-mgr@ISI.EDU Mon Jul 10 06:52:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 07:51:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 07:51:11 -0700 Received: from enforcer.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 07:51:10 -0700 Received: (from bennett@localhost) by enforcer.gsfc.nasa.gov (8.6.10/8.6.9) id KAA12212 for mbone@isi.edu; Mon, 10 Jul 1995 10:52:25 -0400 Date: Mon, 10 Jul 1995 10:52:25 -0400 From: bennett@enforcer.gsfc.nasa.gov Message-Id: <199507101452.KAA12212@enforcer.gsfc.nasa.gov> To: mbone Subject: unsubscribe X-Sun-Charset: US-ASCII unsubscribe From list-mgr@ISI.EDU Mon Jul 10 06:50:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 07:50:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 07:49:02 -0700 Received: from enforcer.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 07:49:01 -0700 Received: (from bennett@localhost) by enforcer.gsfc.nasa.gov (8.6.10/8.6.9) id KAA12203 for mbone@isi.edu; Mon, 10 Jul 1995 10:50:16 -0400 Date: Mon, 10 Jul 1995 10:50:16 -0400 From: bennett@enforcer.gsfc.nasa.gov Message-Id: <199507101450.KAA12203@enforcer.gsfc.nasa.gov> To: mbone Subject: unscribe X-Sun-Charset: US-ASCII unscribe From list-mgr@ISI.EDU Mon Jul 10 07:03:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 08:08:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 08:03:47 -0700 Received: from decvax.dec.com (decvax.zk3.dec.com) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 08:03:39 -0700 Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA06058; Mon, 10 Jul 1995 11:03:34 -0400 Received: from localhost by alpha.zk3.dec.com; (5.65v3.0/1.1.8.2/20May95-1022AM) id AA08754; Mon, 10 Jul 1995 11:03:28 -0400 Message-Id: <9507101503.AA08754@alpha.zk3.dec.com> To: "Lucia Gradinariu" Cc: mbone, ajay@zk3.dec.com Subject: Re: rsvp for OSF1 In-Reply-To: Your message of "Mon, 10 Jul 95 10:02:02 +0200." <199507100802.KAA19569@cismsun.univ-lyon1.fr> Date: Mon, 10 Jul 95 11:03:28 -0400 From: ajay@zk3.dec.com X-Mts: smtp >implementation of RSVP what do you mean by RSVP implementation, Do you mean IP Multicast 3.5/3.6? I'm not sure if RSVP is operational on any platform yet... --Ajay Kachrani From list-mgr@ISI.EDU Thu Jul 6 08:14:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 11:09:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 11:07:28 -0700 Received: from gateway.gtech.com by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 11:07:23 -0700 Received: from ops.soft.gtech.com ([156.24.33.7]) by gateway.gtech.com with SMTP id <25629>; Mon, 10 Jul 1995 14:05:57 -0400 Received: from sunsrv1 by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA1364726785; Mon, 10 Jul 1995 13:51:29 -0400 Received: (from root@localhost) by sunsrv1.soft.gtech.com (8.6.12/8.6.12) id MAA06416; Mon, 10 Jul 1995 12:38:16 -0500 Received: from gateway by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA024178631; Thu, 6 Jul 1995 13:47:35 -0400 Received: from ner.bbnplanet.com ([192.52.71.4]) by gateway.gtech.com with SMTP id <25623>; Thu, 6 Jul 1995 14:01:21 -0400 Received: from nic.near.net by nic.nic.near.net id ab25429; 6 Jul 95 13:58 EDT Received: from venera.isi.edu by nic.ner.bbnplanet.com id ab25396; 6 Jul 95 13:58 EDT Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:17:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:16:56 -0700 Received: from prom.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:16:55 -0700 Received: (dschluss@localhost) by prom.engin.umich.edu (8.6.12/8.6.4) id MAA19434; Thu, 6 Jul 1995 12:16:32 -0400 Date: Thu, 6 Jul 1995 12:14:46 -0400 From: "david a. schlussel" Subject: Re: help me To: Bill Fenner Cc: Tomas Gradin , System Administrator# , mbone, fenner@parc.xerox.com In-Reply-To: <95Jul5.163712pdt.49860@crevenia.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Jul 1995, Bill Fenner wrote: > In message <199507050658.IAA15178@bosun.wblab.lu.se> you write: > >>#cat /etc/mrouted.conf > >>tunnel 134.75.30.5 134.75.30.71 metric 1 threshold 190 > > > >My educated guess would be that your host's netmask is 255.255.0.0. Try > >255.255.255.0 instead. > > In fact, even with a netmask of 255.255.255.0, the hosts 134.75.30.5 and > 134.75.30.71 are on the same subnet. > > What is the output of "mrouted -d 3"? How about "ifconfig -a"? And why are > you trying to run a tunnel between two hosts on the same subnet? > > Bill > > Why shouldn't you try to run a tunnel between two hosts on the same subnet. I was given a feed, and, time permitting, wanted to set up a separate multicasting reflector on another machine on our subnet. Should i not do this? why? From Mailer-Daemon Thu Jul 6 13:47:41 1995 Received: from gateway by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA024178631; Thu, 6 Jul 1995 13:47:35 -0400 Return-Path: <@gateway.gtech.com:nearnet-mbone-request@ner.bbnplanet.com> Received: from ner.bbnplanet.com ([192.52.71.4]) by gateway.gtech.com with SMTP id <25623>; Thu, 6 Jul 1995 14:01:21 -0400 Received: from nic.near.net by nic.nic.near.net id ab25429; 6 Jul 95 13:58 EDT Received: from venera.isi.edu by nic.ner.bbnplanet.com id ab25396; 6 Jul 95 13:58 EDT Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:17:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:16:56 -0700 Received: from prom.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:16:55 -0700 Received: (dschluss@localhost) by prom.engin.umich.edu (8.6.12/8.6.4) id MAA19434; Thu, 6 Jul 1995 12:16:32 -0400 Date: Thu, 6 Jul 1995 12:14:46 -0400 From: "david a. schlussel" Subject: Re: help me To: Bill Fenner Cc: Tomas Gradin , System Administrator# , mbone@isi.edu, fenner@parc.xerox.com In-Reply-To: <95Jul5.163712pdt.49860@crevenia.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Jul 1995, Bill Fenner wrote: > In message <199507050658.IAA15178@bosun.wblab.lu.se> you write: > >>#cat /etc/mrouted.conf > >>tunnel 134.75.30.5 134.75.30.71 metric 1 threshold 190 > > > >My educated guess would be that your host's netmask is 255.255.0.0. Try > >255.255.255.0 instead. > > In fact, even with a netmask of 255.255.255.0, the hosts 134.75.30.5 and > 134.75.30.71 are on the same subnet. > > What is the output of "mrouted -d 3"? How about "ifconfig -a"? And why are > you trying to run a tunnel between two hosts on the same subnet? > > Bill > > Why shouldn't you try to run a tunnel between two hosts on the same subnet. I was given a feed, and, time permitting, wanted to set up a separate multicasting reflector on another machine on our subnet. Should i not do this? why? From list-mgr@ISI.EDU Thu Jul 6 22:30:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 11:16:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 11:16:08 -0700 Received: from gateway.gtech.com by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 11:16:06 -0700 Received: from ops.soft.gtech.com ([156.24.33.7]) by gateway.gtech.com with SMTP id <25731>; Mon, 10 Jul 1995 14:13:50 -0400 Received: from sunsrv1 by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA1441827095; Mon, 10 Jul 1995 13:56:39 -0400 Received: (from root@localhost) by sunsrv1.soft.gtech.com (8.6.12/8.6.12) id MAA07164; Mon, 10 Jul 1995 12:43:26 -0500 Received: from gateway by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA0431858682; Fri, 7 Jul 1995 03:41:46 -0400 Received: from ner.bbnplanet.com ([192.52.71.4]) by gateway.gtech.com with SMTP id <25623>; Fri, 7 Jul 1995 03:55:28 -0400 Received: from nic.near.net by nic.nic.near.net id aa03754; 7 Jul 95 3:52 EDT Received: from venera.isi.edu by nic.ner.bbnplanet.com id aa03745; 7 Jul 95 3:52 EDT Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 23:36:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 23:30:51 -0700 Received: from pobox.cscs.ch by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 23:30:49 -0700 Received: from cscs.ch by pobox.cscs.ch with SMTP inbound id <13849-0@pobox.cscs.ch>; Fri, 7 Jul 1995 08:30:30 +0200 Received: from monte (monte [148.187.160.20]) by piora-ether.cscs.ch (8.6.10/8.6.10) with SMTP id IAA00685 for ; Fri, 7 Jul 1995 08:30:28 +0200 From: Stefano Klett Received: by monte (5.x) id AA02935; Fri, 7 Jul 1995 08:30:27 +0200 Date: Fri, 7 Jul 1995 02:30:27 -0400 Message-Id: <9507070630.AA02935@monte> To: mbone Subject: Re: NP FDDI SBus card & Multicast 3.5 X-Sun-Charset: US-ASCII I have the same problem. Please help me. Tanks Stefano > > > Hi everybody, > > we have run the np_install script to install a NP's S-Bus FDDI card on our > SPARCstation 10. The machine is running SunOS-4.1.3, with the 3.5 multicasting code > installed. During the installation we replied "y" the question: > > "Has your system been modified to use IP MULTICAST applications [y|n]?" > > At the end, in the np_install.log file we got the following messages: > > ........... > Making new vmunix ... > > > ld: Undefined symbol > _addmultiaddr > _delmultiaddr > *** Error code 2 > make: Fatal error: Command failed for target `vmunix' > > ........... > > The vmunix produced is ok, but we can't see the other machines on the FDDI net. > > I'd appreciate any help to fix the problem. > Thank you in advance. > > From list-mgr@ISI.EDU Thu Jul 6 08:39:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 11:21:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 11:16:11 -0700 Received: from gateway.gtech.com by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 11:16:08 -0700 Received: from ops.soft.gtech.com ([156.24.33.7]) by gateway.gtech.com with SMTP id <25633>; Mon, 10 Jul 1995 14:08:32 -0400 Received: from sunsrv1 by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA1370726810; Mon, 10 Jul 1995 13:51:54 -0400 Received: (from root@localhost) by sunsrv1.soft.gtech.com (8.6.12/8.6.12) id MAA06467; Mon, 10 Jul 1995 12:38:41 -0500 Received: from gateway by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA025249916; Thu, 6 Jul 1995 14:09:00 -0400 Received: from ner.bbnplanet.com ([192.52.71.4]) by gateway.gtech.com with SMTP id <25623>; Thu, 6 Jul 1995 14:22:53 -0400 Received: from nic.near.net by nic.nic.near.net id aa26943; 6 Jul 95 14:19 EDT Received: from venera.isi.edu by nic.ner.bbnplanet.com id aa26934; 6 Jul 95 14:19 EDT Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:40:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:39:35 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 6 Jul 1995 09:39:35 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15455(5)>; Thu, 6 Jul 1995 09:39:20 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49860>; Thu, 6 Jul 1995 09:39:09 -0700 To: "david a. schlussel" Cc: mbone Subject: Re: tunnel between hosts on the same subnet In-Reply-To: Your message of "Thu, 06 Jul 95 09:14:46 PDT." Date: Thu, 6 Jul 1995 12:39:05 -0400 Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jul6.093909pdt.49860@crevenia.parc.xerox.com> In message you write: >Why shouldn't you try to run a tunnel between two hosts on the same >subnet. If you have two multicast routers on the same subnet, they will use the native multicasting of the subnet to communicate with each other, thus no need to configure a tunnel. For this reason, mrouted will ignore any tunnel between machines on the same subnet. This means you can still install another multicast router on the subnet, it just means that you don't have to configure a tunnel for it. Bill From list-mgr@ISI.EDU Mon Jul 10 04:54:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 11:55:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 11:54:35 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 11:54:33 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14635(5)>; Mon, 10 Jul 1995 11:54:24 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49860>; Mon, 10 Jul 1995 11:54:20 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: bwalker@musings.com (Brad Walker) Cc: mbone, admin@tlg.org Subject: Re: need a tunnel feed In-Reply-To: Your message of "Sun, 09 Jul 95 10:57:05 PDT." <9507091757.AA13658@musings.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jul 1995 11:54:15 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jul10.115420pdt.49860@crevenia.parc.xerox.com> In message <9507091757.AA13658@musings.com> you write: >Could someone please give a location of the nearest tunnel field. >I believe that MCI or someone connected to BarrNet would be best. BARRNet will only give feeds to its customers, and presumably discourages their customers from giving feeds across BARRNet. MCINet has some internal multicast topology but it is mostly hidden. I don't think that tlg.net has gotten into the multicast providing business yet, but I think it should. Bill From list-mgr@ISI.EDU Mon Jul 10 05:02:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 12:03:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 12:02:40 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 12:02:38 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14613(3)>; Mon, 10 Jul 1995 12:02:17 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49860>; Mon, 10 Jul 1995 12:02:10 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Antonio Querubin Cc: mbone Subject: Re: Cisco/mrouted equivalence? In-Reply-To: Your message of "Mon, 10 Jul 95 05:19:03 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jul 1995 12:02:03 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jul10.120210pdt.49860@crevenia.parc.xerox.com> I don't know anything about the specifics of configuring a Cisco tunnel, but you didn't mention anything about reconfiguring the other end. Both ends of a tunnel need to know about the change; in your example the host "5.6.7.8" would need to change the "1.2.3.4" in its mrouted.conf to "1.2.3.1". (using real IP addresses in examples almost always makes it easier for people to help; i.e. in this case I could have checked myself if "5.6.7.8" had the proper tunnel...) Bill From list-mgr@ISI.EDU Mon Jul 10 15:06:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 16:09:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 16:06:26 -0700 Received: from seka.reston.ans.net by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 16:06:24 -0700 Received: by seka.reston.ans.net (4.1/SMI-4.1) id AA03075; Mon, 10 Jul 95 19:06:23 EDT Date: Mon, 10 Jul 95 19:06:23 EDT From: enger@seka.reston.ans.net (Robert M. Enger) Message-Id: <9507102306.AA03075@seka.reston.ans.net> To: mbone, sklett@cscs.ch Subject: Re: NP FDDI SBus card & Multicast 3.5 hi: I saw the same problem during my initial install. "on principle", I got the latest and greatest from NP's ftp server. That seems to have cleared up the problem for me. ftp to netgw.npix.com cd to /patches/sbus get file NP302.tar.Z Hope this helps, Bob From list-mgr@ISI.EDU Mon Jul 10 12:00:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 17:07:27 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 17:04:45 -0700 Received: from netmon.mty.itesm.mx by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 17:04:44 -0700 Received: by netmon.mty.itesm.mx (NX5.67d/NX3.0M) id AA06693; Mon, 10 Jul 95 18:00:39 -0600 Date: Mon, 10 Jul 95 18:00:39 -0600 From: Ing. Benjamin Dominguez Message-Id: <9507110000.AA06693@netmon.mty.itesm.mx> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: mbone Subject: unsubscribe unsubscribe From list-mgr@ISI.EDU Mon Jul 10 12:01:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 17:08:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 17:05:44 -0700 Received: from netmon.mty.itesm.mx by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 17:05:42 -0700 Received: by netmon.mty.itesm.mx (NX5.67d/NX3.0M) id AA06698; Mon, 10 Jul 95 18:01:38 -0600 Date: Mon, 10 Jul 95 18:01:38 -0600 From: Ing. Benjamin Dominguez Message-Id: <9507110001.AA06698@netmon.mty.itesm.mx> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: mbone Subject: subscribe bdoming@sironmty.mty.itesm.mx subscribe bdoming@sironmty.mty.itesm.mx From list-mgr@ISI.EDU Mon Jul 10 05:39:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 18:41:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 18:38:32 -0700 Received: from mailrelay.pixi.com (sirius.pixi.com) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 18:38:31 -0700 Received: by mailrelay.pixi.com (8.6.10/SMI-4.1) id PAA22928; Mon, 10 Jul 1995 15:39:07 -1000 Date: Mon, 10 Jul 1995 15:39:06 -1000 (HST) From: Antonio Querubin Jr To: mbone Subject: mrouted tunnel needed Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We're looking for an mbone feed closer to us. Our main upstream service provider (TLG) can't provide us with one for a while and they claim their upstream provider (Sprint) can't/wont either. We're running mrouted 3.6 here. The IP address of our tunnel endpoint is 204.182.46.3. Antonio Querubin tony@pixi.com / ah6bw@uhm.ampr.org From list-mgr@ISI.EDU Mon Jul 10 12:21:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 19:20:29 -0700 Received: from netcomsv.netcom.com (uucp1-b.netcom.com) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 19:20:28 -0700 Received: from comit.com by netcomsv.netcom.com with SMTP (8.6.12/SMI-4.1) id TAA22893; Mon, 10 Jul 1995 19:19:20 -0700 Received: by comit.com (5.x/SMI-SVR4) id AA28436; Mon, 10 Jul 1995 19:21:09 -0700 Date: Mon, 10 Jul 1995 19:21:09 -0700 From: nij@everest.comit.com (Nijalingam Dorairaj) Message-Id: <9507110221.AA28436@comit.com> To: mbone-na Subject: mrouted on PC Hello Can I run mrouted on a PC which is running UNIX (NetBSD,BSD385 or Linux). I am not in the list but I will summarize and post it back. Thanks -Nij Comit Systems, Inc. 1250 Oakmead Pky, Suite 210 Sunnyvale, CA-94088 Ph: 408-988-2988 Fax: 408-988-2133 E-mail: nij@comit.com http://everest.comit.com/ From list-mgr@ISI.EDU Mon Jul 10 19:10:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 20:14:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 20:11:26 -0700 Received: from sydney.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 20:11:26 -0700 Received: (from thalerd@localhost) by sydney.eecs.umich.edu (8.6.8/8.6.10) id XAA20644 for mbone@isi.edu; Mon, 10 Jul 1995 23:10:01 -0400 Date: Mon, 10 Jul 1995 23:10:01 -0400 From: Dave Thaler Message-Id: <199507110310.XAA20644@sydney.eecs.umich.edu> To: mbone Subject: Announcing new SNMP-mrouted release (plus new mstat for all platforms) A full 3.6 release of mrouted with revised SNMP-support is now available. This supersedes the SNMP-support included with the original mrouted3.x release. Changes are as follows: Now supports the IGMP mib in addition to the multicast and DVMRP MIBs. Fixes a few bugs in the previous SNMP release No longer requires installation of any other snmp code or libraries other than those included with this release. The snmp daemon and mrouted are now combined into a single binary, eliminating context switching and other problems known to SNMP folk. By moving from the ISODE code to the CMU version of snmpd, the binary is now about half its previous size and no longer requires additional configuration files. Why should you install SNMP support in mrouted at all? Able to use existing network management techniques available via SNMP. Utilities planned or currently under development here at Merit will make use of information available via SNMP from mrouted's, PIM routers, etc. Able to respond to queries by the mstat utility. For example, tables previously available only locally via USR1 and USR2 signals are available remotely with mstat. For more info on mstat, read the man page or check out the CGI script available from: http://shockwave.merit.edu/mbone/mbone_proj.html Source (which includes a new version of mstat) is available from: ftp://home.merit.edu/pub/users/thalerd/snmp-mrouted3.6.tar.Z Sparc binaries are available from: ftp://home.merit.edu/pub/users/thalerd/snmp-mrouted3.6-sunos41x.tar.Z Finally, even if you can't run a 3.5 kernel, you can still use the mstat utility, which has been verified to work on the following platforms: SunOS, Ultrix, HP-UX, FreeBSD, BSDI, NeXT, and Linux Source for mstat only is available from: ftp://home.merit.edu/pub/users/thalerd/mstat.tar.Z Dave Thaler From list-mgr@ISI.EDU Mon Jul 10 15:30:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 22:34:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 22:31:18 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 22:31:17 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15780(5)>; Mon, 10 Jul 1995 22:31:00 PDT Received: by redwing.parc.xerox.com id <177520>; Mon, 10 Jul 1995 22:30:49 -0700 Date: Mon, 10 Jul 1995 22:30:43 PDT Sender: Lixia Zhang From: Lixia Zhang To: ajay@zk3.dec.com Cc: "Lucia Gradinariu" , mbone, ajay@zk3.dec.com Subject: Re: rsvp for OSF1 In-Reply-To: Your message of Mon, 10 Jul 1995 08:03:28 -0700 Message-Id: > >implementation of RSVP > > what do you mean by RSVP implementation, Do you mean IP > Multicast 3.5/3.6? I'm not sure if RSVP is operational > on any platform yet... yes there are running implementations, one from ISI (on Sun, contact Steve Berson, berson@isi.edu), another at Sun (with solaris) Lixia From list-mgr@ISI.EDU Tue Jul 11 07:21:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 00:27:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 00:24:52 -0700 Received: from hollywood.cinenet.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 00:24:51 -0700 Received: by hollywood.cinenet.net (8.6.12/25-eef) id HAA14731; Tue, 11 Jul 1995 07:21:49 GMT Date: Tue, 11 Jul 1995 07:21:49 GMT From: Erin Zhu Message-Id: <199507110721.HAA14731@hollywood.cinenet.net> Content-Type: text Content-Length: 26 Apparently-To: mbone subscribe zhu@cinenet.net From list-mgr@ISI.EDU Wed Jul 12 00:08:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 01:13:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 01:10:58 -0700 Received: from mail.ncku.edu.tw by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 01:10:40 -0700 Received: (from ckwen@localhost) by mail.ncku.edu.tw (8.6.12/8.6.12) id QAA17221; Tue, 11 Jul 1995 16:08:07 +0800 From: Cheng-Kang Wen Message-Id: <199507110808.QAA17221@mail.ncku.edu.tw> Subject: Re: MBONE for LINUX To: jochen@LKN.E-Technik.TU-Muenchen.DE (Jochen Frings) Date: Tue, 11 Jul 1995 16:08:06 +0800 (WST) Cc: mbone In-Reply-To: <199507101319.PAA03329@neptun.LKN.E-Technik.TU-Muenchen.DE> from "Jochen Frings" at Jul 10, 95 03:19:46 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 329 > > > vat: IP_MULTICAST_LOOP: Protocol not available > > Kernel version is 1.2.8 > > The IP Multicast protocol is not enabled in Linux kernel by default. What you need to do is to recompile the linux kernel and enable the ip multicast protocol. Please refer the readme or install file in the kernel source. Cheng-Kang Wen From list-mgr@ISI.EDU Mon Jul 10 21:59:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 05:02:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 04:59:49 -0700 Received: from hq.barrnet.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 04:59:49 -0700 Received: from [36.178.0.13] (Yundt-ISDN.Stanford.EDU [36.178.0.13]) by hq.barrnet.net (8.6.10/HQ-Len) with SMTP id FAA07994; Tue, 11 Jul 1995 05:01:46 -0700 X-Sender: wyundt@hq.barrnet.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Jul 1995 04:59:15 -0700 To: Antonio Querubin Jr From: wyundt@WR.BBNPLANET.COM (Bill Yundt) Subject: Re: mrouted tunnel needed Cc: mbone At 6:39 PM 7/10/95, Antonio Querubin Jr wrote: >We're looking for an mbone feed closer to us. Our main upstream service >provider (TLG) can't provide us with one for a while and they claim their >upstream provider (Sprint) can't/wont either. We're running mrouted 3.6 >here. The IP address of our tunnel endpoint is 204.182.46.3. > >Antonio Querubin >tony@pixi.com / ah6bw@uhm.ampr.org ....maybe you should change provider. Delivering mbone tunnels (only useful at apx. T-1 speeds, really) is for the heavy infrastructure crowd and is expensive to do. If you are a research organization, your best bet would be through a university. ---------------------------------------- Bill Yundt, VP Strategic Development Office Direct: (415) 528-7072 BBN Planet Corporation - BARRNET Offices Home (early am): (415) 574-0915 3801 East Bayshore Road Main: (415) 934-2655 Palo Alto, California 94303 Fax: (415) 934-2665 http://www.barrnet.net From list-mgr@ISI.EDU Tue Jul 11 05:56:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 05:59:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 05:56:54 -0700 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 05:56:52 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.6.12/8.6.12) id IAA20957; Tue, 11 Jul 1995 08:57:12 -0400 Date: Tue, 11 Jul 1995 08:51:21 From: "Dave Thaler" Subject: Announcing new SNMP-mrouted release (plus new mstat for all platforms) Message-Id: <19950711085121.29534@dip.eecs.umich.edu> To: mbone Piete Brooks writes: > > No longer requires installation of any other snmp code or libraries > > other than those included with this release. > > The snmp daemon and mrouted are now combined into a single binary, > > eliminating context switching and other problems known to SNMP folk. > > Indeed -- it *excludes* the possibility of running any other snmp daemon :-( > > When I tried running it, it complained that the port was in use (161). > To get mrouted to run, I had to kill of my snmpd :-( > > Is there a way to get them to co-exist ? The new snmp-mrouted supports the standard MIB information, so the only reason to run a separate snmpd is if you have local additions (i.e. additional MIBs your snmpd supports) beyond your original snmpd distribution. However, the answer to your question is yes. If you MUST run another snmpd, the best thing to do is to run one on an alternate port number (port 9161 is suggested), and set up a native SNMP proxy relationship between them. (This in fact is exactly how Merit's routing arbiter project is set up.) Dave From list-mgr@ISI.EDU Tue Jul 11 05:52:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 06:55:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 06:52:37 -0700 Received: from davinci.gmu.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 06:52:35 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id JAA24484; Tue, 11 Jul 1995 09:52:30 -0400 Date: Tue, 11 Jul 1995 09:52:30 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199507111352.JAA24484@davinci.gmu.edu> To: mbone Subject: NV on Linux???? I originally posted this to linux.misc with no luck. Perhaps I can get an answer here. I am just to get nv running on linux, but I keep getting either a segmentation fault or the following message: XIO: fatal IO error 2 (Bad file number) on X server "" after 94288923373 requests (1162893652 processed) with 1414745928 events remaining. If anyone has ANY ideas, please email me at mbenson@gmu.edu Michael -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Tue Jul 11 07:45:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 08:48:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 08:45:55 -0700 Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 08:45:54 -0700 Received: from roo.uu.net by rodan.UU.NET with SMTP id QQyxyd13030; Tue, 11 Jul 1995 11:45:49 -0400 Received: by roo.uu.net (leaf) id QQyxyd10198; Tue, 11 Jul 1995 11:45:48 -0400 Date: Tue, 11 Jul 1995 11:45:48 -0400 Message-Id: From: Henry Kilmer To: wyundt@WR.BBNPLANET.COM (Bill Yundt) Cc: Antonio Querubin Jr , mbone Subject: Re: mrouted tunnel needed In-Reply-To: References: Bill Yundt writes: >At 6:39 PM 7/10/95, Antonio Querubin Jr wrote: >>We're looking for an mbone feed closer to us. Our main upstream service >>provider (TLG) can't provide us with one for a while and they claim their >>upstream provider (Sprint) can't/wont either. We're running mrouted 3.6 >>here. The IP address of our tunnel endpoint is 204.182.46.3. >> >>Antonio Querubin >>tony@pixi.com / ah6bw@uhm.ampr.org > >....maybe you should change provider. Delivering mbone tunnels (only >useful at apx. T-1 speeds, really) is for the heavy infrastructure crowd >and is expensive to do. If you are a research organization, your best bet >would be through a university. Sprint does support the mbone but TLG may have requested that they not send multicast traffic down their link (perhaps load issues). Changing providers is certainly an option. Why do you recomend universities when pretty much all of the larger providers are supporting the mbone? >---------------------------------------- >Bill Yundt, VP Strategic Development Office Direct: (415) 528-7072 >BBN Planet Corporation - BARRNET Offices Home (early am): (415) 574-0915 >3801 East Bayshore Road Main: (415) 934-2655 >Palo Alto, California 94303 Fax: (415) 934-2665 --- speaking for myself From list-mgr@ISI.EDU Tue Jul 11 11:38:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 11:41:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 11:38:52 -0700 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 11:38:50 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.6.12/8.6.12) id OAA01704; Tue, 11 Jul 1995 14:39:10 -0400 Date: Tue, 11 Jul 1995 14:38:31 From: "Dave Thaler" Subject: mrouted on PC Message-Id: <19950711143831.29534@dip.eecs.umich.edu> To: mbone FreeBSD is supported, and I believe there is at least one BSDI machine on the MBone as well. Dave From list-mgr@ISI.EDU Tue Jul 11 05:43:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 12:46:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 12:44:07 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 12:44:04 -0700 Received: from localhost (localhost [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with SMTP id MAA00672; Tue, 11 Jul 1995 12:43:54 -0700 Message-Id: <199507111943.MAA00672@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6delta 4/7/95 To: "Dave Thaler" Cc: mbone Subject: Re: mrouted on PC In-Reply-To: Your message of "Tue, 11 Jul 1995 14:38:31." <19950711143831.29534@dip.eecs.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Jul 1995 12:43:48 -0700 From: "Amancio Hasty Jr." >>> "Dave Thaler" said: > FreeBSD is supported, and I believe there is at least one BSDI machine > on the MBone as well. > Well, I have mrouted 3.5 running on my FreeBSD box which is connected to the Net via a 128kb isdn line. Actually, since I am here . Is anyone working on porting the X11R5 video extensions to X11R6 or working on mpeg hardware support on the X11R6 server side. I have an mpeg board working on FreeBSD and I am looking into providing hardware assist for mpeg and H.261 . Enjoy, Amancio From list-mgr@ISI.EDU Tue Jul 11 06:01:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 13:05:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 13:02:37 -0700 Received: from kadath.zeitgeist.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 13:02:37 -0700 Received: from kadath.zeitgeist.net (kadath.zeitgeist.net [140.174.77.100]) by kadath.zeitgeist.net (8.6.12/8.6.10) with SMTP id NAA19566; Tue, 11 Jul 1995 13:01:48 -0700 Date: Tue, 11 Jul 1995 13:01:45 -0700 (PDT) From: Edgar Nielsen To: mbone Cc: Antonio Querubin Jr Subject: Re: mrouted tunnel needed Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > We're looking for an mbone feed closer to us. Our main upstream service > provider (TLG) can't provide us with one for a while and they claim their > upstream provider (Sprint) can't/wont either. We're running mrouted 3.6 > here. The IP address of our tunnel endpoint is 204.182.46.3. Hi, I would like to apologize for this mail from this site downstream of us. I'm not sure if this individual works for our customer pixi.com or is a customer of pixi.com. Pixi.com staff had been told we would provide them an MBONE tunnel this week, this person is either not part of their staff or some internal miscommunication went on over there. Currently TLGnet has some limited MBONE stuff going on using a tunnel from Sprint. We are looking into using the cisco multicast features but are still poring through the documentation. Actually if anyone has seen a good configuration guide for the cisco multicast setup, we'd appreciate getting a point to it. Sorry for the wasted bandwidth, edgar nielsen ----- TLGnet staff From list-mgr@ISI.EDU Tue Jul 11 12:20:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 13:24:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 13:21:20 -0700 Received: from edf-bb.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 13:21:19 -0700 Message-Id: <199507112021.AA07880@venera.isi.edu> Received: by edf-bb.gsfc.nasa.gov (1.38.193.4/16.2) id AA20795; Tue, 11 Jul 1995 16:20:26 -0400 From: Ching-Tien TSAI Subject: API for group communication wanted To: mbone Date: Tue, 11 Jul 95 16:20:26 EDT Mailer: Elm [revision: 70.85] Hi, all, Since I did not receive any response from my previous post, I am reposting it. Thanks in advance for your response. _____________________________________________________________________________ Can anyone tell me where I can find APIs or example programs to support group communications? The API should be able to receive and send IGMP multicast packets, and allow a non-multicast host to join the group. That is the API shall allow unicast and multicast communication within a single group. Any host should be able to join or leave a group freely without interrupting the group communications. The data received from this group can be unreliable and unordered, i.e., UDP is O.K. Thanks for any information. Ching Hughes Information Technology Corp. ching@edf-bb.gsfc.nasa.gov From list-mgr@ISI.EDU Tue Jul 11 12:20:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 13:23:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 13:21:00 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 13:20:59 -0700 Received: by chops.icp.net id <20696>; Tue, 11 Jul 1995 16:20:41 -0400 From: Sean Doran To: hank@uunet.uu.net, wyundt@WR.BBNPLANET.COM Subject: Re: mrouted tunnel needed Cc: mbone, tony@pixi.com Message-Id: <95Jul11.162041-0400_edt.20696+14@chops.icp.net> Date: Tue, 11 Jul 1995 16:20:39 -0400 Well, since we're all in a mood to speak for ourselves, Henry Kilmer asked Bill Yundt, "Why do you recommend universities when pretty much all of the larger providers are supporting the mbone?" What, give credibility to those Evil Commercial Networks(tm)? Don't be foolish. Besides, if more people use lots of MBONE on or via a well-connected University campus, then that University's upstream provider can fill more of the University's high-speed link to them with MBONE noise, and thus spare themselves all that much more University-generated traffic on their own infrastructure. "Why do I get lousy TCP performance?" "Because your link is saturated with MBONE traffic, that's why". Hmm, sheer genius, yes? Sean. From list-mgr@ISI.EDU Tue Jul 11 00:40:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 13:49:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 13:46:23 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 13:46:22 -0700 Received: from mailrelay.pixi.com (sirius.pixi.com) by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 11 Jul 1995 13:41:29 -0700 Received: by mailrelay.pixi.com (8.6.10/SMI-4.1) id KAA02867; Tue, 11 Jul 1995 10:40:22 -1000 Date: Tue, 11 Jul 1995 10:40:20 -1000 (HST) From: Antonio Querubin Jr To: Edgar Nielsen Cc: mbone, Julian Cowley , Frank Godek , Herbert B Dudley , Wayne Carvalho Subject: Re: mrouted tunnel needed In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 11 Jul 1995, Edgar Nielsen wrote: > Date: Tue, 11 Jul 1995 13:01:45 -0700 (PDT) > From: Edgar Nielsen > To: mbone@ISI.EDU > Cc: Antonio Querubin Jr > Subject: Re: mrouted tunnel needed > > > We're looking for an mbone feed closer to us. Our main upstream service > > provider (TLG) can't provide us with one for a while and they claim their > > upstream provider (Sprint) can't/wont either. We're running mrouted 3.6 > > here. The IP address of our tunnel endpoint is 204.182.46.3. > > Hi, > I would like to apologize for this mail from this site There's need to apologize for us. Last time I checked PIXI and TLG were separate independent corporations. > downstream of us. I'm not sure if this individual works for our customer > pixi.com or is a customer of pixi.com. Pixi.com staff had been told we would It would be wise to check this out before posting an 'apology'. > provide them an MBONE tunnel this week, this person is either not > part of their staff or some internal miscommunication went on over there. Perhaps some of the latter between PIXI and TLG. > Currently TLGnet has some limited MBONE stuff going on using a tunnel > from Sprint. We are looking into using the cisco multicast features but > are still poring through the documentation. Actually if anyone has seen > a good configuration guide for the cisco multicast setup, we'd appreciate > getting a point to it. We just moved our mbone tunnel from a Sun workstation to a Cisco router with the help of some of the folks on the mbone mailing list. Call us at PIXI if you need help :) > > Sorry for the wasted bandwidth, We now return you to our unregularly scheduled multicasting... Antonio Querubin tony@pixi.com / ah6bw@uhm.ampr.org From list-mgr@ISI.EDU Tue Jul 11 14:29:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 14:32:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 14:29:39 -0700 Received: from gateway.digipix.com by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 14:29:37 -0700 Received: from digipix.com (qmserver.digipix.com) by gateway.digipix.com (4.1/SMI-4.1) id AA06553; Tue, 11 Jul 95 14:40:22 PDT Message-Id: Date: 11 Jul 1995 14:29:55 U From: "Scott Folcarelli" Subject: unsubscribe To: "MBONE group" X-Mailer: Mail*Link SMTP-QM 3.0.2 Subject: Time: 2:30 PM OFFICE MEMO unsubscribe Date: 7/11/95 unsubscribe sfolcarelli@digipix.com From list-mgr@ISI.EDU Tue Jul 11 13:57:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 15:01:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 14:58:34 -0700 Received: from cs1.boston.deshaw.com by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 14:58:29 -0700 Received: (from mycroft@localhost) by cs1.boston.deshaw.com (8.6.12/8.7.Alpha.4/1.31.kim) id RAA02618; Tue, 11 Jul 1995 17:57:31 -0400 Date: Tue, 11 Jul 1995 17:57:31 -0400 From: Charles Hannum Message-Id: <199507112157.RAA02618@cs1.boston.deshaw.com> To: thalerd@eecs.umich.edu Cc: mbone In-Reply-To: <19950711143831.29534@dip.eecs.umich.edu> (thalerd@eecs.umich.edu) Subject: Re: mrouted on PC FreeBSD is supported, and I believe there is at least one BSDI machine on the MBone as well. NetBSD has had native multicast support since December 1993. It's currently at 3.5, with several bug fixes and cleaner kernel-side support. From list-mgr@ISI.EDU Tue Jul 11 19:59:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 21:08:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 21:00:13 -0700 Received: from davinci.gmu.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 21:00:13 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id XAA28863; Tue, 11 Jul 1995 23:59:44 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199507120359.XAA28863@davinci.gmu.edu> Subject: Re: mrouted on PC To: Charles-Hannum@deshaw.com (Charles Hannum) Date: Tue, 11 Jul 1995 23:59:44 -0400 (EDT) Cc: thalerd@eecs.umich.edu, mbone In-Reply-To: <199507112157.RAA02618@cs1.boston.deshaw.com> from "Charles Hannum" at Jul 11, 95 05:57:31 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 502 Is there a Linux version of mrouted anywhere? Michael > > > FreeBSD is supported, and I believe there is at least one BSDI machine > on the MBone as well. > > NetBSD has had native multicast support since December 1993. It's > currently at 3.5, with several bug fixes and cleaner kernel-side > support. > -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Wed Jul 12 11:42:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 22:43:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 22:42:32 -0700 Received: from castor.cc.utu.fi by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 22:42:29 -0700 Received: by utu.fi id <174069-3>; Wed, 12 Jul 1995 08:42:11 +0300 Subject: Re: mrouted on PC From: Matti Aarnio To: mbenson@davinci.gmu.edu (Michael Benson) Date: Wed, 12 Jul 1995 08:42:02 +0300 (EET DST) Cc: mbone In-Reply-To: <199507120359.XAA28863@davinci.gmu.edu> from "Michael Benson" at Jul 11, 95 11:59:44 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 565 Message-Id: <95Jul12.084211+0300_eet_dst.174069-3+47@utu.fi> > Is there a Linux version of mrouted anywhere? > > Michael Not at the moment. Linux is lacking kernel aspects of the mrouted, but I have understood that somebody is working on it. More info (well, "wizard talk") is available via mailinglist: linux-net@vger.rutgers.edu and less wizardy talk on newsgroup: comp.os.linux.networking > -- > Michael Benson > Computer science graduate student at George Mason University > WWW: http://cne.gmu.edu/~mbenson > Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson /Matti Aarnio From list-mgr@ISI.EDU Wed Jul 12 11:27:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 00:29:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 00:28:07 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 00:28:00 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.34.54]) by immd4.informatik.uni-erlangen.de with ESMTP id JAA06606 (8.6.12/7.4b-FAU);; Wed, 12 Jul 1995 09:27:48 +0200 From: Toerless Eckert Message-Id: <199507120727.JAA06606@faui40.informatik.uni-erlangen.de> Subject: Re: mrouted on PC To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Wed, 12 Jul 1995 09:27:46 +0200 (MET DST) Cc: thalerd@eecs.umich.edu, mbone In-Reply-To: <199507111943.MAA00672@rah.star-gate.com> from "Amancio Hasty Jr." at Jul 11, 95 12:43:48 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 824 > Actually, since I am here . Is anyone working on porting the > X11R5 video extensions to X11R6 or working on mpeg hardware support > on the X11R6 server side. I am not quite sure what Xaccell is based on (R5/R6) i think it's R6, but then i don't know what's the big difference in a server between R5/R6 anyway. At least Xaccell supports the XVideo extensions for live video and framegrabbing for some cards in a PC, and it's working quite well (i've got a Spea Showtime). It does not have support for the mpeg decoder on that board or any other mpeg decoder yet, though. The main problem seems to be that there really is no standardised X interface to that functionality. > I have an mpeg board working on FreeBSD and I am looking into providing > hardware assist for mpeg and H.261 . What video card are you using ? From list-mgr@ISI.EDU Tue Jul 11 18:26:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 01:27:20 -0700 Received: from intrepid (intrepid.internex.net) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 01:27:18 -0700 Received: by intrepid (5.x/SMI-SVR4) id AA02054; Wed, 12 Jul 1995 01:26:52 -0700 From: "Marcos Della" Message-Id: <9507120126.ZM2052@intrepid> Date: Wed, 12 Jul 1995 01:26:51 -0700 X-Mailer: Z-Mail (3.2.1 15feb95) To: mbone-na Subject: Looking for an mbone feed. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi there, I'm currently looking for an MBONE feed for my network. Currently I am connected via Net99, Agis, and Sprint as well has having a large pipe into Mae-West. If there is anyone at Mae-West that could provide a feed, that would be ideal. If you would also like to do BGP peering there as well, that would be bennificial. Also, a request for someone that has gotten tunnels to work successfully with the Cisco 10.3(>2) products, I'd appreciate a sample configuration to finish off my end of the tunnel. Currently I am experimenting with the following configuration: ip multicast-routing ! interface Tunnel0 no ip address ip pim dense-mode tunnel source Ethernet0/4 tunnel destination 192.9.5.5 tunnel mode dvmrp Any clues? I am not on this list as of yet, so please forward your comments to me as well as this list. Thanks! Marcos -- ''' (o o) --------------------------oOO--(_)--OOo-------------------------- Marcos R. Della Email: MDella@InterNex.Net Director, Network Engineering InterNex Information Services Phone: 408/496-5466 http://www.internex.net/~mdella From list-mgr@ISI.EDU Wed Jul 12 10:53:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 01:59:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 01:54:06 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 01:54:05 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Wed, 12 Jul 1995 01:54:04 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Jul 1995 09:53:29 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: Ching-Tien TSAI Cc: mbone Subject: Re: API for group communication wanted In-Reply-To: Your message of "Tue, 11 Jul 95 16:20:26 EDT." <199507112021.AA07880@venera.isi.edu> Date: Wed, 12 Jul 95 09:53:22 +0100 Message-Id: <11017.805539202@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >Since I did not receive any response from my previous post, I am reposting >it. >_____________________________________________________________________________ > >Can anyone tell me where I can find APIs or example programs to support group >communications? The API should be able to receive and send IGMP multicast >packets, and allow a non-multicast host to join the group. That is the API sha >ll >allow unicast and multicast communication within a single group. Any host >should be able to join or leave a group freely without interrupting the group >communications. The data received from this group can be unreliable and >unordered, i.e., UDP is O.K. Maybe people didn't understand your question? There is no API to do what you wish to do. In a UNIX environment, the application does not normally send or receive IGMP - the kernel does it. You don't need to join a group to send to it - just address your UDP packets to the class D group address. However, you do want to set the ttl on your send socket: unsigned char ttl; setsockopt(tx, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl)) To receive multicast, you need to do a setsockopt IP_ADD_MEMBERSHIP. Something like: struct ip_mreq imr; setsockopt(rx, IPPROTO_IP, IP_ADD_MEMBERSHIP, &imr, sizeof(struct ip_mreq)) Then the kernel sends IGMP membership reports for you. Then bind the rx socket as appropriate, and receive away.... IP multicast has the property that senders do not need to be in the group they send to, and senders do not know of the exitence of receivers unless you add an application layer protocol to inform them. Is this the information you were looking for? Mark From list-mgr@ISI.EDU Tue Jul 11 19:27:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 02:30:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 02:28:46 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 02:28:45 -0700 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with SMTP id CAA02690; Wed, 12 Jul 1995 02:27:34 -0700 Message-Id: <199507120927.CAA02690@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6delta 4/7/95 To: Toerless Eckert Cc: thalerd@eecs.umich.edu, mbone Subject: Re: mrouted on PC In-Reply-To: Your message of "Wed, 12 Jul 1995 09:27:46 +0200." <199507120727.JAA06606@faui40.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jul 1995 02:27:33 -0700 From: "Amancio Hasty Jr." Oops, Xaccel is Thomas Roell's company and he does have mpeg support at least he has an X server over there working with it. Well, I have the Talisman mpeg playback board . The board works rather well on VGA mode and is capable of NTSC output. I wrote simple X app which can display an mpeg stream on a window with support for resize and scaling . Is great to watch a long stretched movie like star trek while you type e-mail :) I plan to get my hands on a h.261 board soon like in a week or two pending on the availability of the board. At any rate, I expect the PC land this year to be flooded with low cost hardware assist mpeg solutions. Compaq signed a deal with S3 corp to build right on the motherboard mpeg support integrated with their S3 Trio graphic chipset -- that translates to crystal clear display with no compatibility hazzles at the vga level. Enjoy, Amancio >>> Toerless Eckert said: > > Actually, since I am here . Is anyone working on porting the > > X11R5 video extensions to X11R6 or working on mpeg hardware support > > on the X11R6 server side. > > I am not quite sure what Xaccell is based on (R5/R6) i think it's R6, > but then i don't know what's the big difference in a server between > R5/R6 anyway. At least Xaccell supports the XVideo extensions for live > video and framegrabbing for some cards in a PC, and it's working quite > well (i've got a Spea Showtime). It does not have support for the > mpeg decoder on that board or any other mpeg decoder yet, though. The > main problem seems to be that there really is no standardised X > interface to that functionality. > > > I have an mpeg board working on FreeBSD and I am looking into providing > > hardware assist for mpeg and H.261 . > > What video card are you using ? Amancio Hasty Hasty Software Consulting Services Tel: 415-495-3046, Fax 415-495-3046, Cellular: 415-309-8434 e-mail: hasty@star-gate.com From list-mgr@ISI.EDU Tue Jul 11 19:34:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 02:40:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 02:34:50 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 02:34:49 -0700 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with SMTP id CAA02748; Wed, 12 Jul 1995 02:34:28 -0700 Message-Id: <199507120934.CAA02748@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6delta 4/7/95 To: Mark Handley Cc: Ching-Tien TSAI , mbone Subject: Re: API for group communication wanted In-Reply-To: Your message of "Wed, 12 Jul 1995 09:53:22 BST." <11017.805539202@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jul 1995 02:34:27 -0700 From: "Amancio Hasty Jr." >>> Mark Handley said: > > >Since I did not receive any response from my previous post, I am reposting > >it. > >___________________________________________________________________________ __ > > > >Can anyone tell me where I can find APIs or example programs to support gro up Do archie on nv or vic both are capable of ip multicasting and the source code is available . If you can't find nv or vic you can download them from: freebsd.cdrom.com:/.3/FreeBSD/2.0.5-RELEASE/distfiles BTW: A library to support the network aspects for voice and video is not a bad idea... Hope this helps, Amancio From list-mgr@ISI.EDU Tue Jul 11 23:02:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 06:07:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 06:06:11 -0700 Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 06:04:54 -0700 From: bmanning@ISI.EDU Posted-Date: Wed, 12 Jul 1995 06:02:40 -0700 (PDT) Message-Id: <199507121302.AA19080@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 12 Jul 1995 06:02:41 -0700 Subject: Re: New Reflector info (fwd) To: mbone Date: Wed, 12 Jul 1995 06:02:40 -0700 (PDT) Cc: nanog@merit.edu, eof-list@ripe.net, zanog@zanog.org X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1378 > We have a version of the new reflector code up on the Cornell > reflector at 132.236.91.204 now. However, it only tracks for new versions > of the desktop app, the Mac version of which will go to alpha testers today > maybe. We're trying to update the reflector so it will also track (more > crudely) the old versions of the app. As this will be the first version of > the reflector to be released in binary only (except to source licensees), > we're co-ordinating with White Pine to get it compiled for all the popular > platforms and binaries posted. We may have updates out several times in > the next couple weeks as the bw management algorithms get tuned. > If all goes well, we should have both Mac and Windows apps out as > beta versions by the time of IETF. > Some thought on best way to configure reflectors for IETF is > probably a good idea. In general, a feed from a reflector at IETF to the > mbone, picked up by other reflectors in useful places might be a good > approach. > > Cheers, -Dick > > >Bill Manning from ISI is trying to set up and MBONE/CU-SeeMem > >transmission of some IETF sessions from Sweden in 2 weeks. He > >wanted to know when the nex reflector software with the > >better bandwidth management will be released - and if not before > >IETF, is there a way to push the release day up.. > > > >martyne > > --bill From list-mgr@ISI.EDU Tue Jul 11 22:57:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 06:02:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 06:00:00 -0700 Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 05:59:58 -0700 From: bmanning@ISI.EDU Posted-Date: Wed, 12 Jul 1995 05:57:44 -0700 (PDT) Message-Id: <199507121257.AA19066@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 12 Jul 1995 05:57:44 -0700 Subject: Call for Mbone reflectors To: nanog@merit.edu, eof-list@ripe.net, zanog@zanog.org Date: Wed, 12 Jul 1995 05:57:44 -0700 (PDT) Cc: mbone X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1848 > > Bill, > > We have the mbone slot reserved for ISN. I will post this note to teachers > today and begin doing what I can to get them involved. What needs to be > done to push providers to get reflectors set up? > > Thanks, > J > =-=-=-=-NOTE TO POST TO ED LISTS-=-=-=-= > To all Educators able to use CU-SeeMe this summer! > > The Internet School Networking (ISN) group of the Internet Engineering > Task Force (IETF) will be broadcasting its thrice-yearly meeting over the > mbone on Monday, July 17. The meeting will be held in Stockholm, Sweden, > from 9:30 to 11:30 a.m. local time. > > If you would like to participate, please notify me as soon as possible! > > Thanks, > Jennifer Sellers > ISN Co-chair > > ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ > sellers@quest.arc.nasa.gov NASA's K-12 Internet Initiative > gopher quest.arc.nasa.gov Sterling Software > http://quest.arc.nasa.gov 700 13th Street, NW > phone: 202-434-8954 Suite 950 > fax: 202-434-4599 Washington, DC 20005 > ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ > > =-=-=-=-END OF NOTE TO ED LISTS-=-=-=-= > Hi all, If we are actually going to have real teachers participate in the ISN - WG remotely, there should be an identified reflector net setup, since most of the target audience has access to CUSeeMe and not traditional mbone tools. (Odd, traditional & mbone linked together.. :) It should be possible to identify where on the Mbone topology current reflectors sit, and then we will have a better idea where new reflectors need to be. What I really want to avoid is a reflector hosted at the IETF site and all that CUSeeMe traffic converging on that machine.. :) Any clues/assistance etc. would be helpful. -- --bill From list-mgr@ISI.EDU Wed Jul 12 14:30:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 07:33:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 07:31:56 -0700 Received: from fenris.hiof.no by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 07:31:54 -0700 Received: from abdallah.hiof.no by fenris.hiof.no with SMTP (PP) id <23976-0@fenris.hiof.no>; Wed, 12 Jul 1995 16:31:46 +0200 Received: by abdallah.hiof.no (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA10683; Wed, 12 Jul 1995 14:30:30 GMT Date: Wed, 12 Jul 1995 14:30:28 +0000 From: Borre Ludvigsen To: mbone Subject: OFF? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE How do I get off this list? B=F8rre Ludvigsen - http://www.hiof.no/~borrel=20 finger: borrel@abdallah.hiof.no From list-mgr@ISI.EDU Wed Jul 12 06:30:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 07:31:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 07:31:10 -0700 Received: from edf-bb.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 07:31:10 -0700 Message-Id: <199507121431.AA10295@venera.isi.edu> Received: by edf-bb.gsfc.nasa.gov (1.38.193.4/16.2) id AA26361; Wed, 12 Jul 1995 10:30:46 -0400 From: Ching-Tien TSAI Subject: Re: API for group communication wanted To: M.Handley@cs.ucl.ac.uk, hasty@rah.star-gate.com Date: Wed, 12 Jul 95 10:30:46 EDT Cc: mbone In-Reply-To: <11017.805539202@cs.ucl.ac.uk>; from "Mark Handley" at Jul 12, 95 9:53 am Mailer: Elm [revision: 70.85] > IP multicast has the property that senders do not need to be in the > group they send to, and senders do not know of the exitence of > receivers unless you add an application layer protocol to inform > them. > > Is this the information you were looking for? > Thanks for your response. What I am looking for is an API which allows unicast and multicast communication within a single group. For this functionality, it is like the group communication ability as provided by the ISIS distributed kit or RMP(Reliable Multicast Protocol). On the other hand, the API shall allow hosts to join or quit from a group at any time without disrupting the group communications. For RMP, if a member did not leave a group properly, the whole group will be reformed. For VAT example, athough it provide a way for a unicast host to receive traffic sent to a multicast group, but this connection can not be initiated from the unicast host alone, and has to be setup manually at both ends. So are you aware of any API or examples can do what I want? That is to allow sender makes a call to send data to a single group, and the API sends data to all members (whether unicast or multicast) of the group. It shall also allow any hosts to join or quit from the group freely without interrupting the group communication. BTW, the data received from this API can be unreliable and unordered. Thanks for any information. Ching Hughes Information Technology Corp. ching@edf-bb.gsfc.nasa.gov From list-mgr@ISI.EDU Wed Jul 12 06:16:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 07:18:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 07:17:12 -0700 Received: from edf-bb.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 07:17:11 -0700 Message-Id: <199507121417.AA09975@venera.isi.edu> Received: by edf-bb.gsfc.nasa.gov (1.38.193.4/16.2) id AA26266; Wed, 12 Jul 1995 10:16:55 -0400 From: Ching-Tien TSAI Subject: Re: API for group communication wanted To: M.Handley@cs.ucl.ac.uk, hasty@rah.star-gate.com:wq Date: Wed, 12 Jul 95 10:16:54 EDT Cc: mbone In-Reply-To: <11017.805539202@cs.ucl.ac.uk>; from "Mark Handley" at Jul 12, 95 9:53 am Mailer: Elm [revision: 70.85] > IP multicast has the property that senders do not need to be in the > group they send to, and senders do not know of the exitence of > receivers unless you add an application layer protocol to inform > them. > > Is this the information you were looking for? > Thanks for your response. What I am looking for is an API which allows unicast and multicast communication within a single group. For this functionality, it is like the group communication ability as provided by the ISIS distributed kit or RMP(Reliable Multicast Protocol). On the other hand, the API shall allow hosts to join or quit from a group at any time without disrupting the group communications. For RMP, if a member did not leave a group properly, the whole group will be reformed. For VAT example, athough it provide a way for a unicast host to receive traffic sent to a multicast group, but this connection can not be initiated from the unicast host alone, and has to be setup manually at both ends. So are you aware of any API or examples can do what I want? That is to allow sender makes a call to send data to a single group, and the API sends data to all members (whether unicast or multicast) of the group. It shall also allow any hosts to join or quit from the group freely without interrupting the group communication. BTW, the data received from this API can be unreliable and unordered. Thanks for any information. Ching Hughes Information Technology Corp. ching@edf-bb.gsfc.nasa.gov From list-mgr@ISI.EDU Wed Jul 12 03:22:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 10:22:54 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 10:22:50 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id KAA14224; Wed, 12 Jul 1995 10:22:34 -0700 Date: Wed, 12 Jul 1995 10:22:34 -0700 From: Dino Farinacci Message-Id: <199507121722.KAA14224@stilton.cisco.com> To: mdella@internex.net Cc: mbone-na In-Reply-To: "Marcos Della"'s message of Wed, 12 Jul 1995 01:26:51 -0700 <9507120126.ZM2052@intrepid> Subject: Looking for an mbone feed. >> ip multicast-routing >> ! >> interface Tunnel0 >> no ip address >> ip pim dense-mode >> tunnel source Ethernet0/4 >> tunnel destination 192.9.5.5 >> tunnel mode dvmrp You need to configure an IP address or make the tunnel unnumbered. See ftp.cisco.com:dino/multicast/Quickstart-dvmrp for details. Dino From list-mgr@ISI.EDU Wed Jul 12 23:06:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 13:12:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 13:06:22 -0700 Received: from edina.xenologics.com by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 13:06:08 -0700 Received: from [194.77.7.96] (slip-96.xenologics.com [194.77.7.96]) by edina.xenologics.com (8.6.8.1/8.6.6) with SMTP id WAA07214 for ; Wed, 12 Jul 1995 22:07:54 +0200 Message-Id: <199507122007.WAA07214@edina.xenologics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jul 1995 22:06:59 +0100 To: mbone From: m.niederberger@edina.xenologics.com (Michael Niederberger) Subject: subscribe subscribe From list-mgr@ISI.EDU Wed Jul 12 06:36:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 13:41:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 13:36:43 -0700 Received: from hq.barrnet.net by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 13:36:39 -0700 Received: from [36.178.0.13] (Yundt-ISDN.Stanford.EDU [36.178.0.13]) by hq.barrnet.net (8.6.10/HQ-Len) with SMTP id NAA01363; Wed, 12 Jul 1995 13:38:41 -0700 X-Sender: wyundt@hq.barrnet.net (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Jul 1995 13:36:10 -0700 To: Henry Kilmer From: wyundt@WR.BBNPLANET.COM (Bill Yundt) Subject: Re: mrouted tunnel needed Cc: mbone At 8:45 AM 7/11/95, Henry Kilmer wrote: >Why do you recomend universities when pretty much >all of the larger providers are supporting the mbone? My suggestion was qualified ..... I said if you are a research organization ... which was meant to imply an affiliation with a university. Reason: higher ed organizations may support such collaborations and often have the highest local bandwidth to the Internet "core". ...Bill From list-mgr@ISI.EDU Thu Jul 13 18:59:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 16:03:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 15:58:34 -0700 Received: from brolga.cc.uq.oz.au by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 15:58:33 -0700 Received: from [130.102.128.199] (actually monet.cc.uq.oz.au) by brolga.cc.uq.oz.au with SMTP (PP); Thu, 13 Jul 1995 08:58:04 +1000 X-Sender: ccrees@brolga.cc.uq.edu.au Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Jul 1995 08:59:04 +1000 To: mbone From: ccrees@cc.uq.edu.au (Graham REES) unsubscribe --------------------------------------------------------- Graham Rees EMail: G.Rees@cc.uq.edu.au Deputy Director Tel: + 61 7 365 4143 Prentice Centre Fax: + 61 7 365 4477 The University of Queensland Queensland 4072 --------------------------------------------------------- From list-mgr@ISI.EDU Wed Jul 12 09:59:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 17:04:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 17:00:04 -0700 Received: from cavebear.com (pax.cavebear.com) by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 17:00:03 -0700 Received: by cavebear.com (4.1/SMI-4.1) id AA11088; Wed, 12 Jul 95 16:59:47 PDT Date: Wed, 12 Jul 1995 16:59:46 -0700 (PDT) From: Stephen Casner X-Sender: casner@pax.cavebear.com To: Borre Ludvigsen Cc: mbone Subject: Re: OFF? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 12 Jul 1995, Borre Ludvigsen wrote: >=20 > How do I get off this list? >=20 > B=F8rre Ludvigsen - http://www.hiof.no/~borrel=20 > finger: borrel@abdallah.hiof.no Since there has been a spate of these messages lately, I'll respond publically: The mbone mailing list is structured as a hierarchy of regional and national mailing lists. Following the usual convention, send a message to mbone-request@isi.edu and you will receive a canned reply telling you where the appropriate -request address for your area. =09=09=09=09=09=09=09-- Steve From list-mgr@ISI.EDU Wed Jul 12 19:27:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 20:14:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 20:09:12 -0700 Received: from NS.METROLINK.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 12 Jul 1995 20:09:10 -0700 Received: from ankh.metrolink.com by ns.metrolink.com with SMTP id AA15789 (5.67b/IDA-1.5 for ); Wed, 12 Jul 1995 23:09:04 -0400 Received: by ankh.metrolink.com id AA02726 (5.67b/IDA-1.5 for mbone@venera.isi.edu); Wed, 12 Jul 1995 23:27:28 -0400 Date: Wed, 12 Jul 1995 23:27:28 -0400 From: "Garry M. Paxinos" Message-Id: <199507130327.AA02726@ankh.metrolink.com> To: Toerless Eckert Cc: hasty@rah.star-gate.com (Amancio Hasty Jr.), thalerd@zip.eecs.umich.edu, mbone Subject: Re: mrouted on PC In-Reply-To: <199507120727.JAA06606@faui40.informatik.uni-erlangen.de> References: <199507111943.MAA00672@rah.star-gate.com> <199507120727.JAA06606@faui40.informatik.uni-erlangen.de> Toerless Eckert writes: > > Actually, since I am here . Is anyone working on porting the > > X11R5 video extensions to X11R6 or working on mpeg hardware support > > on the X11R6 server side. > > I am not quite sure what Xaccell is based on (R5/R6) i think it's R6, > but then i don't know what's the big difference in a server between > R5/R6 anyway. At least Xaccell supports the XVideo extensions for live > video and framegrabbing for some cards in a PC, and it's working quite > well (i've got a Spea Showtime). It does not have support for the > mpeg decoder on that board or any other mpeg decoder yet, though. The > main problem seems to be that there really is no standardised X > interface to that functionality. We currently have support running in house, and have demonstrated it at a conference (QNX 95) a couple months ago, for the Matrox Marvel II with mpeg hardware decompression. We also have support for the Matrox XPress JPEG hardware codec board. It should be released shortly. Not to mention we've had Xv support in our product for several years (since '91.) Sorry for the "commercial." Hmm, to try and make up for it, we're planning a very interesting MBONE schedule for SIGGRAPH 95. Please contact me if you are planning on attending SIGGRAPH and would be interested in helping with the Web and/or MBONE activities. Take care, Pax. Co-Chair SIGGRAPH95 ONLINE Metro Link Incorporated. 4711 N. Powerline Rd. Fort Lauderdale Fl, 33309 Voice: +1.305.938.0283x414 Fax: +1.305.938.1982 Email: pax@metrolink.com URL: http://www.flsig.org/people/garryp "The real voyage of discovery consists not in seeking new landscapes but in having new eyes." -Proust From list-mgr@ISI.EDU Thu Jul 13 10:49:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 01:54:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 01:49:43 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 01:49:43 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 13 Jul 1995 01:49:41 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 1995 09:49:15 +0100 To: Sean Doran Cc: mbone Subject: Re: mrouted tunnel needed In-Reply-To: Your message of "Thu, 13 Jul 95 09:39:49 BST." <12294.805624789@cs.ucl.ac.uk> Date: Thu, 13 Jul 95 09:49:08 +0100 Message-Id: <1316.805625348@cs.ucl.ac.uk> From: Jon Crowcroft >"Why do I get lousy TCP performance?" "Because your link is >saturated with MBONE traffic, that's why". >Hmm, sheer genius, yes? Sean, lets see now, we rate limit ALL the europoean mbone tunnels to 512kbps we have 8Mbps UK-US academic bandwdth and somewhere between 34 and 155 Mbps inside the UK now, how come the mbone traffic is saturating our links? well, no, it isn';t on close examination, it is web traffic not going via prxy caching servers that is trashing our links now in your case, are your links < 512kbps or something? this mbone bashing is daft...the previous discussion was about non-multicast, non-backing off traffic - this remark is about a non-problem and please why do you think academics think you are an "Evil Commercial Network"? if you can provide our backbone and services at the line + people costs we currently pay (which are not-for profit, but are NOT subsidized) then you are free to bid - in fact, in europe, for any contract over 300k, it has to be open tender....the UK contract comes up again next year.... as an aside, outside the US (not relevant to this particular request for a feedd, but for future reference): it is also not the case yet, that "most" internet providers in europe provide mbone........most that i know of are still considering it.... jon From list-mgr@ISI.EDU Thu Jul 13 13:57:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 03:02:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 02:57:48 -0700 Received: from survis.surfnet.nl by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 02:57:44 -0700 Received: from survis.surfnet.nl by survis.surfnet.nl with SMTP (PP); Thu, 13 Jul 1995 11:57:28 +0200 To: mbone Cc: Erik-Jan Bos Subject: Mbone tunnels between Europe and the US From: Erik-Jan Bos X-Mailer: MH X-Organization: SURFnet bv, Utrecht, The Netherlands X-Phone-Number: +31 30 305305 X-Fax-Number: +31 30 305329 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <4646.805629445.1@SURFnet.nl> Date: Thu, 13 Jul 1995 11:57:25 +0200 Message-Id: <4647.805629445@SURFnet.nl> Sender: Erik-Jan.Bos@SURFnet.nl Mbone, a few people in Europe have been busy reengineering the European part of the Mbone for the upcoming IETF. The backbone for Europe will look like the PS file that can be found on: ftp://ftp.nic.surfnet.nl/surfnet/net-management/mbone/mbone2.ps Regarding the connections to the US we are experiencing some difficulty and that's why I now address the global list "mbone@isi.edu". The drafted plan includes an Mbone tunnel directly from the IETF hotel to a Mbone router at the US East-coast (a PSI Mbone router). However, the colleagues from Stockholm have been unsuccessful in reaching somebody at PSI on this. More important the 34M line between Stockholm and Pennsauken is up and there is or will be a peering with ANS in Pennsauken. There even can be a true backup from Stockholm to the US with a secondary backup through Amsterdam and CERN. Bjorn Carlsson writes: > If we used mbone-east.ans.net, we could also setup the tunnel to > stockholm.mbone.ebone.net to go over MAE-E and the 2x2Mb lines and the tunnel > to the IETF MBONE router to use the new 34M over Pensauken (and internal ANS > infrastructure to Pensauken). This should buy us nice backup should the > 34M fail. I think this is an excellent idea. How do the ANS and other US people think about this? An updated picture can be found at: ftp://ftp.nic.surfnet.nl/surfnet/net-management/mbone/mbone3.ps __ Erik-Jan. From list-mgr@ISI.EDU Thu Jul 13 15:48:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 04:55:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 04:50:00 -0700 Received: from felix.crihan.fr (felix-f.crihan.fr) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 04:49:50 -0700 Received: from athena.crihan.fr (athena-e.crihan.fr [192.93.25.2]) by felix.crihan.fr (8.6.10/8.6.10) with ESMTP id NAA26438; Thu, 13 Jul 1995 13:49:35 +0200 Received: from athena.crihan.fr (localhost [127.0.0.1]) by athena.crihan.fr (8.6.10/8.6.10) with ESMTP id NAA06447; Thu, 13 Jul 1995 13:48:46 +0200 Message-Id: <199507131148.NAA06447@athena.crihan.fr> X-Mailer: exmh version 1.6.1 5/23/95 To: mbone Cc: am@crihan.fr Subject: New reflector (4.0b1) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jul 1995 13:48:46 +0200 From: Alain Massiot Crihan Hi, I just get the new reflector on cornell ftp server, but I don't understand the way to use it (not how to configure it), I can't run them on Sun plateform (under SunOS or Solaris). Could somebody explain what to do, in order to have it running ?? Thanks -- --------------------------------------------------------------------- Alain Massiot | C R I H A N | Centre de Ressources Informatiques Phone: +33 35 59 61 59 | de Haute Normandie Fax : +33 35 59 61 40 | Parc Technologique de la Vatine Mail : Alain.Massiot@crihan.fr | 32, rue Raymond Aron Info : crihan-admin@crihan.fr | 76130 Mont-Saint-Aignan, France --------------------------------------------------------------------- From list-mgr@ISI.EDU Thu Jul 13 07:29:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 09:43:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 09:42:55 -0700 Received: from access1.digex.net by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 09:42:54 -0700 Received: from houston_cc_smtp.hai-net.com (houston_cc_smtp.hai-net.com [204.91.94.67]) by access1.digex.net (8.6.12/8.6.12) with SMTP id MAA15379 ; for ; Thu, 13 Jul 1995 12:42:19 -0400 From: rsingleton@hai-net.com Received: from cc:Mail by houston_cc_smtp.hai-net.com id AA805664888; Thu, 13 Jul 95 12:29:37 EST Date: Thu, 13 Jul 95 12:29:37 EST Message-Id: <9506138056.AA805664888@houston_cc_smtp.hai-net.com> To: Alain Massiot Crihan , mbone Cc: am@crihan.fr Subject: Re: New reflector (4.0b1) I would like some of the same info if someone can help on this issue. I am looking at setting up an SGI extreme as a reflector for company conf use. thx Rickie _______________________________________________________________________________ Subject: New reflector (4.0b1) From: Alain Massiot Crihan at internet Date: 7/13/95 10:10 Hi, I just get the new reflector on cornell ftp server, but I don't understand the way to use it (not how to configure it), I can't run them on Sun plateform (under SunOS or Solaris). Could somebody explain what to do, in order to have it running ?? Thanks -- --------------------------------------------------------------------- Alain Massiot | C R I H A N | Centre de Ressources Informatiques Phone: +33 35 59 61 59 | de Haute Normandie Fax : +33 35 59 61 40 | Parc Technologique de la Vatine Mail : Alain.Massiot@crihan.fr | 32, rue Raymond Aron Info : crihan-admin@crihan.fr | 76130 Mont-Saint-Aignan, France --------------------------------------------------------------------- From list-mgr@ISI.EDU Thu Jul 13 07:49:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 10:50:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 10:49:50 -0700 Received: from marley.ecl.wustl.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 10:49:49 -0700 Received: by marley.ecl.wustl.edu (5.x/ECL-A1.27) id AA03150; Thu, 13 Jul 1995 12:49:45 -0500 Date: Thu, 13 Jul 1995 12:49:45 -0500 From: sifu@ecl.wustl.edu (Ben Regen) Message-Id: <9507131749.AA03150@marley.ecl.wustl.edu> To: mbone Subject: CISCO problems While attempting to get my network on the Mbone, I was told about some problems with running our CISCO router as an Mbone router. I was wondering if anyone could expand on any possible problems or tell me if the problems still exist. Any help would be greatly appreciated! Thanks-- Ben Regen sifu@ecl.wustl.edu From list-mgr@ISI.EDU Thu Jul 13 12:06:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 15:07:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 15:07:29 -0700 Received: from MAIL.TAMU.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 15:07:28 -0700 Received: from vcsun2.tamu.edu (vcsun2.tamu.edu [128.194.169.97]) by mail.tamu.edu (8.6.10/8.6.10) with SMTP id RAA15989 for ; Thu, 13 Jul 1995 17:07:27 -0500 Received: by vcsun2.tamu.edu (5.x/SMI-SVR4) id AA13972; Thu, 13 Jul 1995 17:06:43 -0500 Date: Thu, 13 Jul 1995 17:06:43 -0500 From: mbone@vcsun2.tamu.edu (MBone Mailing List) Message-Id: <9507132206.AA13972@vcsun2.tamu.edu> To: mbone Subject: subscribe X-Sun-Charset: US-ASCII subscribe From list-mgr@ISI.EDU Thu Jul 13 14:34:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 15:41:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 15:35:08 -0700 Received: from seka.reston.ans.net by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 13 Jul 1995 15:35:06 -0700 Received: by seka.reston.ans.net (4.1/SMI-4.1) id AA10218; Thu, 13 Jul 95 18:34:53 EDT Date: Thu, 13 Jul 95 18:34:53 EDT From: enger@seka.reston.ans.net (Robert M. Enger) Message-Id: <9507132234.AA10218@seka.reston.ans.net> To: erik-jan.bos@surfnet.nl Subject: Re: Mbone tunnels between Europe and the US Cc: mbone Eric-Jan: I would be glad to provide main and/or back-up tunnels. Please contact me as soon as possible. thanks, Bob Enger From list-mgr@ISI.EDU Fri Jul 14 02:31:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 14 Jul 1995 09:39:11 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 14 Jul 1995 09:39:10 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id JAA20522; Fri, 14 Jul 1995 09:31:43 -0700 Message-Id: <199507141631.JAA20522@rx7.ee.lbl.gov> To: hfb@OIRM.SBA.GOV Cc: mbone-na Subject: root@bacardi (199.171.55.20) sending 300kb/s video to mbone Date: Fri, 14 Jul 95 09:31:42 PDT From: Van Jacobson The user root@bacardi (199.171.55.20) is sending 300kb/s nv video of a screendump to the NASA shuttle mbone session. This video is trashing several active, legitimate mbone sessions. It does not appear to be possible to reach this machine via email to ask this person to stop. The total bandwidth of the mbone is only 500kb/s and policy limits any one video session to at most 128kb/s and less if possible. The MBone also very busy this week and next with a Shuttle flight & the IETF meeting in Stockholm. It is never a good idea to send screendumps via nv (mbone bandwidth is very limited & treated as a precious resource) and it it not a good idea to send anything during the next week. Thanks. - Van Jacobson From list-mgr@ISI.EDU Fri Jul 14 09:36:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 14 Jul 1995 10:41:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 14 Jul 1995 10:41:01 -0700 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 14 Jul 1995 10:41:00 -0700 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA24040; Fri, 14 Jul 1995 13:37:02 +0500 Message-Id: <9507141737.AA24040@msf.psi.net.> To: Erik-Jan Bos Cc: mbone Subject: Re: Mbone tunnels between Europe and the US In-Reply-To: Your message of "Thu, 13 Jul 1995 11:57:25 +0200." <4647.805629445@SURFnet.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <24038.805743409.1@msf.psi.net> Date: Fri, 14 Jul 1995 13:36:49 -0400 From: "Mark S. Fedor" Content-Length: 499 > > The drafted plan includes an Mbone tunnel directly from the IETF hotel to > a Mbone router at the US East-coast (a PSI Mbone router). However, the > colleagues from Stockholm have been unsuccessful in reaching somebody at > PSI on this. > The tunnel to the IETF mrouter from mae-bone.psi.net was configured yesterday and it looks up now. mae-bone.psi.net was also upgraded to the latest multicast kernel and mrouted. mail to mbone@psi.com if you see any problems with this. thanks, Mark From list-mgr@ISI.EDU Fri Jul 14 21:43:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 14 Jul 1995 10:44:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 14 Jul 1995 10:44:42 -0700 Received: from sunic.sunet.se by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 14 Jul 1995 10:44:36 -0700 Received: from tuborg.pilsnet.sunet.se by sunic.sunet.se (8.6.8/2.03) id TAA19283; Fri, 14 Jul 1995 19:44:34 +0200 Received: from localhost.sunet.se by tuborg.pilsnet.sunet.se (8.6.10/6.0) id TAA03911; Fri, 14 Jul 1995 19:43:02 +0200 Message-Id: <199507141743.TAA03911@tuborg.pilsnet.sunet.se> To: fedor@msf.psi.net Cc: erik-jan.bos@surfnet.nl, mbone Subject: Re: Mbone tunnels between Europe and the US From: Bjorn Carlsson In-Reply-To: Your message of "Fri, 14 Jul 1995 13:36:49 -0400" References: <9507141737.AA24040@msf.psi.net.> X-Mailer: Mew beta version 0.96 on Emacs 19.28.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 14 Jul 95 19:43:00 +0200 Sender: bc@sunet.se Yes, everything looks just fine with the tunnels to PSI. Thanks Mark! --BC > The tunnel to the IETF mrouter from mae-bone.psi.net was configured > yesterday and it looks up now. > > mae-bone.psi.net was also upgraded to the latest multicast kernel and > mrouted. > > mail to mbone@psi.com if you see any problems with this. > > thanks, > > Mark > From list-mgr@ISI.EDU Fri Jul 14 08:22:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 14 Jul 1995 11:32:34 -0700 Received: from balder.ssds.com by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 14 Jul 1995 11:32:30 -0700 Received: (from mail@localhost) by balder.ssds.com (8.6.9/8.6.9.SSDSnet-hub) id MAA29654; Fri, 14 Jul 1995 12:28:29 -0600 Received: from denver(134.127.16.1) by balder via smap (V1.3) id sma029651; Fri Jul 14 12:28:28 1995 Received: from sanjose.ssds.com (sanjose.ssds.com [134.127.10.1]) by denver.ssds.com (8.6.9/8.6.9.SSDSnet-hub) with SMTP id MAA10552; Fri, 14 Jul 1995 12:28:26 -0600 Received: from freke (pc_sjc4) by sanjose.ssds.com (5.x/SMI-SVR4) id AA00053; Fri, 14 Jul 1995 11:27:55 -0700 Message-Id: <9507141827.AA00053@sanjose.ssds.com> X-Sender: cds@sanjose.ssds.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Jul 1995 13:22:16 -0500 To: Van Jacobson , hfb@oirm.sba.gov From: Chris.Swanson@ssds.com (Chris Swanson - SSDS) Subject: Re: root@bacardi (199.171.55.20) sending 300kb/s video to mbone Cc: mbone-na It appears to be machine at the SBA in Washington. Have have contacted the net administrator there and they are tracking it down. Regards, -=Chris At 09:31 14-7-1995 PDT, Van Jacobson wrote: >The user root@bacardi (199.171.55.20) is sending 300kb/s nv >video of a screendump to the NASA shuttle mbone session. This >video is trashing several active, legitimate mbone sessions. >It does not appear to be possible to reach this machine via email >to ask this person to stop. > >The total bandwidth of the mbone is only 500kb/s and policy >limits any one video session to at most 128kb/s and less if >possible. The MBone also very busy this week and next with a >Shuttle flight & the IETF meeting in Stockholm. It is never >a good idea to send screendumps via nv (mbone bandwidth is >very limited & treated as a precious resource) and it it not >a good idea to send anything during the next week. Thanks. > > - Van Jacobson > > / Chris Swanson ____/ ____/ ___ / ____/ Engineer ____ / ____ / /__/ / ____ / 8841 Nicollet Ave South _______/ _______/ _______/ _______/ Bloomington, MN 55420 business driven technology solutions. (612) 888-4045 FAX (612) 888-4066 From list-mgr@ISI.EDU Fri Jul 14 08:13:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 14 Jul 1995 15:16:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 14 Jul 1995 15:13:46 -0700 Received: from sgi.sgi.com (SGI.COM) by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 14 Jul 1995 15:13:45 -0700 Received: from tree.engr.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for <@sgi.sgi.com:mbone@isi.edu> id PAA09226; Fri, 14 Jul 1995 15:13:43 -0700 Received: by tree.engr.sgi.com (940816.SGI.8.6.9/911001.SGI) for mbone@isi.edu id PAA21209; Fri, 14 Jul 1995 15:13:42 -0700 From: "Bill Nowicki" Message-Id: <9507141513.ZM21207@tree.engr.sgi.com> Date: Fri, 14 Jul 1995 15:13:39 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: mbone Subject: Multicast 3.x for SGI IRIX Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii For those who use Silicon Graphics equipment, please get a new: ftp://ftp.sgi.com/sgi/ipmcast/IRIX5/5.3/mrouted3.4.tar.Z And follow the instructions therein. This version should be a proper supserset of patch 530, and patch 317, so it can be installed with or without those patches. The wheels are turning, ever so slowly, to make this into an officially suported patch. When you see patch number 670 come through the official channels, it should be essentially the same. From list-mgr@ISI.EDU Sat Jul 15 02:09:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 15 Jul 1995 02:16:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 15 Jul 1995 02:09:12 -0700 Received: from poppy.ipc.hiroshima-u.ac.jp by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 15 Jul 1995 02:09:07 -0700 Received: from localhost by poppy.ipc.hiroshima-u.ac.jp (5.x/2.8Wb) id AA06908; Sat, 15 Jul 1995 18:09:01 +0900 Return-Path: Message-Id: <9507150909.AA06908@poppy.ipc.hiroshima-u.ac.jp> To: mbone Subject: Announcement of HIROSHIMA-LIVE(Aug.6) From: Kouji Nishimura Date: Sat, 15 Jul 1995 18:08:59 +0900 Sender: kouji@poppy.ipc.hiroshima-u.ac.jp Hi MBoner, We are preparing to broadcast the 50-th Hiroshima Peace Memorial Ceremony, which will be held on August 6 at Hiroshima Peace Memorial Park. CSI, Chugoku-Shikoku Internet Council (regional internet project in Japan), presents the visual and five languages (English, French, Spanish, German and Polish or Portuguese) information using MBone and World Wide Web as a new "Kataribe". Our broadcasting plan is as follows: Session (with TTL=127) Video (nv,32kbps) from Hiroshima Peace Memorial Park Audio (dvi4,32kbps*5) narrations are provided in five languages, English, French, Spanish, German and the last one is Polish or Portuguese (not decided) Character (wb) circumstances, the Peace Declaration, etc. (English) Time-Table Live - Hiroshima Peace Memorial Ceremony (30 min.) from Aug. 6 08:00 JST (Aug. 5 23:00 UTC) Rebroadcast (30 min. each) from Aug. 6 10:00 JST (Aug. 6 01:00 UTC) from Aug. 6 12:00 JST (Aug. 6 03:00 UTC) from Aug. 6 14:00 JST (Aug. 6 05:00 UTC) from Aug. 6 16:00 JST (Aug. 6 07:00 UTC) from Aug. 6 18:00 JST (Aug. 6 09:00 UTC) See http://www.csi.ad.jp/hiroshima-live/ for further information. Any questions and comments should go to "86live@csi.ad.jp". HIROSHIMA-LIVE Project Kouji Nishimura (kouji@hiroshima-u.ac.jp) Chugoku-Shikoku Internet Council From list-mgr@ISI.EDU Wed Jul 15 20:12:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 16 Jul 1995 03:28:27 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 16 Jul 1995 03:27:59 -0700 Received: from elroy.jpl.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 16 Jul 1995 03:27:58 -0700 Received: from isolar.tujunga.ca.us by elroy.jpl.nasa.gov (4.1/SMI-4.1+DXR) id AA08547; Sun, 16 Jul 95 03:27:56 PDT Received: by isolar.Tujunga.CA.US (4.1/SATAN-6.6.6) id AA07707; Sun, 16 Jul 95 03:12:48 PDT Date: Sun, 16 Jul 95 03:12:48 PDT From: earle@isolar.Tujunga.CA.US (Greg Earle) Message-Id: <9507161012.AA07707@isolar.Tujunga.CA.US> To: mbone Subject: Re: Strange problem with mrouted machine Newsgroups: jpl.mail.mbone References: <9507031907.AA08849@wizard.gsfc.nasa.gov> <9507030856.AA20988@tamdhu.dcs.st-andrews.ac.uk> Organization: Personal Usenet site, Tujunga, CA USA Just a reminder from an old Sun hack: panic tracebacks are absolutely useless without symbolic references. If you know how to do this, do the obligatory "adb -k /vmunix /dev/mem" and feed all of your "Called from ..." addresses to "adb" to get symbolic addresses of tracebacks. Then post your panics here. If you don't know how to do this, I recommend you (a) enable crash dumps in /etc/rc.local; and (b) go out immediately and buy "Panic! UNIX System Crash Dump Analysis" by two old cronies of mine, Chris Drake and Kimberley Brown of Sun (SunSoft Press/Prentice Hall, ISBN 0-13-149386-8). Essential knowledge for debugging all SunOS/Solaris system crashes, not just those possibly induced by "mrouted" :-) - Greg In article <9507031907.AA08849@wizard.gsfc.nasa.gov> Bill Fink wrote: > I am getting similar errors on mbone-cf.gsfc.nasa.gov which is > running mrouted 3.4, but they aren't being seen on mbone2-f.gsfc.nasa.gov. > They first started showing up on June 16, and here are the dates and times > they have occurred (all times are EDT): ... >Jul 3 13:53:59 mbone vmunix: g1-g7: 908007e0, f8191c00, fce22d78, fce52d68, f82ab000, f8186000, f8186000 >Jul 3 13:53:59 mbone vmunix: Begin traceback... sp = f8152e80 >Jul 3 13:53:59 mbone vmunix: Called from f8042030, fp=f8152ee0, args=ff64ff00 86 ff64d300 2e ff64f900 0 >Jul 3 13:53:59 mbone vmunix: Called from f804ad84, fp=f8152f40, args=40 f801d838 0 ff64ff00 908001e1 f82411a0 >Jul 3 13:53:59 mbone vmunix: Called from f8005ca8, fp=f8152fa0, args=1 ff007000 f8041fb0 40 908001e2 f81925cc >Jul 3 13:53:59 mbone vmunix: Called from 52dc, fp=f82aac28, args=4 103d8 240 0 0 f7ffff28 >Jul 3 13:53:59 mbone vmunix: End traceback... >Jul 3 13:53:59 mbone vmunix: panic: Data fault ... >Jul 3 13:53:59 mbone vmunix: dumping to vp fce0cb2c, offset 69728 >Jul 3 13:53:59 mbone vmunix: 1271 total pages, dump succeeded >Jul 3 13:53:59 mbone vmunix: rebooting... > >mrouted is usually the process which experiences the data fault, but >occasionally it's another process which is using /dev/nit and once it >was tcpdump which also uses /dev/nit. > ... >Have others also seen these 'Data fault' kernel panics or have any >idea what might be causing them? > > -Bill > >P.S. mbone-cf.gsfc.nasa.gov is a Sun SPARCstation-IPX (sun4c) > running SunOS 4.1.3. Paul Harrington had written: >> {powers,turret}.dcs.st-and.ac.uk is a mrouter running 3.5 (haven't got >> around to upgrading it yet). It also runs as an nn 'headers only' news >> server which gets its feed from a local computing services machine >> which can spew out headers at wildly varying rates: often the lab >> machine crashes, loses its history and takes articles from anywhere. >> My setup runs a short exprire on the headers and can often get floods >> of old articles. >> >> So what has this to do with mrouted? Well, as you can see from the >> following trace, mrouted gets a fault which causes a panic. These >> panics are always preceded by the optimisation messages and these >> messages appear to be caused by swings in the disk consumption on var >> of nn. >> ... >> BAD TRAP >> pid 194, `mrouted': Data fault >> kernel read fault at addr=0x390, pme=0x0 >> Sync Error Reg 80 >> pc=0xf81147ac, sp=0xf8361c28, psr=0x4000c1, context=0x5 >> g1-g7: 0, 0, ffffff80, 3, f8362000, f8184000, f8184000 >> Begin traceback... sp = f8361c28 >> Called from f8049dcc, fp=f8361c88, args=800ae3 f8242438 f8157c00 0 3 f7ffff4c >> Called from f8066514, fp=f8361ce8, args=f8190040 1a f7ffffbc 100 1a f8244198 >> Called from f8064f5c, fp=f8361d48, args=ff64bc38 0 0 0 1 240 >> Called from f806813c, fp=f8361da8, args=ff64bc0c f8361e0c f8361e20 0 4000 1000 >> Called from f8067f10, fp=f8361e38, args=240 f8240bac 240 240 1 f8361e9c >> Called from f812d120, fp=f8361ec0, args=f8361fe0 3e8 f8166168 f8166550 f8362000 f8361fe0 >> Called from f8005a54, fp=f8361f58, args=f8362000 f8361fb4 f8361fe0 f8362000 f8362000 f8361fb4 >> Called from 4810, fp=f7fffee8, args=4 e508 240 0 0 f7ffff4c >> End traceback... >> panic: Data fault >> syncing file systems... done From list-mgr@ISI.EDU Sun Jul 16 09:43:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 16 Jul 1995 11:47:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 16 Jul 1995 11:46:59 -0700 Received: from access1.digex.net by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 16 Jul 1995 11:46:58 -0700 Received: from houston_cc_smtp.hai-net.com (houston_cc_smtp.hai-net.com [204.91.94.67]) by access1.digex.net (8.6.12/8.6.12) with SMTP id OAA27947 ; for ; Sun, 16 Jul 1995 14:46:50 -0400 From: rsingleton@hai-net.com Received: from cc:Mail by houston_cc_smtp.hai-net.com id AA805931562; Sun, 16 Jul 95 14:43:19 EST Date: Sun, 16 Jul 95 14:43:19 EST Message-Id: <9506168059.AA805931562@houston_cc_smtp.hai-net.com> To: nanog@merit.edu, eof-list@ripe.net, zanog@zanog.org, bmanning Cc: mbone Subject: Re: Call for Mbone reflectors Hi my name is Rickie Singleton from Arlington VA. I would like to become an active participant on the Mbone and I would like to set up a reflector. I will be using an SGI extreme 2. Can anyone point me in the right direction to get a reflector setup. I am hoping the mrouted 3.x will fix my mbone problem and I am currently running CUSEEME on my mac. Now comes the task of setting up a reflector on the SGI. Would appreciate any comments. thx Rickie ______________________________ Reply Separator _________________________________ Subject: Call for Mbone reflectors Author: bmanning@ISI.EDU at internet Date: 7/12/95 12:06 PM > > Bill, > > We have the mbone slot reserved for ISN. I will post this note to teachers > today and begin doing what I can to get them involved. What needs to be > done to push providers to get reflectors set up? > > Thanks, > J > =-=-=-=-NOTE TO POST TO ED LISTS-=-=-=-= > To all Educators able to use CU-SeeMe this summer! > > The Internet School Networking (ISN) group of the Internet Engineering > Task Force (IETF) will be broadcasting its thrice-yearly meeting over the > mbone on Monday, July 17. The meeting will be held in Stockholm, Sweden, > from 9:30 to 11:30 a.m. local time. > > If you would like to participate, please notify me as soon as possible! > > Thanks, > Jennifer Sellers > ISN Co-chair > > ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ > sellers@quest.arc.nasa.gov NASA's K-12 Internet Initiative > gopher quest.arc.nasa.gov Sterling Software > http://quest.arc.nasa.gov 700 13th Street, NW > phone: 202-434-8954 Suite 950 > fax: 202-434-4599 Washington, DC 20005 > ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ > > =-=-=-=-END OF NOTE TO ED LISTS-=-=-=-= > Hi all, If we are actually going to have real teachers participate in the ISN - WG remotely, there should be an identified reflector net setup, since most of the target audience has access to CUSeeMe and not traditional mbone tools. (Odd, traditional & mbone linked together.. :) It should be possible to identify where on the Mbone topology current reflectors sit, and then we will have a better idea where new reflectors need to be. What I really want to avoid is a reflector hosted at the IETF site and all that CUSeeMe traffic converging on that machine.. :) Any clues/assistance etc. would be helpful. -- --bill From list-mgr@ISI.EDU Tue Jul 18 06:09:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 05:08:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 05:08:27 -0700 Received: from patton.gate.asahi-net.or.jp (patton.asahi-net.or.jp) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 05:08:26 -0700 Return-Path: Received: from [202.32.120.173] by patton.gate.asahi-net.or.jp (8.6.10+2.4W/IIJ-I1.1) id VAA23233; Mon, 17 Jul 1995 21:06:14 +0900 From: fc9y-ymgc@asahi-net.or.jp Message-Id: <199507171206.VAA23233@patton.gate.asahi-net.or.jp> Date: Mon, 17 Jul 1995 21:09:18 +0900 To: MBone X-Sender: fc9y-ymgc@po.asahi-net.or.jp X-Mailer: Eudora-J(1.3.8.5-J13) help From list-mgr@ISI.EDU Sun Jul 16 22:18:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 05:19:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 05:19:07 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 05:19:03 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id FAA22656; Mon, 17 Jul 1995 05:18:59 -0700 Message-Id: <199507171218.FAA22656@rx7.ee.lbl.gov> To: root@atml.noc.interop.net, root@noc.interop.net Cc: mbone Subject: root@atma.noc.interop.net sending nv screendump to mbone Date: Mon, 17 Jul 95 05:18:58 PDT From: Van Jacobson User root@atma.noc.interop.net (45.211.0.113) has been sending 128kb/s of an nv screendump to the Shuttle Video session for the past 2 hours. The MBone is completely saturated this week with the two IETF sessions from Stockholm and the Shuttle flight so this video is causing significant packet loss. Neither the DNS nor mail seem to be configured for this machine so it doesn't seem possible to reach this user. If someone is nearby, could you ask them to please stop sending? Thanks. - Van Jacobson ps- As I've noted in the past, the human-factors engineering of nv is very poor given the MBone's very limited bandwidth: Nv doesn't respect the MBone ttl vs. bandwidth limits so novice users very often exceed those limits while exploring the tool. Nv also has a large "start sending" button that is easy to hit accidentally and, because of its x11 screen grabber, it will *always* send something when you hit "start sending". (Over the past year, I have monitored an average of 50 users *per day* sending nv screendumps to the MBone.) Sites might consider having novice users use vic in "nv mode" rather than nv since the vic user interface was designed to make these common, very antisocial, user mistakes impossible. From list-mgr@ISI.EDU Sun Jul 16 22:36:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 05:36:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 05:35:46 -0700 Received: from lanshark.sv.interop.net by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 05:35:45 -0700 Received: (from jim@localhost) by lanshark.sv.interop.net (8.6.9/8.6.9) id FAA02568; Mon, 17 Jul 1995 05:36:28 -0700 Date: Mon, 17 Jul 1995 05:36:28 -0700 (PDT) From: Jim Martin To: van@ee.lbl.gov Cc: mbone Subject: Yet another screwup from Interop Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Van, You'd think it was manditory .. every time we have a show in Tokyo, we screw up the MBone with some inadvertant click of a button. The session from atma has been shut down, and I'm increasing my outgoing threshold to 250 so it will take a very concious effort to send anything out. My appologies to everyone we screwed up ... the miscreant who did it _has_ been shot :) Jim Jim Martin Internet: jim@interop.net Network Engineering Fax: (408) 541-4121 Softbank Expos Phone: (408) 541-4166 From list-mgr@ISI.EDU Mon Jul 17 17:43:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 06:44:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 06:43:44 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 06:43:43 -0700 Received: from localhost.electrum.kth.se (cwe@localhost.electrum.kth.se [127.0.0.1]) by piraya.electrum.kth.se (8.6.10/8.6.9) with SMTP id PAA28059; Mon, 17 Jul 1995 15:43:36 +0200 Message-Id: <199507171343.PAA28059@piraya.electrum.kth.se> To: mbone, rem-conf@es.net Cc: mbone@ietf33.nordu.net Subject: IETF transmission... Date: Mon, 17 Jul 95 15:43:35 +0200 From: Christian Wettergren Hi! The IETF Multicast Production Team (tm :-)) wants to know how people have received the IETF transmissions during the first day. Loss percentage, what channels, how you would like to ask questions etc. We have so far receieved two problem reports; 1/ Bad reception at certain sites in the UK. This may be due to ATM-tunnel transitions, this is being investigated. Brunel.ac.uk had the following path; * mrouter.ietf33.nordu.net - stockholm.mbone.ebone.net - broodjeham.surfnet.nl - noc.ulcc.ja.net - - noc2.ulcc.ja.net - babbage.brunel.ac.uk ... We should have good quality at least as far as to broodjeham. 2/ Bad reception in Finland (goose.sms.fi) We believe this is also due to that ATM tunnels went down. Some of the tunnels between sauce.uio.no and somewhere at datanet.tele.fi are down. Route to goose.sms.fi (?) * mrouter.ietf33.nordu.net - stockholm.mbone.ebone.net - - directory.funet.fi This is strange, NORDUnet should copy with it. Could people at sauce.uio.no investigate if there is an ATM- problem at all? We are currently sending with PCM-encoded audio, and nv-video at 100 kbps. There are experimental video sent at 200-250 kbps with vic/jpeg, but that is restricted to the Nordic region so far. If people want to adjust thresholds according to the available bandwidth at other places, we could enlarge the region of higher broadcasts. -Christian Wettergren IETF Multicast Mission Control (IMMC :-)) From list-mgr@ISI.EDU Mon Jul 17 16:14:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 07:15:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 07:15:34 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 07:15:33 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Mon, 17 Jul 1995 07:15:25 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Jul 1995 15:15:02 +0100 To: Christian Wettergren Cc: mbone Subject: Re: IETF transmission... In-Reply-To: Your message of "Mon, 17 Jul 95 15:43:35 +0100." <199507171343.PAA28059@piraya.electrum.kth.se> Date: Mon, 17 Jul 95 15:14:59 +0100 Message-Id: <8954.805990499@cs.ucl.ac.uk> From: Jon Crowcroft >The IETF Multicast Production Team (tm :-)) wants to know how >people have received the IETF transmissions during the first >day. Loss percentage, what channels, how you would like to >ask questions etc. after the .no ATM link came back (around 2 today) we have been getting 0% loss for all the feeds from you and it is first rate... (we are getting some problems internal to the UK, and bad US feeds from the sura path, but thats not your problem:-) >We have so far receieved two problem reports; >1/ Bad reception at certain sites in the UK. > This may be due to ATM-tunnel transitions, this is being > investigated. > Brunel.ac.uk had the following path; > * mrouter.ietf33.nordu.net - stockholm.mbone.ebone.net > - broodjeham.surfnet.nl - noc.ulcc.ja.net - > - noc2.ulcc.ja.net - babbage.brunel.ac.uk ... i don't understand this feed - surely if we have a direct feed on the ATM to lea.cs.ucl.ac.uk, then the best way to get Brunel on would have been from UCL to ULCC anmd then on - not using the broojeham route which is mean to be 1 further than via UCL... > We should have good quality at least as far as to broodjeham. indeed... cheers jon From list-mgr@ISI.EDU Mon Jul 17 06:15:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 07:23:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 07:22:51 -0700 Received: from cml.apgea.army.mil ([131.92.10.7]) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 07:22:50 -0700 Date: Mon, 17 Jul 95 10:15:15 EDT From: "John M. Clemens" To: mbone Subject: interested... Message-Id: <9507171015.aa07447@c-mail.apgea.army.mil> i am interested in joining the MBONE, yet i'm not sure of any providers close to the Edgewood Research, developement, and Engineering Center in Edgewood, Maryland...i have an SGI Indigo2....is there a listing of providers and how to contact them for north-eastern maryland? John Clemens OR/SIM ERDEC From list-mgr@ISI.EDU Mon Jul 17 18:47:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 07:50:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 07:49:44 -0700 Received: from mons.uio.no by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 07:49:43 -0700 Received: from ulrik.uio.no by mons.uio.no with local-SMTP (PP) id <19414-0@mons.uio.no>; Mon, 17 Jul 1995 16:49:20 +0200 X-Mailer: exmh version 1.6 4/21/95 To: Christian Wettergren Cc: geir.pedersen@usit.uio.no, mbone@ietf33.nordu.net, mbone Subject: Re: IETF transmission... In-Reply-To: Your message of "Mon, 17 Jul 1995 15:43:35 MET DST." <199507171343.PAA28059@piraya.electrum.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jul 1995 16:47:52 +0200 From: Geir Pedersen Message-Id: <"mons.uio.n.433:17.06.95.14.49.36"@mons.uio.no> Christian, > 2/ Bad reception in Finland (goose.sms.fi) > We believe this is also due to that ATM tunnels went down. > Some of the tunnels between sauce.uio.no and somewhere > at datanet.tele.fi are down. The tunnel between Norway (sauce-atm.uio.no) and Finland is down: 129.240.202.42 -> 193.166.30.157 (?) [1/16/tunnel/down]. I am unable to get in contact with anyone at FUNET, but has emailed their contact person for the international MBONE over ATM work. > We are currently sending with PCM-encoded audio, and nv-video at You are sending PCM - not PCM2 on the second audio channel. > 100 kbps. There are experimental video sent at 200-250 kbps with > vic/jpeg, but that is restricted to the Nordic region so far. The situation for those listening in Finland may get better if the high bandwidth transmission is limited so that it does no reach them through their non-ATM connection onto the rest of MBONE. Geir. --- Geir Pedersen University of Oslo Center for Information Technology Services From list-mgr@ISI.EDU Mon Jul 17 19:10:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:15:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:10:52 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:10:50 -0700 Received: from localhost.electrum.kth.se (cwe@localhost.electrum.kth.se [127.0.0.1]) by piraya.electrum.kth.se (8.6.10/8.6.9) with SMTP id RAA29203; Mon, 17 Jul 1995 17:10:46 +0200 Message-Id: <199507171510.RAA29203@piraya.electrum.kth.se> To: Geir Pedersen Cc: mbone@ietf33.nordu.net, mbone Subject: Re: IETF transmission... In-Reply-To: Your message of Mon, 17 Jul 95 16:47:52 +0100. <"mons.uio.n.433:17.06.95.14.49.36"@mons.uio.no> Date: Mon, 17 Jul 95 17:10:45 +0200 From: Christian Wettergren | The tunnel between Norway (sauce-atm.uio.no) and Finland is down: | 129.240.202.42 -> 193.166.30.157 (?) [1/16/tunnel/down]. I am unable to get | in contact with anyone at FUNET, but has emailed their contact person for the | international MBONE over ATM work. Someone in Finland said that they didn't think that the ATM-link No-FI were meant to be used, I don't know the status. | > We are currently sending with PCM-encoded audio, and nv-video at | You are sending PCM - not PCM2 on the second audio channel. We thought that the audio would be more comprehensible in face of losses, if we used PCM. Opinions? | > 100 kbps. There are experimental video sent at 200-250 kbps with | > vic/jpeg, but that is restricted to the Nordic region so far. | | The situation for those listening in Finland may get better if the high | bandwidth transmission is limited so that it does no reach them through their | non-ATM connection onto the rest of MBONE. The problem is that ttl 33 suddenly reaches all of the Nordic region. If I could get some tunnel thresholds reconfigured, we could avoid this, and contain the high-bandwidth video better. I'd like to change the tunnels Stockholm.mbone.ebone.net -- directory.funet.fi Stockholm.mbone.ebone.net -- patella.uni-c.dk to a threshold of 40. -Christian From list-mgr@ISI.EDU Mon Jul 17 19:15:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:18:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:17:38 -0700 Received: from sunic.sunet.se by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:17:36 -0700 Received: from tuborg.pilsnet.sunet.se by sunic.sunet.se (8.6.8/2.03) id RAA24912; Mon, 17 Jul 1995 17:17:30 +0200 Received: from localhost.sunet.se by tuborg.pilsnet.sunet.se (8.6.10/6.0) id RAA04709; Mon, 17 Jul 1995 17:15:55 +0200 Message-Id: <199507171515.RAA04709@tuborg.pilsnet.sunet.se> To: cwe@it.kth.se Cc: geir.pedersen@usit.uio.no, mbone@ietf33.nordu.net, mbone Subject: Re: IETF transmission... From: Bjorn Carlsson In-Reply-To: Your message of "Mon, 17 Jul 95 17:10:45 +0200" References: <199507171510.RAA29203@piraya.electrum.kth.se> X-Mailer: Mew beta version 0.96 on Emacs 19.28.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 17 Jul 95 17:15:52 +0200 Sender: bc@sunet.se > I'd like to change the tunnels > > Stockholm.mbone.ebone.net -- directory.funet.fi > Stockholm.mbone.ebone.net -- patella.uni-c.dk > > to a threshold of 40. Ok, I'll fix that. Is there a break in the transmission anytime soon when I can do that? --BC From list-mgr@ISI.EDU Mon Jul 17 19:21:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:27:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:21:53 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:21:51 -0700 Received: from localhost.electrum.kth.se (cwe@localhost.electrum.kth.se [127.0.0.1]) by piraya.electrum.kth.se (8.6.10/8.6.9) with SMTP id RAA29501; Mon, 17 Jul 1995 17:21:46 +0200 Message-Id: <199507171521.RAA29501@piraya.electrum.kth.se> To: Bjorn Carlsson Cc: geir.pedersen@usit.uio.no, mbone@ietf33.nordu.net, mbone Subject: Re: IETF transmission... In-Reply-To: Your message of Mon, 17 Jul 95 17:15:52 +0100. <199507171515.RAA04709@tuborg.pilsnet.sunet.se> Date: Mon, 17 Jul 95 17:21:45 +0200 From: Christian Wettergren | > I'd like to change the tunnels | > | > Stockholm.mbone.ebone.net -- directory.funet.fi | > Stockholm.mbone.ebone.net -- patella.uni-c.dk | > | > to a threshold of 40. | | Ok, I'll fix that. Is there a break in the transmission anytime soon when I | can do that? About now. We'll start the retransmission in half an hour. -Christian From list-mgr@ISI.EDU Mon Jul 17 19:27:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:28:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:27:46 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:27:43 -0700 Received: from localhost.electrum.kth.se (cwe@localhost.electrum.kth.se [127.0.0.1]) by piraya.electrum.kth.se (8.6.10/8.6.9) with SMTP id RAA29612; Mon, 17 Jul 1995 17:27:41 +0200 Message-Id: <199507171527.RAA29612@piraya.electrum.kth.se> To: mbone, rem-conf@es.net Cc: bc@sunet.se, mbone@ietf33.nordu.net Subject: Retransmission of IETF sessions... In-Reply-To: Your message of Mon, 17 Jul 95 17:15:52 +0100. <199507171515.RAA04709@tuborg.pilsnet.sunet.se> Date: Mon, 17 Jul 95 17:27:40 +0200 From: Christian Wettergren Today's IETF sessions will be retransmitted at 16:00 UTC. We had some problems recording this, so unfortunately only the last sessions will be rebroadcast (HTML and POISED'95). We hope to do better tomorrow. /The Multicast Production Team From list-mgr@ISI.EDU Mon Jul 17 07:30:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:31:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:31:11 -0700 Received: from davinci.gmu.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 08:31:09 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id LAA19217; Mon, 17 Jul 1995 11:30:43 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199507171530.LAA19217@davinci.gmu.edu> Subject: Re: root@atma.noc.interop.net sending nv screendump to mbone To: van@ee.lbl.gov (Van Jacobson) Date: Mon, 17 Jul 1995 11:30:43 -0400 (EDT) Cc: mbone In-Reply-To: <199507171218.FAA22656@rx7.ee.lbl.gov> from "Van Jacobson" at Jul 17, 95 05:18:58 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2752 Since people mistakingly send out MBONE feeds that traverse the net on a continuing basis, wouldn't it make sense to come up with a method that would help alleviate the problem? In fact, with the MBONE topology growing everyday, it would make sense to build in mechanisms that would prevent, or at least reduce, the damage to sessions that new users (and some old veterans) inadvertently cause through mis-setting the TTL levels on their software. Something as simple as a little warning from the program SD that their TTL level will cross their threshold and be broadcast to a larger region or the world would help reduce the problem. In addition, sessions should allow restricting remote users from broadcasting. That would help with the problem of sending to sessions similar to NASA's shuttle, where no one except NASA should be transmitting anyway. Remember, that the problem here is not malicious intent to trash the MBONE, but new users who have not been educated to the effects of raising the TTL levels to high or the accidental mis-setting of the ttl level. I believe through education and warnings through software rather than a non-mandatory mailing list, the frequency of trashing the MBONE can be significantly reduced. > User root@atma.noc.interop.net (45.211.0.113) has been sending 128kb/s > of an nv screendump to the Shuttle Video session for the past 2 hours. > The MBone is completely saturated this week with the two IETF sessions > from Stockholm and the Shuttle flight so this video is causing > significant packet loss. Neither the DNS nor mail seem to be > configured for this machine so it doesn't seem possible to reach > this user. If someone is nearby, could you ask them to please stop > sending? Thanks. > > - Van Jacobson > > ps- As I've noted in the past, the human-factors engineering of nv > is very poor given the MBone's very limited bandwidth: Nv > doesn't respect the MBone ttl vs. bandwidth limits so novice > users very often exceed those limits while exploring the tool. > Nv also has a large "start sending" button that is easy to hit > accidentally and, because of its x11 screen grabber, it will > *always* send something when you hit "start sending". (Over > the past year, I have monitored an average of 50 users *per day* > sending nv screendumps to the MBone.) Sites might consider having > novice users use vic in "nv mode" rather than nv since the vic user > interface was designed to make these common, very antisocial, user > mistakes impossible. > -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Mon Jul 17 20:08:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 09:10:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 09:08:47 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 09:08:45 -0700 Received: from localhost.electrum.kth.se (cwe@localhost.electrum.kth.se [127.0.0.1]) by piraya.electrum.kth.se (8.6.10/8.6.9) with SMTP id SAA00212 for ; Mon, 17 Jul 1995 18:08:43 +0200 Message-Id: <199507171608.SAA00212@piraya.electrum.kth.se> To: mbone Subject: IETF mcast... Date: Mon, 17 Jul 95 18:08:42 +0200 From: Christian Wettergren Hi! I've seen several reports about bad video beyond uu.net in the States. Could someone investigate whether that is probable? I'm off for the Social Event now. :-) -Christian From list-mgr@ISI.EDU Mon Jul 17 02:07:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 09:08:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 09:07:47 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 09:07:47 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id JAA23046; Mon, 17 Jul 1995 09:07:44 -0700 Message-Id: <199507171607.JAA23046@rx7.ee.lbl.gov> To: Christian Wettergren Cc: mbone, mbone@ietf33.nordu.net Subject: Re: IETF transmission... In-Reply-To: Your message of Mon, 17 Jul 95 15:43:35 N. Date: Mon, 17 Jul 95 09:07:43 PDT From: Van Jacobson Christian, Audio & video for both channels came through perfectly here -- <1% loss on everything all day except for two short (<5 minute) periods when the loss rate got very high. It was particularly impressive because NASA's Shuttle feed & ARPA's replay of the PI meeting were running at the same time -- over 800kb/s arriving here from the MBone and less than 1% loss on all of it. I was a bit disappointed that the plan for scanning slides into wb didn't seem to work out though. - Van ps- But the replay just started & things seem to have gone to hell though -- I'm seeing 10-30% loss on both channels at the moment. From list-mgr@ISI.EDU Mon Jul 17 06:13:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 09:13:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 09:13:14 -0700 Received: from ecl.wustl.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 09:13:12 -0700 Received: by ecl.wustl.edu (5.x/ECL-A1.27) id AA05896; Mon, 17 Jul 1995 11:13:07 -0500 Date: Mon, 17 Jul 1995 11:13:07 -0500 From: sifu@ecl.wustl.edu (Ben Regen) Message-Id: <9507171613.AA05896@ecl.wustl.edu> To: mbone Subject: Problems compiling mrouted3.5 on Solaris 2.4 We are currently reading all the archived mailing-list mail, but I thought I would mail you guys in case there was a simple fix. When compiling mrouted3.5 on Solaris 2.4, we are having problems with undefined symbols. With kern.c, the problems are with MRT_INIT, MRT_DONE, MRT_ADD_VIF, MRT_DEL_VIF, MRT_ADD_MFC, MRT_DEL_MFC, and MRT_VERSION. With igmp.c, the problems are with IGMP_HOST_NEW_MEMBERSHIP_REPORT, IGMP_HOST_LEAVE_MESSAGE, IGMP_PIM, IGMP_MTRACE, and IGMP_MTRACE_RESP. Any ideas what header files I might be missing? Thanks in advance-- Ben Regen sifu@ecl.wustl.edu From list-mgr@ISI.EDU Mon Jul 17 17:16:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 09:20:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 09:19:56 -0700 Received: from v6.ph.gla.ac.uk ([194.36.1.70]) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 09:18:30 -0700 Received: from v2.ph.gla.ac.uk by v2.ph.gla.ac.uk with SMTP; Mon, 17 Jul 1995 17:16:45 GMT Date: Mon, 17 Jul 1995 17:16:35 +0000 From: "Alan J. Flavell" Reply-To: A.Flavell@physics.gla.ac.uk To: mbone Subject: nv configuration, was Re: root@atma.noc.interop.net Message-Id: Organization: Glasgow University Particle Physics Group Phone: +44 141 330 5454 - fax 334 9029 Organization: sorely needed Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ---------- Forwarded message ---------- On Mon, 17 Jul 1995, Michael Benson wrote: > Something as simple as a little warning from the program SD that > their TTL level will cross their threshold and be broadcast to a larger > region or the world would help reduce the problem. In addition, sessions > should allow restricting remote users from broadcasting. That would help > with the problem of sending to sessions similar to NASA's shuttle, where > no one except NASA should be transmitting anyway. Well, the mistake happened here once. Fortunately not too much harm was done, but in response I edited our sd startup TCL so that it started nv in receive-only mode. That way, a startup from standard sd cannot result in accidentally start transmitting video (no temptingly large button to click on, either by misunderstanding or by accident). I suggest that sd should be distributed in that form. For comparison, recent versions of wb start up in receive-only mode, I think. Now, wb can be switched into write mode by a simple button press, whereas if nv is started rcv-only it stays rcv-only. But, given nv the way it is, I suggest this as a compromise in sd. A simple note to explain how to start it up when transmission is desired would be all that's needed, but at least the default setting would be the safe one. An alternative that was suggested to me (by I forget who, sorry) was to have sd start nv with a low TTL, regardless of the TTL advertised by the conference being joined, unless the user took some deliberate action to make it otherwise. Again I think this could be considered for building into the standard sd script as distributed, no? I'm not in any way arguing against Van's proposal to not use nv at all: I just wander in and out of Mbone and am in no position to do other than make the odd suggestion, for consideration by the regulars. hope that helps. > Remember, that the problem here is not malicious intent to trash the > MBONE, but new users who have not been educated to the effects of Yes, I think that's generally accepted as the explanation. In my case it was a blunder by a visitor trying to bring a different window to the front by clicking on it - and somehow landing on the "Start transmit" button ;-} From list-mgr@ISI.EDU Tue Jul 18 11:42:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 10:40:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 10:37:03 -0700 Received: from tulip.kaist.ac.kr by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 10:36:49 -0700 Received: (from kybae@localhost) by tulip.kaist.ac.kr (8.6.9H1/8.6.9) id CAA08660 for mbone@isi.edu; Tue, 18 Jul 1995 02:43:00 +0900 From: Kwangyeon Bae Message-Id: <199507171743.CAA08660@tulip.kaist.ac.kr> Subject: Problems getting vat source To: mbone Date: Tue, 18 Jul 1995 02:42:58 +0900 (KST) X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 351 Hi! I have two questions. 1.Does anyone port vat into windows 3.1 version ? 2.If none, how can I get vat source code easy ? I had sent mails for authors(van@ee.lbl.gov and mccane@ee.lbl.gov). But I can't get any response. Please let me know contact method with authors or source code location. - Kwang-yeon Bae(kybae@cosmos.kaist.ac.kr) From list-mgr@ISI.EDU Mon Jul 17 13:03:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 14:03:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 14:03:36 -0700 Received: from gamera.rs.itd.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 17 Jul 1995 14:03:36 -0700 Received: from acid by gamera.rs.itd.umich.edu (8.6.12/2.2) id RAA13054; Mon, 17 Jul 1995 17:03:26 -0400 Message-Id: <199507172103.RAA13054@gamera.rs.itd.umich.edu> Date: Mon, 17 Jul 1995 17:03:26 -0400 X-Sender: johnlaue@141.211.83.24 X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Kwangyeon Bae , mbone From: johnlaue@umich.edu (John D. Lauer) Subject: Re: Problems getting vat source Here, here! I can't find VAT for Windows, 95, or NT anywhere. I've read some emails where it seems people are using this. But I have searched long and far to no avail. I too am interested in compiling for NT if the source code is available for VAT or NV. At 02:42 AM 7/18/95 +0900, Kwangyeon Bae wrote: >Hi! > >I have two questions. > >1.Does anyone port vat into windows 3.1 version ? > >2.If none, how can I get vat source code easy ? > > I had sent mails for authors(van@ee.lbl.gov and mccane@ee.lbl.gov). > > But I can't get any response. > > Please let me know contact method with authors or source code location. > >- Kwang-yeon Bae(kybae@cosmos.kaist.ac.kr) > From list-mgr@ISI.EDU Wed Jul 19 00:05:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 01:07:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 01:07:11 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 01:07:10 -0700 Received: from pluto (pluto.cc.nus.sg) by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 18 Jul 1995 01:06:37 -0700 Received: (kokyong@localhost) by pluto (8.6.11/8.6.4) id QAA01943; Tue, 18 Jul 1995 16:05:09 +0800 Date: Tue, 18 Jul 1995 16:05:08 +0800 (WST) From: Leong Kok Yong Subject: Singapore National Day Parade 95 Internet Broadcast To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII MBONE Announcement Singapore 30th National Day Parade Live and delayed Audio/Video MBONE Internet broadcast jointly organized by National University of Singapore Computer Centre Technet, IRDU and TCS August 9 1995 ------------- 0900 - 1000 GMT (test transmission) 1100 - 1300 GMT (live) 1700 - 1900 GMT (rebroadcast) August 10 1995 -------------- 0000 - 0200 GMT (rebroadcast) 0500 - 0700 GMT (rebroadcast) We are planning an MBONE broadcast of our National Day Parade (NDP) 95 on the Internet bringing to you the wonderful sights and sounds of our celelebration on the above date and time. The above schedule may be subjected to change. Also any conflicts in time/date with any other ongoing broadcast on the same day/time can be resolved by contacting with the undersigned. We will be broadcasting over Technet 512kbps leased line to JvNC and making use of the CUSeeMe technolgy. Invitation wll be sent out to overseas sites like the US, UK, Australia and Canada to particapte as a reflector site. Anyone who wish to join in can contact the undersigned. Meanwhile, you can start looking out for further updates or information on our NDP Web Page specially setup for this occasion. You can find it at http://www.nus.sg/NDP30.html. Comments and questions are welcomed. Anybody is welcomed to include this URL in their WEB server home page. Feedbacks on this annoucement can be directed to ndp95@pluto.cc.nus.sg or entered at our web page. From list-mgr@ISI.EDU Tue Jul 18 13:31:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 02:31:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 02:31:26 -0700 Received: from sics.se by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 02:31:24 -0700 Received: from hans.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA26850; Tue, 18 Jul 95 11:31:21 +0200 X-Sender: hans@sics.se Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jul 1995 11:31:24 +0200 To: mbone From: "Amr A. Awadallah" (by way of hans@sics.se (Hans Eriksson)) Subject: How could I hook in to an mbone tunnel ? This is Amr A. Awadallah, Comp Eng Dept , Fac of Eng, Cairo University, EGYPT. Our university has a connection of 64Kbit/s to Paris-EBS2.Ebone.net (192.121.156.74) in France. I have a DEC 3000 AlphaAXP/OSF1V2 machine will all necessary MBONE software. The problem is that I don't know the correct address to write in the /etc/mrouted.conf file. So could somebody help me with that. Which is the nearest MBONE site that I should tunel through ? What is the correct values for metric and threshold ? Should I use [srcrt] or not ? Thanks for your co-operation. Amr A. Awadallah From list-mgr@ISI.EDU Tue Jul 18 13:17:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 03:17:40 -0700 Received: from FRCU.EUN.EG by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 03:16:16 -0700 Received: from FRCU.EUN.EG by FRCU.EUN.EG (PMDF V4.2-11 #3805) id <01HT0MAXWCE8000RNZ@FRCU.EUN.EG>; Tue, 18 Jul 1995 13:17:44 O Date: Tue, 18 Jul 1995 13:17:44 +0000 (O) From: "Amr A. Awadallah" Subject: How could I hook in to an mbone tunnel ? To: mbone-fr@inria.fr Cc: mbone-na, mbone-uk@cs.ucl.ac.uk Message-Id: <01HT0MAXXOMA000RNZ@FRCU.EUN.EG> X-Vms-To: IN%"mbone-fr@inria.fr" X-Vms-Cc: IN%"mbone-na@isi.edu", IN%"mbone-uk@cs.ucl.ac.uk" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT From: FRCU::AMR "Amr A. Awadallah" 18-JUL-1995 12:18:50.70 To: IN%"mbone-request@isi.edu" CC: IN%"mbone-eu-request@sics.se",AMR Subj: How could I hook in to an mbone tunnel ? This is Amr A. Awadallah, Comp Eng Dept , Fac of Eng, Cairo University, EGYPT. Our university has a connection of 64Kbit/s to Paris-EBS2.Ebone.net (192.121.156.74) in France. I have a DEC 3000 AlphaAXP/OSF1V2 machine will all necessary MBONE software. The problem is that I don't know the correct address to write in the /etc/mrouted.conf file. So could somebody help me with that. Which is the nearest MBONE site that I should tunel through ? What is the correct values for metric and threshold ? Should I use [srcrt] or not ? Thanks for your co-operation. Amr A. Awadallah From list-mgr@ISI.EDU Tue Jul 18 04:21:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 04:22:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 04:21:49 -0700 Received: from nosc.ja.net (ns0.ja.net) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 04:21:46 -0700 Received: from nosc.ja.net by nosc.ja.net with Internet SMTP id ; Tue, 18 Jul 1995 12:21:44 +0100 Received: by m5.ja.net (4.1/SMI-4.1) id AA12518; Tue, 18 Jul 95 12:21:43 BST Date: Tue, 18 Jul 95 12:21:43 BST From: robert@nosc.ja.net (Robert Stone) Message-Id: <9507181121.AA12518@m5.ja.net> To: mbone Subject: problems with using IP multicast v3.5 Hi, For a while now we have been using IP multicast v3.3 software on a SPARC Classic with a second LANCE ethernet card running SunOS 4.1.3_U1B without any problems. On upgrading the machine to version 3.5 of the multicast software, with rsvp support and including the set of patches released in June, we get a constant stream of the following messages in the syslog logfile: vmunix: le1: TINT but buffer owned by LANCE vmunix: le1: RINT but buffer owned by LANCE Has anybody encountered this problem and if so is there a solution ?. Regards, Robert Stone JANET Network Operations From list-mgr@ISI.EDU Tue Jul 18 18:24:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 07:28:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 07:28:20 -0700 Received: from dec.sns-felb.debis.de by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 07:28:14 -0700 Received: by dec.sns-felb.debis.de (5.65/DEC-Ultrix/4.3) id AA02905; Tue, 18 Jul 1995 16:24:58 +0200 Date: Tue, 18 Jul 1995 16:24:57 +0200 (MET DST) From: Torsten Kleber X-Sender: kleber@dec To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe kleber@sns-felb.debis.de From list-mgr@ISI.EDU Tue Jul 18 01:53:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 08:59:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 08:53:52 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 08:53:51 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id IAA24350; Tue, 18 Jul 1995 08:53:24 -0700 Message-Id: <199507181553.IAA24350@rx7.ee.lbl.gov> To: jank@suncms9.cern.ch, spkr4@fnvdeo.fnal.gov Cc: mbone Subject: jank@suncms9.cern.ch sending 400kb/s nv video to world Date: Tue, 18 Jul 95 08:53:23 PDT From: Van Jacobson jank@suncms9.cern.ch & spkr4@fnvdeo.fnal.gov are sending two streams of nv video, one from 131.225.40.17 & one from 128.141.237.201, totaling 400kb/s out to the world. The total bandwidth available on the MBone is only 500kb/s and that has to be shared among all its users. This is apparently a private conversation & you are using almost all the world's bandwidth. This week the mbone is very busy with an IETF meeting in Stockholm and a NASA Shuttle flight. These broadcasts have already reserved the bandwidth and you are taking it away from them and causing routing & congestion problems all over the world. Please stop. Thank you. - Van Jacobson From list-mgr@ISI.EDU Tue Jul 18 20:40:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 09:40:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 09:40:31 -0700 Received: from insanus.matematik.su.se by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 09:40:28 -0700 Received: from localhost (wizkids.matematik.su.se [130.237.198.20]) by insanus.matematik.su.se (8.6.10/8.6.9) with ESMTP id QAA09330 for ; Tue, 18 Jul 1995 16:40:27 GMT Message-Id: <199507181640.QAA09330@insanus.matematik.su.se> X-Address: Department of Mathematics, Stockholm University S-106 91 Stockholm SWEDEN X-Phone: int+8162000 X-Fax: int+86126717 X-Url: http://www.matematik.su.se To: mbone Subject: IETF MBONE chat wb started. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <19750.806085621.1@wizkids.matematik.su.se> Date: Tue, 18 Jul 1995 18:40:22 +0200 From: Leif Johansson Hi Y'all This is just to inform you that we started a wb for technical chats and problem reports during the 33rd IETF in Stockholm. Find it in sd. MVH leifj - IETF Multicast Crew From list-mgr@ISI.EDU Tue Jul 18 22:49:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 11:54:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 11:49:38 -0700 Received: from concorde.inria.fr by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 11:49:34 -0700 Received: from magoo.inria.fr (magoo.inria.fr [128.93.17.3]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id UAA24892 for ; Tue, 18 Jul 1995 20:49:27 +0200 Received: from localhost.inria.fr (localhost.inria.fr [127.0.0.1]) by magoo.inria.fr (8.6.8/8.6.6) with SMTP id UAA15276 for mbone@ISI.EDU; Tue, 18 Jul 1995 20:49:26 +0200 From: Pierre Leonard Message-Id: <199507181849.UAA15276@magoo.inria.fr> X-Authentication-Warning: magoo.inria.fr: Host localhost.inria.fr didn't use HELO protocol To: mbone Subject: Quality and Usage enhancement in TILISIA. Date: Tue, 18 Jul 95 20:49:25 +0200 X-Mts: smtp The full paper annonced 4 weeks ago, concerning the work of TILISIA team at INRIA on the videoconferencing system TILISIA is now available at the following URL : http://magoo.inria.fr/pl/telesia-pap2.html We are waiting for your comments and suggestions. Authors: Pierre Lionard, Alain Caristan, Pierre De La Motte, Andrzej Wozniak INRIA Institut National de Recherche en Informatique et Automatique Domaine de Voluceau Rocquencourt BP 105 78153 Le Chesnay Cedex Abstract During the last years, the TELESIA application, remote-seminar / remote-meeting, was the base of a large number of experimentations. These experimentations, in France and over the world, was the field tests for advanced multimedia services and evaluation and technologies research and developments. The usages are rather different due to the user's needs for a remote-seminar or a remote-meeting. Know-how, expertise exchange is enrich with the telepresence of the speaker: the listeners are free from the information decoding. The technology is crucial for the telepresence, which is the main principle of the teleseminars. Therefore, the audio and the video processing and networking needs to prevent the weakness of the low quality networks: off sequence packets, lost packets, variable transit delays. This report presents the analysis of the major defects encountered during the experiments, the solutions designed and realized, to embrace the objective and subjective quality of audio and video processing. Finally we present the analyze of the results trough "in-the-field tests" and campaigns of measures done during December 1994 and May 1995. Pierre Lionard INRIA Rocquencourt Tel : +33 (1) 39 63 50 46 B.P. 105 Fax : +33 (1) 39 63 51 14 78153 Le Chesnay Email: Pierre.Leonard@inria.fr France From list-mgr@ISI.EDU Tue Jul 18 06:30:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 13:32:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 13:32:02 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 13:32:00 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15014(6)>; Tue, 18 Jul 1995 13:30:58 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49860>; Tue, 18 Jul 1995 13:30:53 -0700 To: sifu@ecl.wustl.edu (Ben Regen) Cc: mbone Subject: Re: Problems compiling mrouted3.5 on Solaris 2.4 In-Reply-To: Your message of "Mon, 17 Jul 95 09:13:07 PDT." <9507171613.AA05896@ecl.wustl.edu> Date: Tue, 18 Jul 1995 13:30:49 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jul18.133053pdt.49860@crevenia.parc.xerox.com> In message <9507171613.AA05896@ecl.wustl.edu> you write: >When compiling mrouted3.5 on Solaris 2.4, we are having problems with >undefined symbols. mrouted 2.2 is the latest you can run on "stock" Solaris 2.4 . You can get mrouted 3.4 for Solaris from playground.sun.com in /pub/multicast/Solaris_mc33.2.4.tar.Z ; this includes kernel patches and mrouted. You may or may not also need /pub/multicast/patches/101969-06.tar; I don't know if that patch is included in the other tar file. Just to be safe, add the patch first, and then install Solaris_mc33.2.4.tar . Bill From bart@spirited.primeoption.com Tue Jul 18 11:15:04 1995 Received: from spirited.primeoption.com by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 18:15:10 -0700 Received: (from bart@localhost) by spirited.primeoption.com (8.6.12/8.6.12) id SAA01905 for mbone-na-list@isi.edu; Tue, 18 Jul 1995 18:15:04 -0700 Date: Tue, 18 Jul 1995 18:15:04 -0700 From: Barton Kirk Baenisch Message-Id: <199507190115.SAA01905@spirited.primeoption.com> To: mbone-na-list Subject: subscribe mbone To Whom it May Concern- *PLEASE* subscribe mbone I will be implementing an internal Video Conferencing capability for the company I work for and I will need as much help as I can get. PLEASE include me in the mailing list. Thank you very much, Bart Baenisch Bart Baenisch, OEM Product Manager, System Administration Manager, Release Manager bbaenisch@primeoption.com PRIME|option, Inc. 2236 Rutherford Street Suite 105 Carlsbad CA 92008-8836 (619) 438-0335 voice (619) 438 0343 FAX (619) 944-7867 home office From list-mgr@ISI.EDU Wed Jul 19 20:37:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 21:42:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 21:37:28 -0700 Received: from pluto (pluto.cc.nus.sg) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 18 Jul 1995 21:37:21 -0700 Received: (kokyong@localhost) by pluto (8.6.11/8.6.4) id MAA05484; Wed, 19 Jul 1995 12:37:14 +0800 Date: Wed, 19 Jul 1995 12:37:14 +0800 (WST) From: Leong Kok Yong Subject: Annoucing Singapore National Day Parade '95 Internet Broadcast To: mbone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We are preparing to broadcast the 30th Singapore National Day Parade ceremony, which will be held on August 9 1995. The combined project team comprising National University of Singapore Computer Centre, Technet unit, Internet Research & Development Unit (IRDU) and Television Corporation of Singapore (TCS) will be proudly presenting to you the audio & visual images on the Internet using World Wide Web, MBONE and the CU-SEEME desktop videoconferencing software. Time-Table ---------- Our live (and delayed) broadcasting plan is as follows: Testrun - test transmission, early news, preview, etc. from Aug 9 09:00 - 10:00 GMT Live - Singapore National Day Parade ceremony (approx. 2 hrs.) from Aug 9 11:00 GMT (Aug 9 17:00 Singapore time) Rebroadcast from Aug 9 17:00 - 19:00 GMT (Aug 10 01:00 - 03:00 ST) from Aug 10 00:00 - 02:00 GMT (Aug 10 08:00 - 10:00 ST) from Aug 10 05:00 - 07:00 GMT (Aug 10 13:00 - 15:00 ST) We welcome overseas site to participate as a reflector site on the days of transmission. See the web page http://www.nus.sg/NDP30.html for further information and watch this page for the most recent updates. Any queries and comments can go to "ndp95@irdu.nus.sg". You can also send your greetings to us at the above URL. Singapore 30th National Day Parade Internet Broadcast Project cceravi@nus.sg kokyong@irdu.nus.sg From list-mgr@ISI.EDU Wed Jul 19 13:28:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 19 Jul 1995 02:33:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 19 Jul 1995 02:31:03 -0700 Received: from chx400.switch.ch by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 19 Jul 1995 02:31:00 -0700 X400-Received: by mta chx400.switch.ch in /PRMD=Switch/ADMD=Arcom/C=Ch/; Relayed; Wed, 19 Jul 1995 11:29:02 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Wed, 19 Jul 1995 11:28:54 +0200 X400-Received: by /PRMD=switch/ADMD=arcom/C=ch/; Relayed; Wed, 19 Jul 1995 11:28:46 +0200 Date: Wed, 19 Jul 1995 11:28:46 +0200 X400-Originator: villazon@cui.unige.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arcom/C=ch/;950719112846] X400-Content-Type: P2-1984 (2) Content-Identifier: 263 Alternate-Recipient: Allowed From: VILLAZON Alex Message-Id: <263*/S=villazon/OU=cui/O=unige/PRMD=switch/ADMD=arcom/C=ch/@MHS> To: mbone Subject: Unsuscribe. Please unsuscribe me from the mbone list. Alex villazon@cui.unige.ch From list-mgr@ISI.EDU Wed Jul 19 13:40:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 19 Jul 1995 02:42:49 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 19 Jul 1995 02:42:15 -0700 Received: from chx400.switch.ch by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 19 Jul 1995 02:41:51 -0700 X400-Received: by mta chx400.switch.ch in /PRMD=Switch/ADMD=Arcom/C=Ch/; Relayed; Wed, 19 Jul 1995 11:40:45 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Wed, 19 Jul 1995 11:40:38 +0200 X400-Received: by /PRMD=switch/ADMD=arcom/C=ch/; Relayed; Wed, 19 Jul 1995 11:40:33 +0200 Date: Wed, 19 Jul 1995 11:40:33 +0200 X400-Originator: barrero@cui.unige.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arcom/C=ch/;950719114033] X400-Content-Type: P2-1984 (2) Content-Identifier: 770 Alternate-Recipient: Allowed From: BARRERO MENDIZABAL Luis Marcel Message-Id: <770*/S=barrero/OU=cui/O=unige/PRMD=switch/ADMD=arcom/C=ch/@MHS> To: Mbone list Subject: Unsuscribe Please unsuscribe me from the mbone list. Chaito! Marcel. barrero@cui.unige.ch LA UNION HACE LA FUERZA. --- lmbm --- From list-mgr@ISI.EDU Wed Jul 19 16:20:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 19 Jul 1995 07:39:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 19 Jul 1995 07:38:53 -0700 Received: from sicmail.epfl.ch by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 19 Jul 1995 07:38:51 -0700 Received: from stisun9.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <20201-0@sicmail.epfl.ch>; Wed, 19 Jul 1995 14:20:10 +0200 Received: from localhost by stisun9 (5.x/Epfl-3.1/MX) id AA21392; Wed, 19 Jul 1995 14:20:09 +0200 From: timsit@stisun9.epfl.ch (Richard Timsit) Message-Id: <9507191220.AA21392@stisun9.epfl.ch> X-Mailer: exmh version 1.5.3 12/28/94 To: mbone Subject: Mrouted 3.6, SunOS4.1.3_U1 and BF In-Reply-To: Your message of "Mon, 17 Jul 1995 17:16:35 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jul 1995 14:20:09 +0200 Is Mrouted 3.6 running on SunOS4.1.3_U1 with a FDDI Sun SBus card BF in any place ? +-----------------------------------------------+ | ??? | | {O-O} Richard Timsit | | _^_ SIC STI | | / T \_ EPFL Lausanne | | '` I " 1015 Ecublens,SUISSE | | M (021) 693 22 35 | | | | timsit@sic.epfl.ch | | I I | +-----------------------------------------------+ From bart@spirited.primeoption.com Wed Jul 19 00:16:45 1995 Received: from spirited.primeoption.com by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 19 Jul 1995 18:18:43 -0700 Received: (from bart@localhost) by spirited.primeoption.com (8.6.12/8.6.12) id HAA02360 for mbone-na-list@isi.edu; Wed, 19 Jul 1995 07:16:45 -0700 Date: Wed, 19 Jul 1995 07:16:45 -0700 From: Barton Kirk Baenisch Message-Id: <199507191416.HAA02360@spirited.primeoption.com> To: mbone-na-list Subject: Thanks Thanks to all who pointed out 'mbone-na-request' vs. 'mbone-na-list' Bart Baenisch, OEM Product Manager, System Administration Manager, Release Manager bbaenisch@primeoption.com PRIME|option, Inc. 2236 Rutherford Street Suite 105 Carlsbad CA 92008-8836 (619) 438-0335 voice (619) 438 0343 FAX (619) 944-7867 home office From list-mgr@ISI.EDU Thu Jul 20 19:11:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 19 Jul 1995 18:18:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 19 Jul 1995 18:17:30 -0700 Received: from eekaist.kaist.ac.kr by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 19 Jul 1995 18:11:30 -0700 Received: by eekaist.kaist.ac.kr (8.6.9H1/8.6.4) id KAA28532 From: Byung-Cheol Shin Message-Id: <199507200011.KAA28532@eekaist.kaist.ac.kr> Subject: ITU's opinion on RTP To: mbone Date: Thu, 20 Jul 1995 10:11:45 +0900 (GMT+9:00) Cc: bcshin@eekaist.kaist.ac.kr (Byung-Cheol Shin ) X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 803 Dear Sir: A few weeks ago, I read an e.mail representing the private opinion of ITU-T in that they may NOT use RTP protocol. Regretfully I forget the mail. If you have it, would you please send me or tell me how I can reach it. I would like to know the reason why they hesitate in using RTP protocol. Regards. Shin. ------------------------------------------------------------------------------- Shin, Byung-Cheol, Ph.D. | T:+82-42-869-3426(Research OFFice) Dept. of Elec. Eng. | T:+82-42-869-3402~4(Dept. Office) KAIST | T:+82-42-869-5426, 8026(Student Office) 373-1 Kusong-dong Yusong-gu | T:+82-42-861-0239(residence) Taejon, 305-701 Korea | F:+82-42-869-3410 | e.mail: bcshin@ee.kaist.ac.kr ------------------------------------------------------------------------------ From list-mgr@ISI.EDU Thu Jul 20 10:34:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 01:45:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 01:39:52 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 01:39:50 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 20 Jul 1995 01:37:41 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Jul 1995 09:35:00 +0100 To: Geir Pedersen Cc: mbone@ietf33.nordu.net, mbone Subject: Re: IETF transmission... In-Reply-To: Your message of "Mon, 17 Jul 95 16:47:52 +0100." <"mons.uio.n.433:17.06.95.14.49.36"@mons.uio.no> Date: Thu, 20 Jul 95 09:34:57 +0100 Message-Id: <589.806229297@cs.ucl.ac.uk> From: Jon Crowcroft we've lost the ATM tunnels again from the UK this morning does anyone know if other euro-pno VCs are up ok or if its just a UK end thing? (Oh for ATM level traceroute!!!) jon From list-mgr@ISI.EDU Fri Jul 21 05:45:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 06:52:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 06:47:46 -0700 Received: from v9000.ntu.ac.sg by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 06:46:59 -0700 Received: from ntuvax.ntu.ac.sg by ntuvax.ntu.ac.sg (PMDF V4.3-7 #7636) id <01HT3WKIMUTSC2K903@ntuvax.ntu.ac.sg>; Thu, 20 Jul 1995 21:45:47 +0800 Date: Thu, 20 Jul 1995 21:45:47 +0800 From: SG7130125@ntuvax.ntu.ac.sg Subject: information needed for MBone linkage To: mbone Message-Id: <01HT3WKJ5CCIC2K903@ntuvax.ntu.ac.sg> X-Vms-To: IN%"mbone@isi.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT hi, i am trying to connect my lab with a number of Sun Sparcstation 5 to the MBone. Currently the Stations are running Solaris 2.4. Do i need to have IP multicast software? Do I also need to have mrouted program? by the way what's the difference between ip multicast software and mrouted program? thanks in advance.... kian vine From list-mgr@ISI.EDU Thu Jul 20 21:15:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 10:17:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 10:15:55 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 10:15:54 -0700 Received: from localhost.electrum.kth.se (cwe@localhost.electrum.kth.se [127.0.0.1]) by piraya.electrum.kth.se (8.6.10/8.6.9) with SMTP id TAA06617; Thu, 20 Jul 1995 19:15:44 +0200 Message-Id: <199507201715.TAA06617@piraya.electrum.kth.se> To: mbone Cc: rem-conf@es.net Subject: IETF transmission quality... Date: Thu, 20 Jul 95 19:15:43 +0200 From: Christian Wettergren Hi! The Multicast Production Team at the 33rd IETF would like to get reports on perceived quality in different corners of the world. All comments and suggestions on improvements etc are most welcome. We wish to thank you all and we hope that you enjoyed the transmissions. Christian Wettergren (and the rest of the MBone crew) cwe@it.kth.se KTH/Teleinformatics Stockholm, Sweden From list-mgr@ISI.EDU Thu Jul 20 13:05:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 14:13:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 14:13:03 -0700 Received: from portal.netedge.com by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 14:12:15 -0700 Received: from NetEdge.COM by portal.netedge.com id AA01218; Thu, 20 Jul 95 17:09:50 EDT Received: from suicidesix.NetEdge.COM by NetEdge.COM id AA23333; Thu, 20 Jul 95 17:08:27 EDT Return-Path: Received: from localhost by suicidesix.NetEdge.COM (4.1/NECL-6.14) id AA05572; Thu, 20 Jul 95 17:05:17 EDT Message-Id: <9507202105.AA05572@NetEdge.COM> To: Christian Wettergren Cc: mbone, rem-conf@es.net Subject: Re: IETF transmission quality... In-Reply-To: Your message of "Thu, 20 Jul 1995 19:15:43 +0200." <199507201715.TAA06617@piraya.electrum.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <5569.806274315.1@suicidesix.netedge.com> Date: Thu, 20 Jul 1995 17:05:16 -0400 From: Thomas Pusateri In message <199507201715.TAA06617@piraya.electrum.kth.se> you write: > >Hi! > >The Multicast Production Team at the 33rd IETF would like >to get reports on perceived quality in different corners >of the world. I listened in from chron.jcmax.com connected to a tunnel at interpath.net which connects to MAE EAST and gets its MBONE service from sprintlink. It is T1 speeds to MAE EAST. I almost constantly saw losses of 10% which made the audio useless. There was too much breaking up to understand the speech. Is it possible to use an audio coding format that is less susceptable to packet loss? Thanks for the effort though, Tom From list-mgr@ISI.EDU Thu Jul 20 13:11:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 14:17:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 14:11:51 -0700 Received: from tridis.ist.ucf.edu (Mach-1.tridis.ist.ucf.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 14:11:50 -0700 Received: by tridis.ist.ucf.edu (5.x/SMI-SVR4) id AA02079; Thu, 20 Jul 1995 17:11:49 -0400 Date: Thu, 20 Jul 1995 17:11:49 -0400 From: myjak@tridis.ist.ucf.edu (Michael Myjak) Message-Id: <9507202111.AA02079@tridis.ist.ucf.edu> To: mbone Subject: problem... Hello folks, I wouldn't be sending this if the automated system didn't apprear to be on the blink. I used to be a member of this group several years ago, and then relocated. Now when I attempt to reconnect, I get an automated message that says that I need to contact some mbone-na-request@isi.edu list, and thats what I did. But I get the same response there as well. So, my question is this: is the identity of my previous email address preventing me from attaching to the appropriate list server? And if not, then what is the appropriate server to connect to in order to join this list? again, sorry for the out-of-band request... -- Net@You.Soon, - Michael D. Myjak Senior Research Scientist; DIS Team member; Eagle-SAR P.I. Virtual Reality Research Team Leader (TOY SCOUTS) The Institute for Simulation and Training The University of Central Florida email: voice: 407.658.5043 FAX: 407.658.5059 "I do not think that this 'transistor' will ever be worth the immense development cost that has gone into it. It cannot be mass produced and will never be able to handle more than very small signal levels." -- Dr. Thomas James, 1949 From list-mgr@ISI.EDU Thu Jul 20 08:30:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 15:31:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 15:31:17 -0700 Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 15:31:17 -0700 Received: by precept.com (5.x/SMI-4.1) id AA13637; Thu, 20 Jul 1995 15:30:36 -0700 Date: Thu, 20 Jul 1995 15:30:36 -0700 (PDT) From: Stephen Casner To: Christian Wettergren Cc: mbone, rem-conf@es.net Subject: Re: IETF transmission quality... In-Reply-To: <199507201715.TAA06617@piraya.electrum.kth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 20 Jul 1995, Christian Wettergren wrote: > The Multicast Production Team at the 33rd IETF would like > to get reports on perceived quality in different corners > of the world. I was attending on-site, so I don't know what the remote reception was like. However, I was very impressed by the sophistication of the video production setup and the extra effort you folks put in to make available wb displays and graphics tablets for input. You've raised the standards for IETF Multicasts another notch or several. Bravo! -- Steve From list-mgr@ISI.EDU Thu Jul 20 08:25:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 15:25:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 15:25:25 -0700 Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 15:25:23 -0700 Received: by precept.com (5.x/SMI-4.1) id AA13621; Thu, 20 Jul 1995 15:25:12 -0700 Date: Thu, 20 Jul 1995 15:25:12 -0700 (PDT) From: Stephen Casner To: Michael Myjak Cc: mbone Subject: Re: problem... In-Reply-To: <9507202111.AA02079@tridis.ist.ucf.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 20 Jul 1995, Michael Myjak wrote: > Hello folks, I wouldn't be sending this if the automated system didn't > apprear to be on the blink. I used to be a member of this group > several years ago, and then relocated. Now when I attempt to > reconnect, I get an automated message that says that I need to contact > some mbone-na-request@isi.edu list, and thats what I did. But I get > the same response there as well. Here's what is supposed to happen: - Messages to mbone-request@isi.edu receive only a canned response providing the list of -request addresses for the regional sublists of the main mbone list. This message tells you that you must send another message to the appropriate -request address. - Messages to mbone-na-request@isi.edu (for the North American sublist) also get a canned reply, but this is a different one that tells you a human list manager will be processing your request. So, did you really get the same message both times? If so, then something is wrong. I have one possible explanation that is a bug I discovered only a couple of days ago and for which I have not yet figured out a fix. That bug is that if you send a request to both mbone-request and mbone-na-request, it will be processed as if only mbone-request was given. If that was the problem, try again with only mbone-na-request@isi.edu as the address. -- Steve From list-mgr@ISI.EDU Fri Jul 21 03:09:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 16:22:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 16:21:27 -0700 Received: from noc.BelWue.DE by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 16:21:21 -0700 X400-Received: by mta pp-belwue in /PRMD=BelWue/ADMD=d400/C=DE/; Relayed; Fri, 21 Jul 1995 01:09:45 +0200 X400-Received: by mta kssun-mta in /PRMD=BelWue/ADMD=d400/C=DE/; Relayed; Fri, 21 Jul 1995 01:09:19 +0200 X400-Received: by /PRMD=uni-stuttgart/ADMD=d400/C=de/; Relayed; Fri, 21 Jul 1995 01:09:19 +0200 Date: Fri, 21 Jul 1995 01:09:19 +0200 X400-Originator: feil@rus.uni-stuttgart.d400.de X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=uni-stuttgart/ADMD=d400/C=de/;950721010919] X400-Content-Type: P2-1984 (2) Content-Identifier: 2136 Alternate-Recipient: Allowed From: Peter Feil Message-Id: <2136*/S=feil/OU=rus/PRMD=uni-stuttgart/ADMD=d400/C=de/@MHS> To: Christian Wettergren Cc: mbone, rem-conf@es.net In-Reply-To: <199507201715.TAA06617@piraya.electrum.kth.se> Subject: Re: IETF transmission quality... > >Hi! > >The Multicast Production Team at the 33rd IETF would like >to get reports on perceived quality in different corners >of the world. Well, maybe it's interesting for other people to get an idea of how simple it is to join the MBONE: This morning I was busy configuring a new Sun SparcStation 20SX. With my colleagues already actively contributing to the IETF-MBONE sessions I had the idea to integrate this new machine into this scenario. And this is what I did: - install multicast capability: 5 min. (see ftp://www-ks.rus.uni-stuttgart.de/pub/mice/mrouted) - install SunVideo board and video camera: 5 min - install MBONE-tools: 2 min. (in Stuttgart a simple mount via NFS) - start the MBONE applications and get used to them: 30 min It took me less than 1 hour to have my new workstation connected to the MBONE and to the IETF sessions. Transmission quality: We were connected to the IETF via a 2 Mbit/s SMDS link to UCL (London) and then via the European ATM-Pilot directly to IETF in Stockholm. The transmission quality was good (listening at suntrec.rus.uni-stuttgart.de) with an average loss rate of 10%. Our main problem was the LAN configuration (Ethernet) contributing to this overall loss rate with app. 90%. In the near future we will solve this problem by using ATM-LAN connections A highlight was the participation in an international secure conferencing session using the "upgraded" MBONE tools with new keyword capabilities. Peter --------------------------------------------------------------- Peter Feil University of Stuttgart Computing Center phone : ++49-711-685 5735 Allmandring 30 fax : ++49-711-678 7626 70550 Stuttgart e-mail: feil@rus.uni-stuttgart.de Germany --------------------------------------------------------------- From list-mgr@ISI.EDU Thu Jul 20 10:38:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 17:39:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 17:39:06 -0700 Received: from mvs.oac.ucla.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 20 Jul 1995 17:39:04 -0700 Message-Id: <199507210039.AA02000@venera.isi.edu> Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1) with BSMTP id 4556; Thu, 20 Jul 95 17:39:25 PST Date: Thu, 20 Jul 95 17:38 PDT To: mbone, rem-conf@ES.NET From: Denis DeLaRoca (310) 825-4580 Subject: Sparc 4 and MBONE Tools ??? Can anyone report on experiences running the MBONE tools on the fairly new Sparc 4 platforms? Is the audio hardware like the one on the Sparc 5 or like the one in the Sparc 20, and does it work without problems? How do VIC and the SunVideo card perform on this platform? -- Denis From list-mgr@ISI.EDU Fri Jul 21 09:52:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 00:53:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 00:53:29 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 00:53:23 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 21 Jul 1995 00:53:16 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 21 Jul 1995 08:52:38 +0100 To: Peter Feil Cc: Christian Wettergren , mbone, rem-conf@es.net Subject: Re: IETF transmission quality... In-Reply-To: Your message of "Fri, 21 Jul 95 01:09:19 +0100." <2136*/S=feil/OU=rus/PRMD=uni-stuttgart/ADMD=d400/C=de/@MHS> Date: Fri, 21 Jul 95 08:52:33 +0100 Message-Id: <5702.806313153@cs.ucl.ac.uk> From: Jon Crowcroft >Transmission quality: >We were connected to the IETF via a 2 Mbit/s SMDS link >to UCL (London) and then via the European ATM-Pilot >directly to IETF in Stockholm. >The transmission quality was good (listening at >suntrec.rus.uni-stuttgart.de) with an average loss >rate of 10%. Our main problem was the LAN configuration >(Ethernet) contributing to this overall loss rate with >app. 90%. In the near future we will solve this problem >by using ATM-LAN connections how can traffic that fits on a 2Mbps link swamp a 10Mbps ethernet? we were receiving perfectly ok from the ATM net onto our local ethernets, even the 2 high bandwidth video streams, without any trouble..... do you have an overlaoded mrotued at the last hop maybe? or a stressed out LAN? ATM LAN will NOT help you deliver to lots of hosts very easily...by the way..since there is no easy mapping fro mIP multipoint to ATM multipoint calls (except in Fore kit...), and i nany case, you wont get this across the WAN, so you'll still have to go via an IP router between the WAN ATM and your LAN ATM....and take the WAN IP tunnel feed, then have a router make a local ATM multipoint call... cheers jon From list-mgr@ISI.EDU Fri Jul 21 10:28:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 01:34:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 01:29:21 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 01:28:15 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id JAA09115; Fri, 21 Jul 1995 09:27:38 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id JAA01699; Fri, 21 Jul 1995 09:28:52 +0100 Date: Fri, 21 Jul 1995 09:28:52 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Jon Crowcroft Cc: Peter Feil , Christian Wettergren , mbone, rem-conf@es.net Subject: Re: IETF transmission quality... In-Reply-To: <5702.806313153@cs.ucl.ac.uk> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 21 Jul 1995, Jon Crowcroft wrote: > > >Transmission quality: > >We were connected to the IETF via a 2 Mbit/s SMDS link > >to UCL (London) and then via the European ATM-Pilot > >directly to IETF in Stockholm. > >The transmission quality was good (listening at > >suntrec.rus.uni-stuttgart.de) with an average loss > >rate of 10%. Our main problem was the LAN configuration > >(Ethernet) contributing to this overall loss rate with > >app. 90%. In the near future we will solve this problem > >by using ATM-LAN connections > > how can traffic that fits on a 2Mbps link swamp a 10Mbps ethernet? Perhaps he meant it the other way round? That the traffic he already had on the 10Mbps ethernet was swamping the <2Mbps MBONE traffic. > we were receiving perfectly ok from the ATM net onto our local > ethernets, even the 2 high bandwidth video streams, without any > trouble..... And when the ATM was up and one of the main UK Mbone routers was up the loss at Edinburgh was about 0%. During some of the evening transmissions the high bandwidth video was fantastic. Unfortunately, we had two problems one of the main UK mrouteds collapsed during the first day and didn't get fixed until the second. And then on Thursday the ATM tunnels to UCL went down and we were then routing over the old tunnels through broodjeham. This was bareable but up to 30% loss was noticed. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Fri Jul 21 05:15:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 04:19:49 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 04:19:08 -0700 Received: from unb.ca (hermes.csd.unb.ca) by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 04:19:06 -0700 Received: from cythera.unb.ca by unb.ca (8.6.12/950414-15:35) id IAA17241; Fri, 21 Jul 1995 08:19:02 -0300 Date: Fri, 21 Jul 1995 08:15:30 -0300 (ADT) From: "Dwight E. Spencer" To: "Denis DeLaRoca (310) 825-4580" Cc: mbone, rem-conf@es.net Subject: Re: Sparc 4 and MBONE Tools ??? In-Reply-To: <199507210039.AA02000@venera.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 20 Jul 1995, Denis DeLaRoca (310) 825-4580 wrote: > Can anyone report on experiences running the MBONE tools on the fairly > new Sparc 4 platforms? Is the audio hardware like the one on the Sparc 5 > or like the one in the Sparc 20, and does it work without problems? How > do VIC and the SunVideo card perform on this platform? I've used vic, nv, sd and wb without -any- problems on my sparc 4 running solaris 2.4. I have not tried to use vat, but I have started it, because I haven't recieved my (optional) sound card yet. The order just went in this last week. I'm not sure if it will have the same driver problems that the sparc 5's did, but I'll respond on it's activity after I try it. dwight s. ---------------------------------------------------------------------------- Dwight E. Spencer University of New Brunswick Mail: spencer@unb.ca Community Access Canada Phone: +1 506 447 3060 "C-Net" Server Administrator Url: http://cnet.unb.ca/staff/dspencer/ From list-mgr@ISI.EDU Fri Jul 21 07:31:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 08:34:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 08:33:53 -0700 Received: from titan.sprintlink.net by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 08:33:50 -0700 Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id LAA15941; Fri, 21 Jul 1995 11:31:32 -0400 Date: Fri, 21 Jul 1995 11:31:32 -0400 From: Vadim Antonov Message-Id: <199507211531.LAA15941@titan.sprintlink.net> To: J.Crowcroft@cs.ucl.ac.uk, feil@rus.uni-stuttgart.d400.de Subject: Re: IETF transmission quality... Cc: cwe@it.kth.se, mbone, rem-conf@es.net >how can traffic that fits on a 2Mbps link swamp a 10Mbps ethernet? A typical ethernet breaks down at about 3Mbps *total*, and the E-1 pipe can easily run at 4Mbps (it's full duplex). >ATM LAN will NOT help you deliver to lots of hosts very easily... Unless you have wads of money to burn. If you do, go buy a DEC's FDDI switch, and off-the-shelf FDDI cards (better full-duplex ones). Sure beats any ATM you can find. --vadim From list-mgr@ISI.EDU Fri Jul 21 07:57:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 08:58:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 08:58:15 -0700 Received: from burdell.cc.gatech.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 08:58:14 -0700 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.6.12/8.6.9) with ESMTP id LAA19015; Fri, 21 Jul 1995 11:58:09 -0400 Received: (from kevin@localhost) by flora.cc.gatech.edu (8.6.10/8.6.9) id LAA24018; Fri, 21 Jul 1995 11:57:49 -0400 Date: Fri, 21 Jul 1995 11:57:49 -0400 From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199507211557.LAA24018@flora.cc.gatech.edu> To: kevin@cc.gatech.edu Subject: Mail to both mbone and rem-conf lists After all the duplicate mail on both the mbone and rem-conf lists lately, I'm going to re-send a message originally sent to both lists on Jan 11, 1994. It is a good explanation of the two lists, and describes the type of mail appropriate for each. -Kevin Almeroth P.S. The original authors names have been removed in case their opinion on the subject have changed. So I take no credit. ------------------------------------------------------------------------ REM-CONF: - technical discussions that are related to all the pieces of the puzzle involved in accomplishing remote conferencing (one-one, one-to-many, many-to-many), including software, hardware, and protocols - participants are developers and end-users of remote conferencing, therefore it is the preferred list for: - release notes for new applications, such as audio/video tools - announcements of events on the MBONE that can be received by the people who run these tools, since rem-conf should reach most/many of the potential viewers MBONE: - purpose is to manage the engineering and operation of the MBONE itself - participants are those who run MBONE nodes (i.e., a narrower audience than rem-conf), therefore is is the preferred list for: - requests for MBONE tunnels to be set up or changed - questions about the multicast kernel software, since the person who builds multicast kernels for a site is likely to be the same one who runs the MBONE node for that site - release notes for new MBONE monitoring tools From list-mgr@ISI.EDU Fri Jul 21 02:19:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 09:22:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 09:22:37 -0700 Received: from inet-gw-1.pa.dec.com by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 09:22:36 -0700 Received: from bigpink.pa.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA04439; Fri, 21 Jul 95 09:19:24 -0700 Received: by bigpink.pa.dec.com; id AA23536; Fri, 21 Jul 1995 09:19:24 -0700 Message-Id: <9507211619.AA23536@bigpink.pa.dec.com> To: Jon Crowcroft Cc: mbone Subject: Re: IETF transmission quality... In-Reply-To: Message of Fri, 21 Jul 95 08:52:33 +0100 from Jon Crowcroft <5702.806313153@cs.ucl.ac.uk> Date: Fri, 21 Jul 95 09:19:23 -0700 From: berc@pa.dec.com X-Mts: smtp ATM LAN will NOT help you deliver to lots of hosts very easily...by the way..since there is no easy mapping fro mIP multipoint to ATM multipoint calls (except in Fore kit...), and i nany case, you wont get this across the WAN, so you'll still have to go via an IP router between the WAN ATM and your LAN ATM....and take the WAN IP tunnel feed, then have a router make a local ATM multipoint call... Many vendor's ATM switches and host adapters support multicast. As an existence proof, BAGNet is composed of DEC, Newbridge, Synoptics, Xerox, and Fore switches, and has a fully-connected PVC mesh for all sixty hosts including multicast distribution. Running IP-mulicast at mbone rates (or a bit more) over ATM LANs, MANs, and WANS is dead simple. Some details of the status, setup and configuration are at: http://chocolate.research.digital.com/status.html lance berc From list-mgr@ISI.EDU Fri Jul 21 10:18:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 10:19:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 10:18:53 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 10:18:48 -0700 Received: from hillfoot.cent.gla.ac.uk ([130.209.30.12]) by quark.isi.edu (5.65c/5.61+local-20) id ; Fri, 21 Jul 1995 10:18:26 -0700 Received: from hillhead.cent.gla.ac.uk by hillfoot.cent.gla.ac.uk with SMTP-GLA (PP); Fri, 21 Jul 1995 18:16:46 +0100 Received: from kite.psy.gla.ac.uk by hillhead.cent.gla.ac.uk with SMTP (PP); Fri, 21 Jul 1995 18:16:39 +0100 From: Anne Marie Date: Fri, 21 Jul 95 18:19:06 BST Message-Id: <12245.9507211719@swan.psy.gla.ac.uk.psy.gla.ac.uk> To: mbone, rem-conf@es.net Subject: Stormy Waters - Tonight !! Stormy Waters Tonight and tomorrow night between approx 9 pm to 11.30 (GMT+1) Stormy Waters will be transmitted on the mbone on 224.2.17.150 with a CU-SeeMe reflector on 224.2.17.151. the event is advertised in 'sd'. We will be using Vic and Vat. As this event involves many fast moving video images we are broadcasting video in jpeg mode at 250kb/s. If this proves to be a problem for anyone or any network or if you have any suggestions for improvement please email annemari@psy.gla.ac.uk ============================================================================= Anne Marie Fleming Tel: +44 41 330 5424 University of Glasgow Fax: +44 41 339 8889 56 Hillhead St Telex: 777070 UNIGLA Glasgow G12 8QB, U.K. email: annemari@psy.gla.ac.uk www url: http://www.psy.gla.ac.uk/staff/annemari.html ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Fri Jul 21 04:53:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 11:55:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 11:54:56 -0700 Received: from ptavv.nersc.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 11:54:54 -0700 Received: from localhost by ptavv.nersc.gov; (5.65/1.1.8.2/08Feb94-0649PM) id AA19085; Fri, 21 Jul 1995 11:53:45 -0700 Message-Id: <9507211853.AA19085@ptavv.nersc.gov> To: Vadim Antonov Cc: J.Crowcroft@cs.ucl.ac.uk, feil@rus.uni-stuttgart.d400.de, cwe@it.kth.se, mbone, rem-conf@es.net, oberman@nersc.gov Subject: Re: IETF transmission quality... In-Reply-To: Your message of "Fri, 21 Jul 95 11:31:32 EDT." <199507211531.LAA15941@titan.sprintlink.net> Date: Fri, 21 Jul 95 11:53:44 -0700 From: "Kevin Oberman" X-Mts: smtp > Date: Fri, 21 Jul 1995 11:31:32 -0400 > From: Vadim Antonov > > >how can traffic that fits on a 2Mbps link swamp a 10Mbps ethernet? > > A typical ethernet breaks down at about 3Mbps *total*, and the > E-1 pipe can easily run at 4Mbps (it's full duplex). This is total bilge as anyone who has spent much time with Ethernet knows. But it refuses to die because people who should know better keep repeating it. For some facts, see "Measured Capacity of an Ethernet: Myths and Reality" by Boggs, Mogul, and Kent. It's available from http://www.research.digital.com/wrl/publications/abstracts/88.4.html In the IP world, Van Jacobson has documented actual, measured throughput of > 1MB (or 8Mbps) on an Ethernet, although this is NOT feasible in typical cases. But 6 Mbps is easily attainable on a typical Ethernet and 7 Mbps is not unusual. I can't find a reference for this right now, but it's fairly well known. While the Ethernet in question may be congested, it is not congested because of traffic from the E-1 or any 4 Mbps pipe. Please stop this foolishness before someone else is stuck with a token ring or Ethernet switch they don't really need. R. Kevin Oberman Energy Sciences Network (ESnet) National Energy Research Supercomputer Center (NERSC) Lawrence Livermore National Laboratory (LLNL) EMAIL: koberman@llnl.gov Phone: +1 510 422-6955 From list-mgr@ISI.EDU Fri Jul 21 09:14:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 12:14:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 12:14:17 -0700 Received: from elvis.ecl.wustl.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 12:14:16 -0700 Received: by elvis.ecl.wustl.edu (5.x/ECL-A1.27) id AA04659; Fri, 21 Jul 1995 14:14:13 -0500 Date: Fri, 21 Jul 1995 14:14:13 -0500 From: sjp@ecl.wustl.edu (Steve Polityka) Message-Id: <9507211914.AA04659@elvis.ecl.wustl.edu> To: mbone Subject: pruning for Solaris 2.4 I was wondering if there was a way to filter out certain conferences that are transmitted across the mbone. We are considering setting up a tunnel from us, a department at a university, to the rest of the university, but we don't want to flood the network. We are running ipmulticast 3.3 on Solaris 2.4. I know you can limit the bandwidth by using the rate limit option but is there a way to limit which conferences we pass? Any help would be greatly appreciated. Thanks. Steve Polityka (sjp@ecl.wustl.edu) From list-mgr@ISI.EDU Fri Jul 21 12:33:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 13:37:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 13:37:16 -0700 Received: from cerc.wvu.edu (cathedral.cerc.wvu.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 13:37:15 -0700 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA29093; Fri, 21 Jul 95 16:33:26 EDT Received: by elk (5.x//ident-1.0) id AA07575; Fri, 21 Jul 1995 16:33:17 -0400 Date: Fri, 21 Jul 1995 16:33:16 -0400 (EDT) From: "Todd L. Montgomery" Subject: Re: IETF transmission quality... To: Kevin Oberman Cc: Vadim Antonov , J.Crowcroft@cs.ucl.ac.uk, feil@rus.uni-stuttgart.d400.de, cwe@it.kth.se, mbone, rem-conf@es.net In-Reply-To: <9507211853.AA19085@ptavv.nersc.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 21 Jul 1995, Kevin Oberman wrote: > For some facts, see "Measured Capacity of an Ethernet: Myths and > Reality" by Boggs, Mogul, and Kent. It's available from > http://www.research.digital.com/wrl/publications/abstracts/88.4.html > > In the IP world, Van Jacobson has documented actual, measured > throughput of > 1MB (or 8Mbps) on an Ethernet, although this is NOT > feasible in typical cases. But 6 Mbps is easily attainable on a > typical Ethernet and 7 Mbps is not unusual. I can't find a reference > for this right now, but it's fairly well known. Also, I have documented throughput of > 1100 KBps on an ethernet using RMP. http://research.ivv.nasa.gov/projects/RMP/Docs/RMPdocs.html under Performance Graphs. > While the Ethernet in question may be congested, it is not congested > because of traffic from the E-1 or any 4 Mbps pipe. Definitely. However, packet starvation effect does do quite a bit of harm if large numbers of senders are blasting away at the same time. For some other examinations of CSMA/CD and the packet starvation effect that makes several senders on an ethernet drop ethernet to about 60% utilization, ftp://tenet.cs.berkeley.edu/pub/users/whetten/FDDQ Thanks to Brian Whetten! -- Todd From list-mgr@ISI.EDU Fri Jul 21 18:15:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 19:18:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 19:16:44 -0700 Received: from titan.sprintlink.net by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 21 Jul 1995 19:16:42 -0700 Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id WAA16366; Fri, 21 Jul 1995 22:15:06 -0400 Date: Fri, 21 Jul 1995 22:15:06 -0400 From: Vadim Antonov Message-Id: <199507220215.WAA16366@titan.sprintlink.net> To: avg@sprint.net, oberman@nersc.gov Subject: Re: IETF transmission quality... Cc: J.Crowcroft@cs.ucl.ac.uk, cwe@it.kth.se, feil@rus.uni-stuttgart.d400.de, mbone, rem-conf@es.net >> A typical ethernet breaks down at about 3Mbps *total*, and the >> E-1 pipe can easily run at 4Mbps (it's full duplex). >This is total bilge as anyone who has spent much time with Ethernet >knows. But it refuses to die because people who should know better >keep repeating it. >For some facts, see "Measured Capacity of an Ethernet: Myths and >Reality" by Boggs, Mogul, and Kent. It's available from >http://www.research.digital.com/wrl/publications/abstracts/88.4.html That study has explicit disclaimers to the effect that it does not represent "typical" cases. The reality is that the performance of Ethernet depends quite a lot on very subtle factors like self-synchronization and how well carrier/collision detection works. Most of PC Ethernet adapters are simply broken as designed (you can't argue with that, not with me :) and i saw may "solid" equipment like bridges which was doing completely insane things (time to remember old MAE-East?) In the IP world, Van Jacobson has documented actual, measured throughput of > 1MB (or 8Mbps) on an Ethernet, although this is NOT feasible in typical cases. >But 6 Mbps is easily attainable on a >typical Ethernet and 7 Mbps is not unusual. I can't find a reference >for this right now, but it's fairly well known. In my practice congestion collapses on Ethernets at 500Kbps are as common as Ethernets running at 6Mbps. You are also forgetting that point-to-point pipes tend to deliver more-less constant-rate traffic, which does not fit very well into the stochastic Ethernet model. I.e. you end up with D/M/1 kind of situation, with performance quite worse than M/M/1 model of Ethernet with end hosts and no gateways to WAN. (Well, for the purists, M is really not M but something self-similar). The fact is neither of studies you mentioned is directly applicable, as even the crude queueing theory models behave quite differently for LAN-with-hosts and LAN-with-WAN-gateway. >Please stop this foolishness before someone else is stuck with a token >ring or Ethernet switch they don't really need. Ethernet switch is useful for other reasons (like security and fault isolation). >R. Kevin Oberman >Energy Sciences Network (ESnet) Regards, --vadim From list-mgr@ISI.EDU Sat Jul 22 01:00:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 22 Jul 1995 01:01:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 22 Jul 1995 01:00:43 -0700 Received: from camis.kaist.ac.kr by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 22 Jul 1995 01:00:06 -0700 Received: (from jwjung@localhost) by camis.kaist.ac.kr (8.6.12H1/8.6.9) id QAA04138 for mbone@isi.edu; Sat, 22 Jul 1995 16:57:47 +0900 From: Jung Joowon Message-Id: <199507220757.QAA04138@camis.kaist.ac.kr> Subject: [Help] Cannot here VAT sound on CU-SeeMe thru Reflector To: mbone Date: Sat, 22 Jul 1995 16:57:47 +0900 (JST) X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 1206 Hello... I installed ipmulti-3.5 on SunOS 4.1.3, sd, vat, nv. And I have tested sd and vat with those of Solaris 2.3, and they works well. I installed CU-SeeMe reflector 3.0b2 on both SunOS 4.1.3 and Solaris 2.3, and installed CU-SeeMe 0.65b2 on sevral PC's which have Sound Blaster 16 card & driver. (SunOS, Solaris, PC's are on the same subnet.) When I start reflector with no configuration file, every CU-SeeMe PC clients recognized each other. I wrote reflect.conf as follows to receive VAT sound by CU-SeeMe. VAT-MC-PORT 35199 VAT-MC-IN 224.2.159.236 VAT-MC-OUT 32 224.2.159.236 VAT-CONF-ID 58907 Each number was obtained from sd by creating an audio session. I executed reflect, vat, and CU-SeeMe. Of course, I connected CU-SeeMe to the reflect and turned on receive audio option on CU-SeeMe. But... I cannot hear any sound from CU-SeeMe client. I checked VAT's operation by hearing sound from another VAT. CU-SeeMe reflector sends its PC clients info to VAT. (I can see the entry names on paticipants list of VAT.) But... I cannot hear the sound on my PC. Where do I wrong? Thanks in advance... -Jung Joowon P.S: reflect 4.0b1 crashes(Segmentaton fault) when VAT starts to send audio. From list-mgr@ISI.EDU Sat Jul 22 08:52:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 22 Jul 1995 09:57:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 22 Jul 1995 09:51:44 -0700 Received: from gigabit.bellcore.com by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 22 Jul 1995 09:51:43 -0700 Received: (from sincos@localhost) by gigabit.bellcore.com (8.6.9/8.6.10) id MAA21144; Sat, 22 Jul 1995 12:52:29 -0400 Date: Sat, 22 Jul 1995 12:52:29 -0400 From: sincos@bellcore.com (Dave Sincoskie) Message-Id: <199507221652.MAA21144@gigabit.bellcore.com> To: cwe@it.kth.se Subject: MBONE quality Cc: mbone, mwg@gigabit.bellcore.com Christian, I watched (or tried to watch) the IETF MBONE broadcasts all four days (Monday-Thursday). The received quality was atrocious, and as a result I got basically no use out of it on Monday, Tuesday, and Wednesday, but some use on Thursday. I was experiencing high loss rates, especially during the 0800-1800 EDT timeframe I was attempting to use. Loss rates measured by VAT ranged from a low of about 8% (for one glorious 15 minute period on Thursday) to 80% (most of the day Monday and Tuesday). I suspect much of the problem lies in the network of Bellcore's provider, GES (aka JVNC). They had a poorly configured tunnel, which they got corrected on Wednesday. With the second tunnel configuration, which I used most of Thursday, the loss rate seemed to hover in the 20-50% range. On Thursday I was noticing extended (3-5 minute) outages that seemed to be disconencts or either all of Europe, or sometimes just Sweden. May have been some sort of routing problem, but I really don't know. Packets would just completely cease for 3-5 minutes. This happened at least 5 times on Thursday. On Monday and Tuesday I could receive video using nv, but on Wednesday and Thursday, my nv showed no video. Did you change transmission format? The whiteboards seemed to work pretty well. Dave P.S. I was watching from gigabit.bellcore.com (128.96.33.40). I believe the first tunnel was y-wing.jvnc.net (130.94.7.6), and the better one waters-gateway.jvnc.net (130.94.7.108) P.P.S. A suggestion for improvement would be to provide some telephone dial-in conference bridges with connections to the audio feeds. At least then I could hear something when the mbone craps out. >To: mbone@isi.edu >cc: rem-conf@es.net >Subject: IETF transmission quality... >Date: Thu, 20 Jul 95 19:15:43 +0200 >From: Christian Wettergren >Status: R > > >Hi! > >The Multicast Production Team at the 33rd IETF would like >to get reports on perceived quality in different corners >of the world. > >All comments and suggestions on improvements etc are most >welcome. > >We wish to thank you all and we hope that you enjoyed the >transmissions. > > Christian Wettergren (and the rest of the MBone crew) > cwe@it.kth.se > KTH/Teleinformatics > Stockholm, Sweden From list-mgr@ISI.EDU Wed Jul 22 17:54:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 23 Jul 1995 00:57:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 23 Jul 1995 00:56:12 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 23 Jul 1995 00:56:11 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id AAA28903; Sun, 23 Jul 1995 00:54:59 -0700 Message-Id: <199507230754.AAA28903@rx7.ee.lbl.gov> To: sincos@bellcore.com (Dave Sincoskie) Cc: cwe@it.kth.se, mbone, mwg@gigabit.bellcore.com Subject: Re: MBONE quality In-Reply-To: Your message of Sat, 22 Jul 95 12:52:29 EDT. Date: Sun, 23 Jul 95 00:54:58 PDT From: Van Jacobson Dave, I'm sure Christian would like to fix JVNC but I'm afraid it's beyond his control (and perhaps anyone's). I'm 3000 miles and three hops further away from Stockholm than you & reception here was almost perfect (<0.1% loss) except for a few 1-5 minute outages due to problems at mae-bone.psi.net. This was the best reception quality I've ever had from an IETF. (And I have to second Steve Casner's comments about the Stockholm crew really raising the bar on production quality -- the audio & video from the sessions was far & away the best ever & the extra effort made to scan the overheads into wb I found tremendously useful.) We've discussed your mbone problems in the past. They could be completely solved by simply re-homing your mbone tunnel from JVNC to the Bellcore dartnet gateway. (Other JVNC customers are not so lucky but you, at least, have a viable service alternative.) Another constructive thing you could do is upgrade to the 3.6 multicast software and encourage your providers to do likewise. If you're running 3.6, you can simply type "mtrace " to see both the path from to you and the loss rate at every hop along that path. I.e., when there's a problem, mtrace will tell you exactly where the problem is. Unfortunately, support for the query packet used by mtrace didn't appear until v3.4 of mrouted (released a year ago) and, not surprisingly, the providers most likely to be trouble spots are also the slowest to upgrade. Since mtrace is the best tool we have for finding & fixing mbone problems, Bill Fenner has been waging a one man campaign to get at least the major backbone links upgraded. You could help: If you type "mtrace ..." and it quits saying " didn't respond", complain loudly & publically that broken.net is broken & needs to be upgraded. As far as current US MBone problems (excluding JVNC), we know there's something wrong on the southern east-west backbone path (the one that goes mae-bone.psi.net - vinegar.sesqui.net - brahms.sdsc.edu - mbone.nsi.nasa.gov. The problem is most likely at brahms.sdsc.edu since everything else on the path runs 3.6 & reports low loss rates while brahms is a proteon which doesn't support mtrace and proteons are known to have problems with multicast traffic. There also seems to be a problem on the path between the central US (UIUC, NCAR, MIDNet, etc.) and the east coast. I'm suspicious of dc-mbone-1.sprintlink.net (with 32 tunnels!) but so few sites on this path have been upgraded that it's impossible to really isolate the cause. - Van From list-mgr@ISI.EDU Wed Jul 22 19:46:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 23 Jul 1995 02:53:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 23 Jul 1995 02:53:28 -0700 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 23 Jul 1995 02:53:27 -0700 Received: from icsib67.ICSI.Berkeley.EDU (whetten@icsib67.ICSI.Berkeley.EDU [128.32.201.167]) by icsia.ICSI.Berkeley.EDU (8.6.12/HUB+V8$Revision: 1.23 $) with ESMTP id CAA24499; Sun, 23 Jul 1995 02:46:57 -0700 Received: (whetten@localhost) by icsib67.ICSI.Berkeley.EDU (8.6.12/1.8) id CAA21558; Sun, 23 Jul 1995 02:46:52 -0700 Date: Sun, 23 Jul 1995 02:46:50 -0700 (PDT) From: Brian Whetten To: Kevin Oberman Cc: Vadim Antonov , J.Crowcroft@cs.ucl.ac.uk, feil@rus.uni-stuttgart.d400.de, cwe@it.kth.se, mbone, rem-conf@es.net, oberman@nersc.gov Subject: Re: IETF transmission quality... In-Reply-To: <9507211853.AA19085@ptavv.nersc.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes...an ethernet can handle 6-7 Mbps of realistic traffic. While very good, the Boggs&Mogul paper does not deal with the problem of starved packets. For a detailed analysis on the real capacity of an Ethernet, please see: B. Whetten, S. Steinberg, and D. Ferrari, "The Packet Starvation Effect in CSMA/CD LANs and a Solution", Proc. of IEEE Local Computer Networks Minneapolis, MN, pp. 206-217, October 1994. On Fri, 21 Jul 1995, Kevin Oberman wrote: > > Date: Fri, 21 Jul 1995 11:31:32 -0400 > > From: Vadim Antonov > > > > >how can traffic that fits on a 2Mbps link swamp a 10Mbps ethernet? > > > > A typical ethernet breaks down at about 3Mbps *total*, and the > > E-1 pipe can easily run at 4Mbps (it's full duplex). > > This is total bilge as anyone who has spent much time with Ethernet > knows. But it refuses to die because people who should know better > keep repeating it. > > For some facts, see "Measured Capacity of an Ethernet: Myths and > Reality" by Boggs, Mogul, and Kent. It's available from > http://www.research.digital.com/wrl/publications/abstracts/88.4.html > > In the IP world, Van Jacobson has documented actual, measured > throughput of > 1MB (or 8Mbps) on an Ethernet, although this is NOT > feasible in typical cases. But 6 Mbps is easily attainable on a > typical Ethernet and 7 Mbps is not unusual. I can't find a reference > for this right now, but it's fairly well known. > > While the Ethernet in question may be congested, it is not congested > because of traffic from the E-1 or any 4 Mbps pipe. > > Please stop this foolishness before someone else is stuck with a token > ring or Ethernet switch they don't really need. > > R. Kevin Oberman > Energy Sciences Network (ESnet) > National Energy Research Supercomputer Center (NERSC) > Lawrence Livermore National Laboratory (LLNL) > EMAIL: koberman@llnl.gov Phone: +1 510 422-6955 > From list-mgr@ISI.EDU Sun Jul 23 16:15:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 23 Jul 1995 21:08:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 23 Jul 1995 21:03:02 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Sun, 23 Jul 1995 21:03:02 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Sun, 23 Jul 1995 07:16:22 -0700 Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 23 Jul 1995 15:15:28 +0100 To: Vadim Antonov Cc: oberman@nersc.gov, cwe@it.kth.se, feil@rus.uni-stuttgart.d400.de, mbone, rem-conf@es.net Subject: Re: IETF transmission quality... In-Reply-To: Your message of "Fri, 21 Jul 95 22:15:06 EDT." <199507220215.WAA16366@titan.sprintlink.net> Date: Sun, 23 Jul 95 15:15:19 +0100 Message-Id: <1921.806508919@cs.ucl.ac.uk> From: Jon Crowcroft >>> A typical ethernet breaks down at about 3Mbps *total*, and the >>> E-1 pipe can easily run at 4Mbps (it's full duplex). >>This is total bilge as anyone who has spent much time with Ethernet >>knows. But it refuses to die because people who should know better >>keep repeating it. >>For some facts, see "Measured Capacity of an Ethernet: Myths and >>Reality" by Boggs, Mogul, and Kent. It's available from >>http://www.research.digital.com/wrl/publications/abstracts/88.4.html btw, its availaible in the latest ACM CCR as a reprint as [part of the 254th anniversay issue... >That study has explicit disclaimers to the effect that it does >not represent "typical" cases. in our expeirence of using ethernets as mbone "FIXes" (now being replaced by atm boxes as Mbone "NAPs"), the 3Mbps figure is sort of right but in general, we run a lot of our ethernets at 60-70% load quite happily - a lot of ethernets do not have "poisson arrtival" traffic (in fact, i've never seen a measurement of a study that showed a real erther that did the classic mythical figure (near 4Mbps, not 3) was the trivial undergrad result of maximum utilisation before the congestion knee for CSMA/CD >The reality is that the performance of Ethernet depends quite >a lot on very subtle factors like self-synchronization and >how well carrier/collision detection works. Most of PC Ethernet >adapters are simply broken as designed (you can't argue with that, >not with me :) and i saw may "solid" equipment like bridges which >was doing completely insane things (time to remember old MAE-East?) true, true, all sadly true.... >In the IP world, Van Jacobson has documented actual, measured >throughput of > 1MB (or 8Mbps) on an Ethernet, although this is NOT >feasible in typical cases. >>But 6 Mbps is easily attainable on a >>typical Ethernet and 7 Mbps is not unusual. I can't find a reference >>for this right now, but it's fairly well known. >In my practice congestion collapses on Ethernets at 500Kbps are as >common as Ethernets running at 6Mbps. yes, but this is often in overextended, badly tapped sites... >You are also forgetting that point-to-point pipes tend to deliver >more-less constant-rate traffic, which does not fit very well into >the stochastic Ethernet model. I.e. you end up with D/M/1 kind of >situation, with performance quite worse than M/M/1 model of Ethernet >with end hosts and no gateways to WAN. (Well, for the purists, M >is really not M but something self-similar). if you have a number of these, yes (we had 5 mrouteds at one point:-) but if you simply have a stuv ether with the mrouted (so basically, you have D/M/! from tow sources, inbound and outbound) then the utilisation ought to be ok up to around 7Mbps... [of course, this all assumes no other host traffic - if that exists, you will die badly well before this - this happens everynow and then when our multicast routing goes astray betwenn the 5 mrouted and the traffic in all directions starts traversing the ether that also has all our student machines on....) >The fact is neither of studies you mentioned is directly applicable, >as even the crude queueing theory models behave quite differently >for LAN-with-hosts and LAN-with-WAN-gateway. >>Please stop this foolishness before someone else is stuck with a token >>ring or Ethernet switch they don't really need. >Ethernet switch is useful for other reasons (like security and fault >isolation). but make sure your ether switch is good at emulating old fashioned bus multicast! some of them arent! actually, a good study of the use of bus and switched ethers for typical real mbone traffic (say a trace driven simulation or analysis based on some of this discussion) would be a useful thing to do... cheers jon From list-mgr@ISI.EDU Mon Jul 24 13:19:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 24 Jul 1995 00:30:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 24 Jul 1995 00:29:21 -0700 Received: from sun1.iihe.ac.be by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 24 Jul 1995 00:29:18 -0700 X400-Received: by mta sun1.iihe.ac.be in /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Mon, 24 Jul 1995 09:22:26 +0200 X400-Received: by mta elem5 in /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Mon, 24 Jul 1995 11:19:26 +0200 X400-Received: by /PRMD=iihe/ADMD=rtt/C=be/; Relayed; Mon, 24 Jul 1995 11:19:26 +0200 Date: Mon, 24 Jul 1995 11:19:26 +0200 X400-Originator: colin@helios.iihe.rtt.be X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=iihe/ADMD=rtt/C=be/;950724091926] X400-Content-Type: P2-1984 (2) Content-Identifier: 13030001 From: Michel Colin Message-Id: <13030001*/G=michel/S=colin/O=helios/PRMD=iihe/ADMD=rtt/C=be/@MHS> To: "Denis DeLaRoca 825-4580 (310)" (Non Receipt Notification Requested) Cc: mbone (Non Receipt Notification Requested), rem-conf@es.net (Non Receipt Notification Requested) In-Reply-To: <199507210039.AA02000@venera.isi.edu> Subject: Sparc 4 and MBONE Tools ??? ------------------------------ Start of body part 1 As far as I know audio is not provided by default on Sparc 4 ! Michel ------------------------------ Start of body part 2 =============================================================================== Michel Colin Tel. +32-2-650 57 03 Fax: +32-2-629 38 16 Universite Libre de Bruxelles Faculte des Sciences Service Telematique et Communication CP 230, Boulevard du triomphe B-1050 Bruxelles BELGIUM RFC822: colin@helios.iihe.rtt.be X.400 : C=be;ADMD=rtt;PRMD=iihe;O=helios;S=colin; X.500 : @c=be@o=Universite Libre de Bruxelles@ou=Faculte des Sciences@ou=Service Telematique et Communication@cn=Michel Colin ------------------------------------------------------------------------------- ------------------------------ End of body part 2 From list-mgr@ISI.EDU Mon Jul 24 05:58:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 24 Jul 1995 07:00:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 24 Jul 1995 06:59:40 -0700 Received: from stealth.sprintlink.net by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 24 Jul 1995 06:59:39 -0700 Received: (from rmartin@localhost) by stealth.sprintlink.net (8.6.10/8.6.9) id JAA17729; Mon, 24 Jul 1995 09:58:16 -0400 Date: Mon, 24 Jul 1995 09:58:16 -0400 (EDT) From: Richard Martin Subject: Re: MBONE quality To: Van Jacobson Cc: Dave Sincoskie , cwe@it.kth.se, mbone, mwg@gigabit.bellcore.com In-Reply-To: <199507230754.AAA28903@rx7.ee.lbl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 23 Jul 1995, Van Jacobson wrote: > Dave, > > There also seems to be a problem on the path between the central > US (UIUC, NCAR, MIDNet, etc.) and the east coast. I'm suspicious > of dc-mbone-1.sprintlink.net (with 32 tunnels!) but so few sites > on this path have been upgraded that it's impossible to really > isolate the cause. > > - Van > Van: You have reason to be suspicious of dc-mbone-1.sprintlink.net, it's still running 2.2 code as nothing else will work on an old SGI running IRIX 4.0.5f. We will be replacing it (and stk-mbone-1.sprintlink.net) in the next month or two with machines running whatever the latest mrouted stuff is at that time. We also plan on putting additional machines in our network to do multicast routing to take some of the load off of dc-mbone-1 as it is overloaded. Rich Martin Sprintlink Systems From list-mgr@ISI.EDU Mon Jul 24 03:56:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 24 Jul 1995 11:00:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 24 Jul 1995 11:00:17 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 24 Jul 1995 11:00:12 -0700 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with SMTP id KAA21478; Mon, 24 Jul 1995 10:58:08 -0700 Message-Id: <199507241758.KAA21478@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Richard Martin Cc: Van Jacobson , Dave Sincoskie , cwe@it.kth.se, mbone, mwg@gigabit.bellcore.com Subject: Re: MBONE quality In-Reply-To: Your message of "Mon, 24 Jul 1995 09:58:16 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Jul 1995 10:56:38 -0700 From: "Amancio Hasty Jr." >>> Richard Martin said: > > You have reason to be suspicious of dc-mbone-1.sprintlink.net, > it's still running 2.2 code as nothing else will work on an old SGI > running IRIX 4.0.5f. We will be replacing it (and > stk-mbone-1.sprintlink.net) in the next month or two with machines > running whatever the latest mrouted stuff is at that time. We also > plan on putting additional machines in our network to do multicast > routing to take some of the load off of dc-mbone-1 as it is overloaded. > > Rich Martin > Sprintlink Systems If you have a PC laying around you can run FreeBSD and mrouted 3.6. The current snapshot of FreeBSD includes mrouted 3.6. Amancio From list-mgr@ISI.EDU Mon Jul 24 06:07:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 24 Jul 1995 13:08:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 24 Jul 1995 13:07:44 -0700 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 24 Jul 1995 13:07:42 -0700 Received: from icsib67.ICSI.Berkeley.EDU (whetten@icsib67.ICSI.Berkeley.EDU [128.32.201.167]) by icsia.ICSI.Berkeley.EDU (8.6.12/HUB+V8$Revision: 1.23 $) with ESMTP id NAA18871 for ; Mon, 24 Jul 1995 13:07:41 -0700 From: whetten@ICSI.Berkeley.EDU (Brian Whetten) Received: (whetten@localhost) by icsib67.ICSI.Berkeley.EDU (8.6.12/1.8) id NAA26018 for mbone@isi.edu; Mon, 24 Jul 1995 13:07:36 -0700 Date: Mon, 24 Jul 1995 13:07:36 -0700 Message-Id: <199507242007.NAA26018@icsib67.ICSI.Berkeley.EDU> To: mbone Subject: How reliable is the mbone? Hello. The Unidata Internet Data Distribution (IDD) system (from the University Center for Atmospheric Research) currently distributes atmospheric information from sattelite feeds to approximately 100 universities in near real time, using a system of hierarchical TCP/IP streams. They have arranged their sites into a hierarchy, and connect all the nodes with TCP/IP connections. Their current bandwidth is about 100 Kbps. Their system works reasonably well, but has some definite problems in scalability. The Reliable Multicast Protocol (with some additional layers) will suit their needs very well, if the mbone has reached sufficient maturity and stability. Their system is exactly the type of thing that the combination of IP Multicast and RMP have been designed to support. It is just a question of timing. So, my questions are: How stable is the mbone at this time? Do the backbone routers all support pruning? Would sites connected via IP Multicast partition away from the rest of the net more often than if they are using IP? How much so? RMP can default to a unicast route for a site if the mbone connectivity to it is flaky, so we can handle some partitions and problems. If the mbone isn't quite mature yet (as I think), what type of timeline do people expect for it before the mbone as it is goes away and most of the backbone routers reliably support IP Multicast with the new routing algorithms? Thanks! Brian Whetten whetten@cs.berkeley.edu From list-mgr@ISI.EDU Tue Jul 25 10:27:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 01:32:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 01:30:32 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 01:30:11 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Tue, 25 Jul 1995 01:29:53 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 25 Jul 1995 09:27:45 +0100 To: whetten@ICSI.Berkeley.EDU (Brian Whetten) Cc: mbone Subject: Re: How reliable is the mbone? In-Reply-To: Your message of "Mon, 24 Jul 95 13:07:36 PDT." <199507242007.NAA26018@icsib67.ICSI.Berkeley.EDU> Date: Tue, 25 Jul 95 09:27:39 +0100 Message-Id: <6659.806660859@cs.ucl.ac.uk> From: Jon Crowcroft >How stable is the mbone at this time? Do the backbone routers all support >pruning? Would sites connected via IP Multicast partition away from >the rest of the net more often than if they are using IP? How much so? >RMP can default to a unicast route for a site if the mbone connectivity >to it is flaky, so we can handle some partitions and problems. Brian the mbone is as stable as your provider lets it be.... (i.e. how long is a piece of string....) once, when there was an NSFNet you had one lot of people for academic and research network provision (we still do in the UK...they provide a "pilot service" mbone that is pretty robust, but still not embedded in backbone routers due to lack of appropriate technology for scalable backbone multicast routing with pruning...) now, the comercial providers in the US (and europe) give you what you pay for - so i'm sure if you ask for multicast as part of the robust service, they will cost it and provide it.... if you want to offer a steady IP traffic rate rather than elastic TCP like behaviour (c.f. a 'discussion' on this list a few weeks back) you may find some providers want to discuss this beforehand...as it affects their backbone design decisions (and possibly router selection criteria) btw, doesn't IMM do roughly what you are proposing? cheers jon From list-mgr@ISI.EDU Tue Jul 25 06:09:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 13:09:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 13:09:24 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 13:09:22 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id NAA02883; Tue, 25 Jul 1995 13:09:29 -0700 Message-Id: <199507252009.NAA02883@rx7.ee.lbl.gov> To: whetten@ICSI.Berkeley.EDU (Brian Whetten) Cc: mbone Subject: Re: How reliable is the mbone? In-Reply-To: Your message of Mon, 24 Jul 95 13:07:36 PDT. Date: Tue, 25 Jul 95 13:09:28 PDT From: Van Jacobson I think you're asking the wrong questions Brian. The mbone has 500kb/s of bandwidth, a hard limit enforced (at least at several backbone sites) by rate limiting. There are currently over 2500 nets attached to the mbone and, based on our traffic logs, about 12,000 people routinely use it. Since the average `event' on the mbone takes 40-150kb/s, it should be clear that the bandwidth supply lags demand by a factor of over 1000 & users cannot do as they please over the mbone. Currently we accommodate the huge mismatch between supply & demand by a rough concensus, manual, scheduling process that seems to be based on a "greatest good for greatest number" principle plus encouraging a wide diversity of use (as is appropriate for research facility investigating a new communication modality). You are asking if some organization can use 1/4 of the available bandwidth for it's own private purposes on a full time, production basis. My reaction would be "No, that would destroy the concensus process that makes the mbone work." (Have you ever heard the phrase "tragedy of the commons"?) If you had asked the question "what has to happen for UCAR to be able to distribute atmospheric data to universities via IP multicast over the Internet?" a more useful answer is possible: 1. Hierarchical multicast has to get deployed. (Your question about pruning was also off - the issue is not whether backbone hosts support pruning but rather the consequences of some hosts not supporting pruning (since you will never get everyone to upgrade). Currently, if even one subnet per country doesn't support pruning then all countries receive all multicast traffic. This will only change when hierarchical multicast is deployed (hopefully later this year). 2. The backbone providers (at least) have to have multicast support in their routing infrastructure, not added on top via `tunnels'. In the early days of the mbone, it was small enough, and the people configuring tunnels were knowledgeable enough about the physical topology, that the multicast scaling property of only one packet per source packet per link was preserved. These days random people are configuring tunnels with no thought at all for the physical topology. And providers, pushed by the sudden interest in the mbone, are hooking up customers much faster than they can expand their infrastructure. The result is the average fanout on an ISP mbone machine has gone from 4 to 15 and some crucial backbone machines have fanouts of 20-30. This means that the incoming traffic rate gets multiplied by a factor of 20-30 so, for example, at some backbone sites the tunnel machine would have to send 15Mb/s over its ethernet to handle the 500kb/s max mbone rate. The end result is that everyone downstream of these underprovisioned nodes sees a 40% drop rate. It's futile & absurd to ask ISPs to provision separately for multicast & unicast (they can barely keep up with the unicast demand) so the only solution here is native multicast support. That happily also solves the problem of tunnel/topology mismatch. Item 1 has to happen in the next few months or the mbone will collapse. Bill Fenner & Steve Deering are working hard on it so the code will probably happen in time. Most of the important players understand the need so the deployment may also happen in time. Item 2 probably depends on how ISPs perceive the customer demand for multicast (relative to all the other customer demands). The best way to make it happen is to get UCAR and all its user community saying "multicast is very important to us & our provider has to supply it or we'll change providers". If you want UCAR to eventually use RMP for distribution, that's the place to start. - Van From list-mgr@ISI.EDU Wed Jul 26 19:28:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 16:34:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 16:28:49 -0700 Received: from mail.mel.aone.net.au by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 16:28:45 -0700 Received: from ipx.office.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by mail.mel.aone.net.au (8.6.11/8.6.11) with ESMTP id JAA24227; Wed, 26 Jul 1995 09:28:42 +1000 Received: from ipx.office.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by ipx.office.bne.aone.net.au (8.6.11/8.6.12) with ESMTP id JAA18155; Wed, 26 Jul 1995 09:28:14 +1000 To: Van Jacobson Cc: whetten@icsi.berkeley.edu (Brian Whetten), mbone Subject: Re: How reliable is the mbone? In-Reply-To: Your message of "Tue, 25 Jul 1995 13:09:28 PDT." <199507252009.NAA02883@rx7.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <18149.806714893.1@ipx.office.bne.aone.net.au> Date: Wed, 26 Jul 1995 09:28:13 +1000 Message-Id: <18151.806714893@ipx.office.bne.aone.net.au> From: George Michaelson Van, if you were re-visiting some of the coding decisions, in the light of the explosive takeup of MBONE, would you have included more "management" control in vat/sd/wb than currently? I think that the relationship between default TTL and bandwidth that got coded into vic (and vat?) is the kind of thing that at an application level will help to constrain bandwidth wastage. Maybe vat should only permit lpc when used point-to-point? -George From list-mgr@ISI.EDU Wed Jul 26 19:53:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 16:55:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 16:54:00 -0700 Received: from mail.mel.aone.net.au by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 16:53:59 -0700 Received: from ipx.office.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by mail.mel.aone.net.au (8.6.11/8.6.11) with ESMTP id JAA24303; Wed, 26 Jul 1995 09:53:57 +1000 Received: from ipx.office.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by ipx.office.bne.aone.net.au (8.6.11/8.6.12) with ESMTP id JAA18209; Wed, 26 Jul 1995 09:53:29 +1000 Cc: Van Jacobson , whetten@icsi.berkeley.edu (Brian Whetten), mbone Subject: Re: How reliable is the mbone? In-Reply-To: Your message of "Wed, 26 Jul 1995 09:28:13 +1000." <18151.806714893@ipx.office.bne.aone.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <18203.806716408.1@ipx.office.bne.aone.net.au> Date: Wed, 26 Jul 1995 09:53:28 +1000 Message-Id: <18205.806716408@ipx.office.bne.aone.net.au> From: George Michaelson Sorry.. maybe that last posting was a bit out of context. I think MBONE scaling has (at least) two dimensions. One is the back-end engineering of links and the protocol. The other is end-user behaviour. To the extent end-users are what they are (like me: dumb) clients on MBONE should maybe tread softly on the common sward. Whilst I have substantial sympathy with a deliberate decision not to hard code a management model into the apps, I think the utilitarian aspect of unconstrained tools needs *some* coding. Maybe quality needs to be a function of the number of participants? If Van proposes "greatest good" as a general MBONE goal, then things like ttl/b.w. and lpc for pt-to-pt equate to community-interest constraints on who gets to use high-visibility and high bandwidth access. -George From list-mgr@ISI.EDU Tue Jul 25 10:10:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 17:11:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 17:11:18 -0700 Received: from Csli.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 17:11:15 -0700 Received: from Csli.Stanford.EDU (localhost.Stanford.EDU [127.0.0.1]) by Csli.Stanford.EDU (8.6.11/8.6.11) with ESMTP id RAA16548; Tue, 25 Jul 1995 17:10:56 -0700 Message-Id: <199507260010.RAA16548@Csli.Stanford.EDU> To: George Michaelson Cc: Van Jacobson , whetten@icsi.berkeley.edu (Brian Whetten), mbone Subject: Re: How reliable is the mbone? In-Reply-To: Your message of Wed, 26 Jul 1995 09:53:28 +1000. <18205.806716408@ipx.office.bne.aone.net.au> Date: Tue, 25 Jul 1995 17:10:50 -0700 From: Christian Wettergren | If Van proposes "greatest good" as a general MBONE goal, then things like | ttl/b.w. and lpc for pt-to-pt equate to community-interest constraints | on who gets to use high-visibility and high bandwidth access. The downside of it is that certain events where you really want high- quality transmission will not be able to do that anymore. During the IETF someone pointed out to me that I really should differentiate the ttl's of different media, so that audio of session 1 reached the farthest and so on. This unfortunately meant that we could not use PCM for the audio anymore, since the ttl/bw logic "took over". I believe that the one thing people over the whole MBone cares about is the audio of the channel 1 in the IETF. :-) And since it is going over the smallest of links, it will suffer a lot of loss. PCM is a whole lot more resistant to loss than PCM2, so there is your tradeoff! I'm not seriously talking against ttl/bw policies, I'm just pointing out a little "twist" of it. I can tell you all that if everyone upgraded their mrouted to >3.4, audio would improve a lot. There is nowdays prioritization depending on the port-number in the mrouted. This was showing up clearly during the IETF when some sites in Finland reported <10% loss of audio, but as much as 80% loss in the video. This was due to an implicit rate limiting on some tunnels, which was subsequently fixed. But it was a good illustration that it really worked. One more note; I believe that if we start to "regulate" MBone too much, people will "avoid the regulations" by going unicast reflecting or setting up strange tunnels etc. This is unfortunate, but I believe that is what will happen. Maybe I'm just negative! :-) /Christian Wettergren cwe@it.kth.se KTH/Teleinformatics From list-mgr@ISI.EDU Wed Jul 26 20:29:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 17:30:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 17:30:16 -0700 Received: from mail.mel.aone.net.au by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 25 Jul 1995 17:30:14 -0700 Received: from ipx.office.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by mail.mel.aone.net.au (8.6.11/8.6.11) with ESMTP id KAA24443; Wed, 26 Jul 1995 10:30:09 +1000 Received: from ipx.office.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by ipx.office.bne.aone.net.au (8.6.11/8.6.12) with ESMTP id KAA18314; Wed, 26 Jul 1995 10:29:36 +1000 To: Christian Wettergren Cc: Van Jacobson , whetten@icsi.berkeley.edu (Brian Whetten), mbone Subject: Re: How reliable is the mbone? In-Reply-To: Your message of "Tue, 25 Jul 1995 17:10:50 MST." <199507260010.RAA16548@Csli.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <18308.806718575.1@ipx.office.bne.aone.net.au> Date: Wed, 26 Jul 1995 10:29:36 +1000 Message-Id: <18310.806718576@ipx.office.bne.aone.net.au> From: George Michaelson | ttl/b.w. and lpc for pt-to-pt equate to community-interest constraints | on who gets to use high-visibility and high bandwidth access. The downside of it is that certain events where you really want high- quality transmission will not be able to do that anymore. Not if the sender code modifies the b.w. constraint as a function of the number of receivers. Weighted voting as a modifier of more simple builtin settings perhaps. This would have other nice behaviours, ie people voting with their feet and not watching a source would tend to reduce its impact on the rest of the net. Only for well behaved apps of course, doesn't stop deliberate wreckers. During the IETF someone pointed out to me that I really should differentiate the ttl's of different media, so that audio of session 1 reached the farthest and so on. This unfortunately meant that we could not use PCM for the audio anymore, since the ttl/bw logic "took over". I think by default this is probably the right behaviour. Stuff like IETF should be able to exploit some kind of override to get a "better" share. Obviously if ttl exceeds threshold constraints that would have restricted flow to slow tunnels, not sending PCM is also highly desireable. Overloading ttl to serve many purposes probably isn't the way to go, but you could imagine "community benefit" being another numeric value that has set quantum points which influence emitted quality. I suspect layered coding and RTP/RSVP will address this problem better. One more note; I believe that if we start to "regulate" MBone too much, people will "avoid the regulations" by going unicast reflecting or setting up strange tunnels etc. This is unfortunate, but I believe that is what will happen. MBONE is not like any other IP. when somebody ftp's the entire X11R6 kit from the wrong place, the "horizon" of affected people is usually constrained to a single continent (!) where the offshore pipe is the scarce resource being clogged, but when somebody sends high-bitrate video of a black bear hiding in the coal pile, everyone suffers. The Craig Shergold effect on steroids. Maybe I'm just negative! :-) No, I think you're being realistic. -George From list-mgr@ISI.EDU Wed Jul 26 05:18:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Jul 1995 08:19:49 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Jul 1995 08:18:49 -0700 Received: from elvis.ecl.wustl.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Jul 1995 08:18:48 -0700 Received: by elvis.ecl.wustl.edu (5.x/ECL-A1.27) id AA03886; Wed, 26 Jul 1995 10:18:43 -0500 Date: Wed, 26 Jul 1995 10:18:43 -0500 From: sjp@ecl.wustl.edu (Steve Polityka) Message-Id: <9507261518.AA03886@elvis.ecl.wustl.edu> To: mbone Subject: assined address Our routers do source based filtering and we are trying to set them up to filter out certain conferences. In order to filter out conferneces we need to know how the conference's addresses are assigned. Does anyone know how the conferences get there address? Are they randomly assigned on the 224.xxx.xxx.xxx or is there a method for assigning these addresses when a conference is created on the mbone? Any help would be greatly appreciated. Thanks. Steve Polityka (sjp@ecl.wustl.edu) From list-mgr@ISI.EDU Wed Jul 26 04:20:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Jul 1995 11:20:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Jul 1995 11:20:20 -0700 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Jul 1995 11:20:19 -0700 Received: from icsib67.ICSI.Berkeley.EDU (whetten@icsib67.ICSI.Berkeley.EDU [128.32.201.167]) by icsia.ICSI.Berkeley.EDU (8.6.12/HUB+V8$Revision: 1.23 $) with ESMTP id LAA02473; Wed, 26 Jul 1995 11:20:14 -0700 Received: (whetten@localhost) by icsib67.ICSI.Berkeley.EDU (8.6.12/1.8) id LAA00472; Wed, 26 Jul 1995 11:20:06 -0700 Date: Wed, 26 Jul 1995 11:20:05 -0700 (PDT) From: Brian Whetten To: Jon Crowcroft Cc: mbone Subject: Re: How reliable is the mbone? In-Reply-To: <6659.806660859@cs.ucl.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks. Two things I wasn't necessarily clear on. 1) We are using a flow control/congestion control scheme that works very similarly to TCP/IP, but works for groups. 2) They need reliable transfer, in more or less real time...the real time aspect is less important than the reliability. Yes...this is exactly what I am trying to figure out...how stable is the service that MCI and Sprint are providing to the US in terms of multicast traffic. What is IMM? Thanks! Brian On Tue, 25 Jul 1995, Jon Crowcroft wrote: > > >How stable is the mbone at this time? Do the backbone routers all support > >pruning? Would sites connected via IP Multicast partition away from > >the rest of the net more often than if they are using IP? How much so? > >RMP can default to a unicast route for a site if the mbone connectivity > >to it is flaky, so we can handle some partitions and problems. > > Brian > > the mbone is as stable as your provider lets it be.... > (i.e. how long is a piece of string....) > > once, when there was an NSFNet you had one lot of people for academic > and research network provision (we still do in the UK...they provide a > "pilot service" mbone that is pretty robust, but still not embedded in > backbone routers due to lack of appropriate technology for scalable > backbone multicast routing with pruning...) > > now, the comercial providers in the US (and europe) give you what you > pay for - so i'm sure if you ask for multicast as part of the robust > service, they will cost it and provide it.... > > if you want to offer a steady IP traffic rate rather than elastic TCP like > behaviour (c.f. a 'discussion' on this list a few weeks back) > you may find some providers want to discuss this beforehand...as it > affects their backbone design decisions (and possibly router selection > criteria) > > btw, doesn't IMM do roughly what you are proposing? > > cheers > > jon > > From list-mgr@ISI.EDU Wed Jul 26 04:25:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Jul 1995 11:31:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Jul 1995 11:25:54 -0700 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Jul 1995 11:25:53 -0700 Received: from icsib67.ICSI.Berkeley.EDU (whetten@icsib67.ICSI.Berkeley.EDU [128.32.201.167]) by icsia.ICSI.Berkeley.EDU (8.6.12/HUB+V8$Revision: 1.23 $) with ESMTP id LAA02550; Wed, 26 Jul 1995 11:25:53 -0700 Received: (whetten@localhost) by icsib67.ICSI.Berkeley.EDU (8.6.12/1.8) id LAA00491; Wed, 26 Jul 1995 11:25:45 -0700 Date: Wed, 26 Jul 1995 11:25:44 -0700 (PDT) From: Brian Whetten To: Van Jacobson Cc: mbone Subject: Re: How reliable is the mbone? In-Reply-To: <199507252009.NAA02883@rx7.ee.lbl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thank you very much for your reply. We will get UCAR and the 100 universities they support to start talking to their providers. So, you expect to see the providers using hierarchical routing within the next year? Brian On Tue, 25 Jul 1995, Van Jacobson wrote: > I think you're asking the wrong questions Brian. The mbone has > 500kb/s of bandwidth, a hard limit enforced (at least at several > backbone sites) by rate limiting. There are currently over 2500 > nets attached to the mbone and, based on our traffic logs, about > 12,000 people routinely use it. Since the average `event' on > the mbone takes 40-150kb/s, it should be clear that the > bandwidth supply lags demand by a factor of over 1000 & users > cannot do as they please over the mbone. Currently we > accommodate the huge mismatch between supply & demand by a rough > concensus, manual, scheduling process that seems to be based on > a "greatest good for greatest number" principle plus encouraging > a wide diversity of use (as is appropriate for research facility > investigating a new communication modality). > > You are asking if some organization can use 1/4 of the available > bandwidth for it's own private purposes on a full time, production > basis. My reaction would be "No, that would destroy the concensus > process that makes the mbone work." (Have you ever heard the phrase > "tragedy of the commons"?) > > If you had asked the question "what has to happen for UCAR to be able > to distribute atmospheric data to universities via IP multicast over > the Internet?" a more useful answer is possible: > > 1. Hierarchical multicast has to get deployed. (Your question about > pruning was also off - the issue is not whether backbone hosts > support pruning but rather the consequences of some hosts not > supporting pruning (since you will never get everyone to upgrade). > Currently, if even one subnet per country doesn't support pruning > then all countries receive all multicast traffic. This will only > change when hierarchical multicast is deployed (hopefully later > this year). > > 2. The backbone providers (at least) have to have multicast support > in their routing infrastructure, not added on top via `tunnels'. > In the early days of the mbone, it was small enough, and the > people configuring tunnels were knowledgeable enough about the > physical topology, that the multicast scaling property of only > one packet per source packet per link was preserved. These days > random people are configuring tunnels with no thought at all for > the physical topology. And providers, pushed by the sudden interest > in the mbone, are hooking up customers much faster than they can > expand their infrastructure. The result is the average fanout on an > ISP mbone machine has gone from 4 to 15 and some crucial backbone > machines have fanouts of 20-30. This means that the incoming > traffic rate gets multiplied by a factor of 20-30 so, for example, > at some backbone sites the tunnel machine would have to send 15Mb/s > over its ethernet to handle the 500kb/s max mbone rate. The end > result is that everyone downstream of these underprovisioned nodes > sees a 40% drop rate. It's futile & absurd to ask ISPs to provision > separately for multicast & unicast (they can barely keep up with the > unicast demand) so the only solution here is native multicast > support. That happily also solves the problem of tunnel/topology > mismatch. > > Item 1 has to happen in the next few months or the mbone will collapse. > Bill Fenner & Steve Deering are working hard on it so the code will > probably happen in time. Most of the important players understand the > need so the deployment may also happen in time. > > Item 2 probably depends on how ISPs perceive the customer demand for > multicast (relative to all the other customer demands). The best > way to make it happen is to get UCAR and all its user community saying > "multicast is very important to us & our provider has to supply it > or we'll change providers". If you want UCAR to eventually use RMP for > distribution, that's the place to start. > > - Van > From list-mgr@ISI.EDU Thu Jul 27 18:17:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Jul 1995 18:20:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Jul 1995 18:17:49 -0700 Received: from nms.etri.re.kr by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 26 Jul 1995 18:16:56 -0700 Received: from hic.etri.re.kr by nms.etri.re.kr (4.1/NMS-0.1) id AA24713; Thu, 27 Jul 95 10:21:25 KDT Received: by hic.etri.re.kr (8.6.9H1/SMI-SVR4) id JAA22795; Thu, 27 Jul 1995 09:17:27 +0900 From: cjh@hic.etri.re.kr Message-Id: <199507270017.JAA22795@hic.etri.re.kr> Subject: subscribe me To: mbone Date: Thu, 27 Jul 1995 09:17:27 +0900 (KST) X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 296 Subscribe me -------------------------------------------------------------------------------- Choi JoonHyuk Broadband-ISDN Service Section E-Mail:cjh@mouth.etri.re.kr Phone :042-860-6770 http://mouth.etri.re.kr -------------------------------------------------------------------------------- From list-mgr@ISI.EDU Thu Jul 27 13:08:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 27 Jul 1995 04:10:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 27 Jul 1995 04:09:38 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 27 Jul 1995 04:09:36 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id ; Thu, 27 Jul 1995 04:09:21 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 12:08:35 +0100 To: Brian Whetten Cc: mbone Subject: Re: How reliable is the mbone? In-Reply-To: Your message of "Wed, 26 Jul 95 11:20:05 PDT." Date: Thu, 27 Jul 95 12:08:32 +0100 Message-Id: <7063.806843312@cs.ucl.ac.uk> From: Jon Crowcroft >1) We are using a flow control/congestion control scheme that works very >similarly to TCP/IP, but works for groups. >2) They need reliable transfer, in more or less real time...the real time >aspect is less important than the reliability. there is a tension between 1 and 2 - if you need a minimum time to dewliver a satellite immage, and it has a fixed size or quality, you have a minimum thruput... >Yes...this is exactly what I am trying to figure out...how stable is the >service that MCI and Sprint are providing to the US in terms of multicast >traffic. >What is IMM? IMM(1) USER COMMANDS IMM(1) NAME imm - Image Multicaster Client SYNOPSIS imm [ -p ] [ -i ] [ -N ] [ -ttl ] [ -n ] [ -a <files> ] [ -h ] DESCRIPTION Imm is a client program which receives multicasted images. It is designed to reassemble images multicasted as UDP pack- ets from the server program called immserv. Sucessfully received images are automatically loaded onto the root win- dow of the client host. If the environment variable DISPLAY is defined, Imm will attempt to load the image onto the defined display. Also, Imm has the capability to archive received files into a specified directory. If the environ- ment variable IMM_IMAGE_DIR is defined, files will be cached into the specified directory. OPTIONS -p <socket> Socket number to listen on to receive packets. -i <ip> Multicast or Internet address. -ttl <ttl> Time to live which ranges from 1 to 256. The ttl is used when Imm is configured to startup the immserve program. -n SD entry name passed to Imm. -N <MyHostName> The name you want everyone to know you by. -a <files> Number of files to archive. Imm automatically defaults to storing the last 2 received files in the directory /tmp. Older files are unlinked automatically. You can change the number of files cached by using this option. If file number specified is 0, then Imm will not unlink any files. -h Help display line. MANUAL DISPLAY OPTION By clicking on the middle left section of the main window (the transmission button), IMM will call xv or xli to display the last received image. Coupled with the archive option this function is useful for displaying images only on demand. Note that xv and xli take a few seconds to process Sun Release 4.0 Last change: 29 May 1993 1 IMM(1) USER COMMANDS IMM(1) the image before coming up. IMM OPTION window By clicking on the lower bar of the main window, an option window will appear. The Radio buttons alter the xv or xli system call to load the image such that it either fills the entire screen or tiles the screen with the image. The Win- dow option plays a dual role. It can either call a shell script called "imm2xv" or simply place the image into its own window. In order to used the shell script option, "imm2xv" must be created by the user and placed in his path. The shell scripts purpose is to allow the user the ability to manipulate the image file in any fashion he wants. If "imm2xv" is not found and the Window option is used, IMM will use xv to load an image into its own window. This is useful for people having colormap contention problems. The archive button bypasses the automatic image display. Image files are still received and maintained in /tmp. User can manually display the last image received by clicking on the main window transmission button. The dither or Smooth option are also xv and xli options which performs some extra post processing on the image. The DEBUG button if clicked will immediately start outputting debug information on the parent window. IMM Viewer window The viewer window shows all the stats collected from all clients and servers on the same session. It takes a few hours to receive data. The good field reflects the number of successfully received files. The bad field shows any incomplete abandoned files. Packets received are the total number of data packets received. Retries are the number of requested packets requested from the server pool. IMM Transmit window The transmit window provides an easy interface for users to transmit their own images. You simple create a directory entry which points to the images. Then click the start but- ton. You have the option to send either one or two pictures per hour. IMM Log window The Log window shows the last forty eight sucessfully received files by the receiving client. Each entry also shows who sent the file. IMM Myname window Your name is periodically broadcasted as your login name and your IP address. If you wish to be known by some other name, enter it in this window. Sun Release 4.0 Last change: 29 May 1993 2 IMM(1) USER COMMANDS IMM(1) NOTES Imm is designed to be called by SD written by Van Jacobson. BUGS While it is possible to be running many imm sessions simul- taneously, imm does not insure availability of resources. Also Imm does not regulate the number of colors used in the root window. SEE ALSO immserv AUTHOR Written by Winston Dang at the University of Hawaii. Sun Release 4.0 Last change: 29 May 1993 3 From list-mgr@ISI.EDU Thu Jul 27 13:48:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02651>; Thu, 27 Jul 1995 04:50:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02641>; Thu, 27 Jul 1995 04:49:51 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA02634>; Thu, 27 Jul 1995 04:49:48 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA27380>; Thu, 27 Jul 1995 04:49:22 -0700 Message-Id: <199507271149.AA27380@quark.isi.edu> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.25752-0@bells.cs.ucl.ac.uk>; Thu, 27 Jul 1995 12:48:59 +0100 To: mbone Subject: Asymmetric tunnels Date: Thu, 27 Jul 95 12:48:57 +0100 From: I.Wakeman@cs.ucl.ac.uk To show that there are a large number of assymetric tunnels around, we've decided to go for the public service announcement approach. The following pairs of hosts are assymetric, either in ttl threshold or metric (indicated by t or m) between them. Please, if you look after these tunnels and the metrics are wrong, sort them out. The information was collected by the mwatch programs, available by url at <http://www.cl.cam.ac.uk/mbone/index.html#Mrouted>. cheers ian + atanu Amsterdam.ripe.net t lea.cs.ucl.ac.uk [5/5][48/64] mbone.rus.uni-stuttgart.de t pluto.cs.ucl.ac.uk [1/1][32/16] obi.cc.miyazaki-u.ac.jp m nova.astro.miyazaki-u.ac.jp [2/3][1/1] thor.ece.uc.edu m cyhan.csm.uc.edu [1/2][64/64] broodjeham.surfnet.nl m mbone.rus.uni-stuttgart.de [5/1][48/48] 128.167.1.197 t mbone.sura.net [1/1][1/32] cdrn-sura9-c1.sura.net m mbone.sura.net [1/3][32/32] fibula.cic.net mt davros.acs.ohio-state.edu [2/1][64/32] 199.18.104.2 mt davros.acs.ohio-state.edu [3/1][64/0] se1-eth2-2.net.ohio-state.edu t davros.acs.ohio-state.edu [1/1][11/0] peggy.aads.net mt davros.acs.ohio-state.edu [2/1][32/64] 199.18.104.2 mt ernie.bgsu.edu [2/1][32/0] 199.18.104.2 mt kira.cc.uakron.edu [2/1][32/0] 199.18.104.2 mt sentry.wright.edu [2/1][32/0] 199.18.104.2 mt hobbes.mathsci.denison.edu [2/1][32/0] grid.arl.mil t les7.arl.mil [2/2][8/2] poly.arl.mil t les7.arl.mil [2/2][8/2] 204.235.71.2 m 204.235.65.2 [2/1][48/48] sphinx.cc.ic.ac.uk t noc.cam.ja.net [1/1][24/64] sura-mp2-pe.sura.net t 128.167.1.197 [1/1][32/1] stargate.ida.org t 128.167.1.197 [1/1][32/128] faraday.gmu.edu t noc.hpc.org [1/1][64/16] a-wing.jvnc.net t noc.hpc.org [1/1][64/32] picpus.polytechnique.fr t soleil.polytechnique.fr [1/1][32/1] electron-a.nasa.atd.net m copernicus.nrl.atd.net [4/1][1/1] butthead.atglab.bls.com t bstfirewall.atglab.bls.com [1/1][8/1] 139.133.210.26 t jal.cc.abdn.ac.uk [1/1][24/16] tipper.oit.unc.edu t camden.med.unc.edu [1/1][16/10] fuji.ethz.ch t mbone-transit.ethz.ch [1/1][1/16] clever.Germany.EU.net mt test-RS.ripe.net [1/3][64/1] broodjeham.surfnet.nl m ws-dus.dfn.de [1/5][48/48] broodjeham.surfnet.nl t mbone.cern.ch [1/1][64/48] directory.funet.fi t stockholm.mbone.ebone.net [1/1][40/32] patella.uni-c.dk t stockholm.mbone.ebone.net [1/1][40/32] fmroute1-1.exp.edf.fr t stockholm.mbone.ebone.net [4/4][64/48] qhepuc.oeaw.ac.at mt mbone.aco.net [1/3][32/1] 128.130.5.129 t mbone.aco.net [1/1][32/64] sintef-gw.sintef.no t lunde.runit.sintef.no [1/1][6/0] sarastro.nbi.dk t patella.uni-c.dk [1/1][16/32] noc.near.net mt MBONE.CIT.CORNELL.EDU [7/1][32/64] tipper.oit.unc.edu t mbone.ncren.net [1/1][32/10] mbone.merit.edu t a-wing.jvnc.net [1/1][32/64] 130.94.40.201 t a-wing.jvnc.net [1/1][64/0] scorpio.arc.nasa.gov t mbone2.nsi.nasa.gov [1/1][16/1] tahoe.arc.nasa.gov t mbone2.nsi.nasa.gov [1/1][16/1] 128.250.136.2 t borromini.arbld.unimelb.EDU.AU [1/1][1/4] baiame.sep.unimelb.EDU.AU t borromini.arbld.unimelb.EDU.AU [1/1][1/8] baiame.sep.unimelb.EDU.AU t 128.250.136.2 [1/1][4/8] wehib.wehi.edu.au t vitruvius.arbld.unimelb.EDU.AU [1/1][16/1] wtn-mp1-mae-east-pe.sura.net t 192.41.177.197 [1/1][32/1] appalachian.cc.gatech.edu t houdini-fddi.gatech.edu [1/1][8/4] 199.18.104.2 t ns1.sprintlink.net [1/1][64/0] zen.wustl.edu mt ns1.sprintlink.net [1/3][64/1] thinkpix.com t ns1.sprintlink.net [1/1][64/1] mbone.tamu.edu t ns1.sprintlink.net [1/1][64/255] natasha.InterNex.Net t ns1.sprintlink.net [1/1][64/32] 199.103.128.254 t ns1.sprintlink.net [1/1][64/0] nevis3.nevis.columbia.edu t 192.12.15.1 [1/1][32/1] mbone.gate.uni-erlangen.de t star.gate.uni-erlangen.de [1/1][24/32] janus.gw.utexas.edu t 128.83.7.251 [1/1][128/1] janus.gw.utexas.edu t mis.bus.utexas.edu [1/1][32/1] mbone.chalmers.se t cth-fddi-gw.chalmers.se [1/1][0/1] merkurius.lu.se t half.dna.lth.se [1/1][8/4] bowder.ncl.ac.uk t scoat.ncl.ac.uk [1/1][1/64] mbone.evitech.fi t nic.edu.fi [1/1][8/1] dwelly.natcorp.ox.ac.uk t orac.physics.ox.ac.uk [1/1][24/1] alcor.vc.cvut.cz t pklunx.cvut.cz [1/1][64/1] hp18.fzu.cz mt pklunx.cvut.cz [1/3][64/32] leporello.cs.unibo.it t astra.infn.it [1/1][24/128] dunet2.router.tudelft.nl t dutepp7.et.tudelft.nl [1/1][16/32] morgul.barrnet.net t mbone.nsi.nasa.gov [1/1][64/0] schwartz.lerc.nasa.gov mt mbone.lerc.nasa.gov [1/2][1/32] charybdis.ipac.caltech.edu t elxr-fddi.jpl.nasa.gov [1/1][48/16] corvette.jpl.nasa.gov t elxr-fddi.jpl.nasa.gov [1/1][8/1] monte.cscs.ch mt swiMA8.switch.ch [2/0][16/0] oncidium.cscs.ch mt swiMA8.switch.ch [2/0][16/0] tibia.cic.net t mbone.merit.edu [1/1][64/32] Clouso.CRIM.CA t atlantis.CC.McGill.CA [1/1][32/16] loon.Music.McGill.CA t atlantis.CC.McGill.CA [1/1][8/1] cisco-red.iss.nus.sg t venus.cc.nus.sg [1/1][1/0] sununx.iscs.nus.sg t venus.cc.nus.sg [1/1][4/16] rzsgi1.rz.uni-karlsruhe.de t mbone.nic.de [1/1][16/1] exxilon.xx.rmit.EDU.AU t aggedor.rmit.EDU.AU [1/1][16/32] wtn-mp1-pe.sura.net t trivia.CSS.GOV [1/1][1/32] 128.83.134.252 t janus.gw.utexas.edu [1/1][1/64] mbone.sunet.se t merkurius.lu.se [1/1][8/16] mbone.sunet.se t aquila.udac.uu.se [1/1][8/16] mbone.sunet.se t mbone.nada.kth.se [1/1][8/16] caligola.cselt.stet.it t iclsp20.cilea.it [1/1][16/1] news.spb.su t arch.kiae.su [1/1][5/4] aquarius.Relcom.EU.net t arch.kiae.su [1/1][3/1] expo.EXPO-RELCOM.msk.su t arch.kiae.su [1/1][2/1] mbone.sunet.se t hydra.sics.se [1/1][8/16] mbone.sunet.se t lower-gw.sunet.se [1/1][8/16] visitor1.larc.nasa.gov t ra-iris18.arc.nasa.gov [1/1][1/64] gauss.univ-mrs.fr m whisky.ens-lyon.fr [3/1][32/32] nintendo.enst-bretagne.fr mt matisse.univ-rennes1.fr [1/3][32/1] CVUT-gw.cvut.cz t ns.felk.cvut.cz [1/1][1/0] sun4.iihe.ac.be m sideral.rediris.es [1/4][48/48] corbu.cnrs-mrs.fr t gauss.univ-mrs.fr [1/1][16/32] jupiter.cc.nagasaki-u.ac.jp m study-rs.mech.nagasaki-u.ac.jp [2/1][5/5] solaris.cc.vt.edu t isb-ags.e6.cns.vt.edu [1/1][32/1] ns1.nysernet.net t startide.ctr.columbia.edu [1/1][32/64] tix-gw.tisn.ad.jp t ccut.cc.u-tokyo.ac.jp [1/1][1/4] sat.t.u-tokyo.ac.jp t 130.69.127.51 [1/1][1/64] indy.cc.it-hiroshima.ac.jp t saijo.csi.ad.jp [1/1][176/174] madoka.its.rpi.edu t ns1.nysernet.net [1/1][64/128] tix-gw.tisn.ad.jp t netsun.train.ad.jp [1/1][1/4] hibp7.ecse.rpi.edu t madoka.its.rpi.edu [1/1][2/1] cosmos.kaist.ac.kr t mindlle.cse.cau.ac.kr [3/3][1/16] cabal.Colorado.EDU m matisse.VIS.ColoState.EDU [2/1][32/32] jupiter.cc.nagasaki-u.ac.jp m nic.karrn.ad.jp [1/5][64/64] pero.sysa.csse.yamaguchi-u.ac.jp t nic.karrn.ad.jp [1/1][64/160] nakasu.csce.kyushu-u.ac.jp t starbow.cc.kyushu-u.ac.jp [1/1][1/4] Utumno.BARRNET.NET m matmos.hpl.hp.com [2/1][64/64] morgul.barrnet.net t 36.56.0.27 [1/1][32/0] Dragonlance.Stanford.EDU t 36.56.0.27 [2/2][16/32] Waimea.Stanford.EDU t 36.56.0.27 [2/2][16/32] tempest.Stanford.EDU t 36.56.0.27 [1/1][16/32] winona.Stanford.EDU t 36.56.0.27 [1/1][16/1] morgul.barrnet.net t Utumno.BARRNET.NET [1/1][32/0] 129.213.128.9 t Utumno.BARRNET.NET [1/1][32/1] morgul.barrnet.net t PLAYGROUND.SUN.COM [1/1][32/0] morgul.barrnet.net t Angband.BARRNET.NET [1/1][32/0] aki.csi.ad.jp t center2.ipc.hiroshima-cu.ac.jp [1/1][1/16] mbone.nps.navy.mil m usw.nps.navy.mil [2/1][1/1] houdini-atm.tioc.magic.net t mauchly.ukans.magic.net [1/1][48/1] ace.mid.net mt hobbes.ksu.ksu.edu [3/1][1/32] mbone.ucar.edu t nist-gw.ucar.edu [1/1][64/24] tempeh.sesqui.net t PAVLOV.SSCTR.BCM.TMC.EDU [1/1][1/64] brahms.sdsc.edu mt mbone-dmz.nosc.mil [1/2][64/32] eticket.llnl.gov t mbone.llnl.gov [1/1][8/2] realist.ca.sandia.gov m yar-con.ca.sandia.gov [1/5][1/1] defiant-bb.cs.odu.edu t galileo.cs.odu.edu [1/1][1/16] mb204.isi.edu mt mbone.isi.edu [1/0][32/0] noc.msc.net m ns2.sprintlink.net [1/3][64/64] ss20.mty.itesm.mx t ns2.sprintlink.net [1/1][64/128] enterprise.interpath.net m ns2.sprintlink.net [1/6][64/64] cleland.phyast.pitt.edu m oday-114.psc.edu [1/3][64/64] YERTLE.DCCS.UPENN.EDU t oday-114.psc.edu [1/1][64/2] caffeine.pa.dec.com t morgul.barrnet.net [1/1][0/32] cosmos.kaist.ac.kr t h2o.kotel.co.kr [1/1][32/16] oversteer.library.uwa.edu.au mt diablox.uwa.edu.au [1/3][8/1] gin.ee.umanitoba.ca t Clouso.CRIM.CA [1/1][32/64] 192.231.8.130 t tempeh.sesqui.net [1/1][64/1] sundiver.cnoc.imnet.ad.jp mt mbone.inoc.imnet.ad.jp [1/3][1/32] bonnou.kddlabs.co.jp t mbone.inoc.imnet.ad.jp [1/1][64/96] suzume.crl.go.jp m mbone.inoc.imnet.ad.jp [1/5][32/32] bandai.cc.kyushu-u.ac.jp t nakasu.csce.kyushu-u.ac.jp [1/1][1/16] dns2.anl.gov t benedick.ctd.anl.gov [1/1][16/32] mb160.isi.edu mt dom.isi.edu [1/0][1/0] MBONE-2.MIT.EDU t X.media.mit.edu [1/1][1/8] MBONE3.UU.NET m nb-gw.rutgers.edu [1/3][64/64] bandai.cc.kyushu-u.ac.jp t sakimori.cc.kyushu-u.ac.jp [1/1][1/16] ccmng.riken.go.jp t jupiter.riken.go.jp [1/1][1/16] defiant-bb.cs.odu.edu t pong.cs.odu.edu [1/1][1/16] defiant-bb.cs.odu.edu t brahma.cs.odu.edu [1/1][1/16] tron.nts.uci.edu m mbone-cerfnet.sdsc.edu [1/8][32/32] utorgw.gw.utoronto.ca t mbone.on.canet.ca [1/1][1/32] tomcat.center.osakafu-u.ac.jp t cconyx01.center.osaka-u.ac.jp [1/1][96/128] biyo.csce.kyushu-u.ac.jp m bandai.cc.kyushu-u.ac.jp [1/3][4/4] elm.netcom.ubc.ca t netman.cs.ubc.ca [1/1][1/16] acrux.astro.indiana.edu t cisco-mbone.ucs.indiana.edu [1/1][1/64] mbone.sunet.se t gaston.telematik.su.se [1/1][8/16] jocosus.matematik.su.se mt gaston.telematik.su.se [1/3][8/1] stisun2-f1.epfl.ch t liasg5.epfl.ch [1/1][1/16] stacer.eecs.ukans.edu mt curie.eecs.ukans.edu [2/1][10/1] davis.cecer.army.mil t dcl2.gw.uiuc.edu [1/1][64/32] jeeves.ncsa.uiuc.edu t dcl2.gw.uiuc.edu [1/1][16/1] elm.netcom.ubc.ca m mbone-seattle.nwnet.net [3/1][64/64] hubsrv.alaska.edu t mbone-seattle.nwnet.net [1/1][32/45] klaatu.fhcrc.org mt mbone-seattle.nwnet.net [1/3][32/1] gateway.ora.dnd.ca t rtr.ndhq.dnd.ca [1/1][1/16] fibula.cic.net m rossi.astro.nwu.edu [3/1][32/32] 199.18.104.2 mt dune.mcs.kent.edu [2/1][32/0] 164.67.3.1 t sequel.humnet.ucla.edu [1/1][4/32] gateway.gtech.com t noc.near.net [1/1][192/64] tiananmen.cc.nd.edu t fibula.cic.net [1/1][32/1] tdraffic.gw.psu.edu t fibula.cic.net [1/1][32/64] tron.nts.uci.edu mt john-bigboote.ics.uci.edu [1/2][1/8] ss20.mty.itesm.mx mt agave.staff.udg.mx [10/1][1/64] paris-e0.ucla.edu m tron.nts.uci.edu [8/1][64/64] draco.acs.uci.edu mt tron.nts.uci.edu [2/1][8/1] bossanova.ics.uci.edu mt tron.nts.uci.edu [2/1][8/1] isengard.barrnet.net t mbone.Berkeley.EDU [1/1][64/32] mroute.winona.msus.edu mt Riverside.MR.Net [3/1][32/1] infectious.micro.umn.edu mt noc.msc.net [1/3][64/1] softserv.solsource.net m sl-ana-3-S3/3-384k.sprintlink.net [1/0][0/0] 128.8.15.1 t spiderman.umbc.edu [1/1][24/0] MBONE1.UU.NET t neteye.thepoint.com [1/1][1/64] bob.EECS.Berkeley.EDU t inr-181.Berkeley.EDU [1/1][0/4] aldebaran.EECS.Berkeley.EDU t inr-181.Berkeley.EDU [1/1][0/1] navis-1.ie.org t MBONE1.UU.NET [1/1][64/32] sauce.uio.no mt leto.uio.no [3/1][1/3] sura-mp2-pe.sura.net t 129.2.250.1 [1/1][0/32] 199.18.104.2 mt ostermann.cs.ohiou.edu [3/1][64/0] ewa.mat.uni.torun.pl t mg.cyf-kr.edu.pl [1/1][40/32] mbone.sunet.se t mit-gw.umu.se [1/1][8/16] 192.156.226.1 t igi.prep.net [1/1][1/64] gateway.crad.dnd.ca t 128.43.253.45 [1/1][100/16] 133.5.17.201 m biyo.csce.kyushu-u.ac.jp [2/1][2/2] korosuke.ec.kyushu-u.ac.jp m biyo.csce.kyushu-u.ac.jp [2/1][2/2] boo.cc.columbia.edu t 128.59.247.1 [1/1][0/64] From list-mgr@ISI.EDU Thu Jul 27 07:34:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07284>; Thu, 27 Jul 1995 08:36:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07267>; Thu, 27 Jul 1995 08:36:25 -0700 Received: from prom.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA07260>; Thu, 27 Jul 1995 08:36:24 -0700 Received: (dschluss@localhost) by prom.engin.umich.edu (8.6.12/8.6.4) id LAA04322; Thu, 27 Jul 1995 11:36:04 -0400 Date: Thu, 27 Jul 1995 11:34:54 -0400 (EDT) From: "david a. schlussel" <dschluss@engin.umich.edu> Subject: Re: [Help] Cannot here VAT sound on CU-SeeMe thru Reflector To: Jung Joowon <jwjung@camis.kaist.ac.kr> Cc: mbone In-Reply-To: <199507220757.QAA04138@camis.kaist.ac.kr> Message-Id: <Pine.3.87.9507271154.E4160-0100000@prom.engin.umich.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You need a NV-UC-PORT and an VAT-UC-PORT, cu-seeme is unicast (UC) not multicast (MC) +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ On Sat, 22 Jul 1995, Jung Joowon wrote: > > Hello... > > I installed ipmulti-3.5 on SunOS 4.1.3, sd, vat, nv. And I have tested > sd and vat with those of Solaris 2.3, and they works well. > > I installed CU-SeeMe reflector 3.0b2 on both SunOS 4.1.3 and Solaris 2.3, > and installed CU-SeeMe 0.65b2 on sevral PC's which have Sound Blaster 16 > card & driver. > (SunOS, Solaris, PC's are on the same subnet.) > > When I start reflector with no configuration file, every CU-SeeMe PC clients > recognized each other. > > I wrote reflect.conf as follows to receive VAT sound by CU-SeeMe. > > VAT-MC-PORT 35199 > VAT-MC-IN 224.2.159.236 > VAT-MC-OUT 32 224.2.159.236 > VAT-CONF-ID 58907 > > Each number was obtained from sd by creating an audio session. > > I executed reflect, vat, and CU-SeeMe. Of course, I connected CU-SeeMe to > the reflect and turned on receive audio option on CU-SeeMe. > > But... I cannot hear any sound from CU-SeeMe client. > I checked VAT's operation by hearing sound from another VAT. > CU-SeeMe reflector sends its PC clients info to VAT. > (I can see the entry names on paticipants list of VAT.) > But... I cannot hear the sound on my PC. > > Where do I wrong? > > Thanks in advance... > > -Jung Joowon > > P.S: reflect 4.0b1 crashes(Segmentaton fault) when VAT starts to send audio. > > From list-mgr@ISI.EDU Thu Jul 27 19:49:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16704>; Thu, 27 Jul 1995 11:49:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16689>; Thu, 27 Jul 1995 11:49:22 -0700 Received: from tigger.read.tasc.com by venera.isi.edu (5.65c/5.61+local-22) id <AA16681>; Thu, 27 Jul 1995 11:49:20 -0700 Received: by tigger.Read.TASC.COM (5.0/TASC-NONDOM-1.7) id AA07791; Thu, 27 Jul 1995 14:49:42 +0500 Date: Thu, 27 Jul 1995 14:49:42 +0500 From: wgsmith@tigger.Read.TASC.COM (W. Garth Smith) Message-Id: <9507271849.AA07791@tigger.Read.TASC.COM> To: mbone Subject: mrouted slow performance Cc: akoifman@tasc.com, wgsmith@tasc.com X-Sun-Charset: US-ASCII Content-Length: 1556 mbone community: We are attempting to use the multicast tunneling software (mrouted) to tunnel UDP multicast packets accross a WAN. We see significant time delays over say a traditional point to point communication among these two sites. What performance degredation should one see when using this software. I notice the FAQ does not seem to address performance issues. Is the threshold parameter where we adjust timing performance? We are using the mrouted software on an IRIX5.2 SGI Indigo2. We essentially are trying to do realtime simulations over a WAN. We currently see a latencey of 80 millisenconds one way with the UNIX ping utility. We need to be around 100 millisenconds as a upper bound. How much additional delay would be encountered by using a tunnel? The tunnel seems to incure on the order of several seconds of additional delay on packet transmission. Garth ____________________________________________________________________________ W. Garth Smith _/_/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/_/ TASC _/ _/ _/ _/ _/ _/ _/ 55 Walkers Brook Drive _/ _/ _/ _/ _/ Reading, MA 01867-3297 _/ _/_/_/_/ _/_/_/_/ _/ voice: 617-942-2000 (ext. 2417) _/ _/ _/ _/ _/ fax: 617-942-7100 _/ _/ _/ _/ _/ _/ _/ email: wgsmith@tasc.com _/ _/ _/ _/_/_/_/ _/_/_/_/ ____________________________________________________________________________ From list-mgr@ISI.EDU Thu Jul 27 18:07:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22823>; Fri, 28 Jul 1995 01:13:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22764>; Fri, 28 Jul 1995 01:08:40 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-22) id <AA22757>; Fri, 28 Jul 1995 01:08:38 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA00969; Fri, 28 Jul 95 01:07:45 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9507280807.AA00969@taurus.cs.nps.navy.mil> Subject: MBone tunnel request for SIGGRAPH LA To: mbone (Multicast Backbone mail list) Date: Fri, 28 Jul 1995 01:07:44 -0700 (PDT) Cc: graphicsnet@siggraph.org (GraphicsNet mail list), coco@siggraph.org (Coco Conn), pax@ankh.metrolink.com (Garry Paxinos), tlemswil@nps.navy.mil (Tracey L Emswiler), rjbigelo@nps.navy.mil (Jon Bigelow), carl@radio.com (Carl Malamud), bacon@cs.nps.navy.mil (Dan Bacon) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2444 We'd like to make a request for an MBone tunnel in Los Angeles for SIGGRAPH, the ACM Special Interest Group on Graphics. Dates are August 5-11 (Saturday-Friday). Upstream IP number of our mrouter will be 156.153.98.137 Our physical location is the LA Convention Center. Long-haul links are being provided by Sprint via PacBell. Domain name is .s95.siggraph.org with (probable) hostname router137.s95.siggraph.org Second issue of interest to this list: today's announcement of an imminent shuttle launch puts a serious crimp in our plans to provide content. Our multicast schedule has two tracks: papers/panels and "MBone Unplugged." Papers/panels will present technical sessions. Our unplugged session will use a cart equipped with Indy, wireless bridge, wireless mics, paired cameras and uninterruptible power supply. This is a mobile studio that brings the TV station to the programs. Our goal is to give all Interactive Communities exhibitors 30-60 minutes of multicast time on "KSIG-TV" all week. So where is the technical issue? If feasible we might try setting up some special tunnels via ATM to circumvent limits on global MBone bandwidth driven by overloaded links. Perhaps some ATM links might be arranged to remote sites which would then relay the feed at reduced ttl to their region. I have no idea if this is feasible for transoceanic links. Nevertheless some careful experimentation might be very interesting. I've heard several prominent people discuss this possibility, here is an opportunity to try it. We will likely learn something even if we are constrained to North America. Comments are welcome. As thanks for working with us on a Saturday afternoon to set up a tunnel, I will work on getting 2 free floor admission passes to the conference. Expected attendance is about 25,000. A particular feature of interest is GraphicsNet, a combination of ATM FDDI and Ethernet networks. One of the main exhibit themes is Interactive Communities, sixty works demonstrating networked collaboration using computer graphics. Info: http://www.siggraph.org/conferences/siggraph95/GraphicsNet/ http://www.siggraph.org/conferences/siggraph95/siggraph95.html all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA [Root 200] fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv_uvw.html From list-mgr@ISI.EDU Thu Jul 27 18:29:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23457>; Fri, 28 Jul 1995 01:38:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23300>; Fri, 28 Jul 1995 01:33:59 -0700 Received: from sand.net by venera.isi.edu (5.65c/5.61+local-22) id <AA23293>; Fri, 28 Jul 1995 01:33:56 -0700 Received: by Sand.Net (4.1/4.7) id AA23794; Fri, 28 Jul 95 01:29:06 PDT Date: Fri, 28 Jul 1995 01:29:05 -0700 (PDT) From: Tom Hutton <hutton@sdslug.org> Subject: Re: MBone tunnel request for SIGGRAPH LA To: Don Brutzman <brutzman@cs.nps.navy.mil> Cc: Multicast Backbone mail list <mbone>, GraphicsNet mail list <graphicsnet@siggraph.org>, Coco Conn <coco@siggraph.org>, Garry Paxinos <pax@ankh.metrolink.com>, Tracey L Emswiler <tlemswil@nps.navy.mil>, Jon Bigelow <rjbigelo@nps.navy.mil>, Carl Malamud <carl@radio.com>, Dan Bacon <bacon@cs.nps.navy.mil> In-Reply-To: <9507280807.AA00969@taurus.cs.nps.navy.mil> Message-Id: <Pine.3.89.9507280146.K22979-0100000@hot> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Isnt our internet connection via ANS? (not sprint pacbell) If so, we should look for an ANS customer to be our mbone feed. Just being on the west coast might not be the best thing if the data has to travel to the NewYork NAP and back. Tom On Fri, 28 Jul 1995, Don Brutzman wrote: > We'd like to make a request for an MBone tunnel in Los Angeles for > SIGGRAPH, the ACM Special Interest Group on Graphics. Dates are > August 5-11 (Saturday-Friday). Upstream IP number of our mrouter > will be 156.153.98.137 > > Our physical location is the LA Convention Center. Long-haul links > are being provided by Sprint via PacBell. Domain name is .s95.siggraph.org > with (probable) hostname router137.s95.siggraph.org > > Second issue of interest to this list: today's announcement of an > imminent shuttle launch puts a serious crimp in our plans to provide > content. Our multicast schedule has two tracks: papers/panels and > "MBone Unplugged." Papers/panels will present technical sessions. > Our unplugged session will use a cart equipped with Indy, wireless > bridge, wireless mics, paired cameras and uninterruptible power > supply. This is a mobile studio that brings the TV station to the > programs. Our goal is to give all Interactive Communities exhibitors > 30-60 minutes of multicast time on "KSIG-TV" all week. > > So where is the technical issue? If feasible we might try setting up > some special tunnels via ATM to circumvent limits on global MBone > bandwidth driven by overloaded links. Perhaps some ATM links might be > arranged to remote sites which would then relay the feed at reduced > ttl to their region. I have no idea if this is feasible for > transoceanic links. Nevertheless some careful experimentation might > be very interesting. I've heard several prominent people discuss this > possibility, here is an opportunity to try it. We will likely learn > something even if we are constrained to North America. Comments are > welcome. > > As thanks for working with us on a Saturday afternoon to set up a > tunnel, I will work on getting 2 free floor admission passes to the conference. > Expected attendance is about 25,000. A particular feature of interest > is GraphicsNet, a combination of ATM FDDI and Ethernet networks. > One of the main exhibit themes is Interactive Communities, sixty works > demonstrating networked collaboration using computer graphics. Info: > http://www.siggraph.org/conferences/siggraph95/GraphicsNet/ > http://www.siggraph.org/conferences/siggraph95/siggraph95.html > > all the best, Don > -- > Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 > Monterey California 93943-5000 USA [Root 200] fax 408.656.3679 > AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv_uvw.html > =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Thomas E. Hutton (hutton@sdslug.org) Voice: 01-619-534-5136 San Diego SUN Local Users Group Fax: 01-619-534-5152 7919 Silverton Ave; Suite 414 San Diego, CA 92126 ...Lead us not into temptation, We can find it ourselves. =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= From list-mgr@ISI.EDU Fri Jul 28 10:39:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26229>; Fri, 28 Jul 1995 17:54:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25026>; Fri, 28 Jul 1995 17:38:59 -0700 Received: from mercury.Sun.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA25019>; Fri, 28 Jul 1995 17:38:58 -0700 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id RAA20790; Fri, 28 Jul 1995 17:38:40 -0700 Received: from jurassic.Eng.Sun.COM (jurassic-52.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14597; Fri, 28 Jul 1995 17:38:36 -0700 Received: from offshore.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id RAA19592; Fri, 28 Jul 1995 17:38:22 -0700 Received: by offshore.Eng.Sun.COM (5.x/SMI-SVR4) id AA18516; Fri, 28 Jul 1995 17:39:45 -0700 Date: Fri, 28 Jul 1995 17:39:45 -0700 From: Allyn.Romanow@Eng.Sun.COM (Allyn Romanow) Message-Id: <9507290039.AA18516@offshore.Eng.Sun.COM> To: sifu@ecl.wustl.edu, fenner@parc.xerox.com Subject: Re: Problems compiling mrouted3.5 on Solaris 2.4 Cc: mbone X-Sun-Charset: US-ASCII There's a confusion here- the patch you mentioned is for Solaris 2.3, no patch is needed for Solaris 2.4. There's a README in the directory and installation instructions. > From fenner@parc.xerox.com Tue Jul 18 13:43:41 1995 > To: sifu@ecl.wustl.edu (Ben Regen) > Cc: mbone@ISI.EDU > Subject: Re: Problems compiling mrouted3.5 on Solaris 2.4 > Date: Tue, 18 Jul 1995 13:30:49 PDT > Sender: Bill Fenner <fenner@parc.xerox.com> > From: Bill Fenner <fenner@parc.xerox.com> > Content-Length: 575 > X-Lines: 15 > > In message <9507171613.AA05896@ecl.wustl.edu> you write: > >When compiling mrouted3.5 on Solaris 2.4, we are having problems with > >undefined symbols. > > mrouted 2.2 is the latest you can run on "stock" Solaris 2.4 . > > You can get mrouted 3.4 for Solaris from playground.sun.com in > /pub/multicast/Solaris_mc33.2.4.tar.Z ; this includes kernel patches > and mrouted. > > You may or may not also need /pub/multicast/patches/101969-06.tar; > I don't know if that patch is included in the other tar file. Just > to be safe, add the patch first, and then install Solaris_mc33.2.4.tar . > > Bill > From list-mgr@ISI.EDU Fri Jul 28 19:43:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01532>; Fri, 28 Jul 1995 20:49:27 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01305>; Fri, 28 Jul 1995 20:40:37 -0700 Received: from fore.com (relay.fore.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA01298>; Fri, 28 Jul 1995 20:40:36 -0700 Received: from dolphin (dolphin.fore.com [169.144.1.16]) by fore.com (8.6.11/8.6.11) with SMTP id XAA24747; Fri, 28 Jul 1995 23:40:20 -0400 Received: from shell.fore.com by dolphin (4.1/SMI-4.1) id AA18396; Fri, 28 Jul 95 23:40:27 EDT Received: from by shell.fore.com (4.1/SMI-4.1) id AB22292; Fri, 28 Jul 95 23:39:40 EDT X-Sender: marke@pophost.fore.com Message-Id: <v02120c06ac3f31800e2e@[198.29.30.61]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Jul 1995 23:43:07 -0400 To: Tom Hutton <hutton@sdslug.org>, Don Brutzman <brutzman@cs.nps.navy.mil> From: marke@fore.com (Marke Clinger) Subject: Re: MBone tunnel request for SIGGRAPH LA Cc: Multicast Backbone mail list <mbone>, GraphicsNet mail list <graphicsnet@siggraph.org>, Coco Conn <coco@siggraph.org>, Garry Paxinos <pax@ankh.metrolink.com>, Tracey L Emswiler <tlemswil@nps.navy.mil>, Jon Bigelow <rjbigelo@nps.navy.mil>, Carl Malamud <carl@radio.com>, Dan Bacon <bacon@cs.nps.navy.mil> At 4:29 AM 7/28/95, Tom Hutton wrote: >Isnt our internet connection via ANS? (not sprint pacbell) If so, we >should look for an ANS customer to be our mbone feed. Just being on the >west coast might not be the best thing if the data has to travel to the >NewYork NAP and back. We now have a confirmed DS-3 path from LACC to ANS. This has been a problem for the last several weeks, but it is a done deal now. So yes. We are using ANS. If you have questions of ANS please contact Peter Haddad at haddad@hpl.hp.com. Peter is handling the Internet connection. He is currently staying at the Omni in Los Angeles, so you can reach him there also. Marke From list-mgr@ISI.EDU Mon Jul 31 20:55:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01225>; Sun, 30 Jul 1995 19:56:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01215>; Sun, 30 Jul 1995 19:55:29 -0700 Received: from poppy.ipc.hiroshima-u.ac.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA01208>; Sun, 30 Jul 1995 19:55:18 -0700 Received: from localhost by poppy.ipc.hiroshima-u.ac.jp (5.x/2.8Wb) id AA17712; Mon, 31 Jul 1995 11:55:12 +0900 Return-Path: <kouji@poppy.ipc.hiroshima-u.ac.jp> Message-Id: <9507310255.AA17712@poppy.ipc.hiroshima-u.ac.jp> To: mbone Subject: Re: Announcement of HIROSHIMA-LIVE(Aug.6) From: Kouji Nishimura <kouji@hiroshima-u.ac.jp> In-Reply-To: Your message of "Sat, 15 Jul 1995 18:08:59 JST" References: <9507150909.AA06908@poppy.ipc.hiroshima-u.ac.jp> Date: Mon, 31 Jul 1995 11:55:11 +0900 Sender: kouji@poppy.ipc.hiroshima-u.ac.jp Hi all, We had decided the last language to broadcast the 50th Hiroshima Peace Memorial Ceremony on August 6. The last language is Polish. And we want to change the transmission rate of the video to 64kbps. Please let us know, if there is any problem. Session (with TTL=127) Video (nv,64kbps) from Hiroshima Peace Memorial Park Audio (dvi4,32kbps*5) narrations are provided in five languages, English, French, Spanish, German and Polish Character (wb) circumstances, the Peace Declaration, etc. (English) Time-Table Live - The 50th Hiroshima Peace Memorial Ceremony (30 min.) from Aug. 6 08:00 JST (Aug. 5 23:00 UTC) Rebroadcast (30 min. each) from Aug. 6 10:00 JST (Aug. 6 01:00 UTC) from Aug. 6 12:00 JST (Aug. 6 03:00 UTC) from Aug. 6 14:00 JST (Aug. 6 05:00 UTC) from Aug. 6 16:00 JST (Aug. 6 07:00 UTC) from Aug. 6 18:00 JST (Aug. 6 09:00 UTC) See http://www.csi.ad.jp/hiroshima-live/ for further information (updated). Any questions and comments should go to "86live@csi.ad.jp". Thank you HIROSHIMA-LIVE Project Kouji Nishimura (kouji@hiroshima-u.ac.jp) Chugoku-Shikoku Internet Council From list-mgr@ISI.EDU Mon Jul 31 16:58:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13057>; Mon, 31 Jul 1995 06:02:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13041>; Mon, 31 Jul 1995 06:01:30 -0700 Received: from sanson.dit.upm.es (sanson-gw.dit.upm.es) by venera.isi.edu (5.65c/5.61+local-22) id <AA13030>; Mon, 31 Jul 1995 06:01:23 -0700 Received: from isabel.dit.upm.es (isabel.dit.upm.es [138.4.22.1]) by sanson.dit.upm.es (8.6.12/3.02) with ESMTP id PAA14540 for <mbone@ISI.EDU>; Mon, 31 Jul 1995 15:01:15 +0200 Received: (azcorra@localhost) by isabel.dit.upm.es (8.6.10/3.02) id OAA26875; Mon, 31 Jul 1995 14:58:51 +0200 Date: Mon, 31 Jul 1995 14:58:51 +0200 From: Arturo Azcorra <azcorra@dit.upm.es> Message-Id: <199507311258.OAA26875@isabel.dit.upm.es> To: mbone Subject: unsubscribe From list-mgr@ISI.EDU Tue Aug 1 10:39:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02391>; Mon, 31 Jul 1995 23:42:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02364>; Mon, 31 Jul 1995 23:41:51 -0700 Received: from sanson.dit.upm.es (sanson-gw.dit.upm.es) by venera.isi.edu (5.65c/5.61+local-22) id <AA02357>; Mon, 31 Jul 1995 23:41:47 -0700 Received: from isabel.dit.upm.es (isabel.dit.upm.es [138.4.22.1]) by sanson.dit.upm.es (8.6.12/3.02) with ESMTP id IAA00955 for <mbone@ISI.EDU>; Tue, 1 Aug 1995 08:41:44 +0200 Received: (azcorra@localhost) by isabel.dit.upm.es (8.6.10/3.02) id IAA27236; Tue, 1 Aug 1995 08:39:19 +0200 Date: Tue, 1 Aug 1995 08:39:19 +0200 From: Arturo Azcorra <azcorra@dit.upm.es> Message-Id: <199508010639.IAA27236@isabel.dit.upm.es> To: mbone Subject: unsubscribe Please, unsubscribe. From list-mgr@ISI.EDU Tue Aug 1 05:09:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02303>; Tue, 1 Aug 1995 12:15:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02063>; Tue, 1 Aug 1995 12:10:11 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-22) id <AA02056>; Tue, 1 Aug 1995 12:10:10 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA04082; Tue, 1 Aug 95 12:09:18 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9508011909.AA04082@taurus.cs.nps.navy.mil> Subject: Re: MBone tunnel request for SIGGRAPH LA (fwd) To: mbone (Multicast Backbone mail list) Date: Tue, 1 Aug 1995 12:09:17 -0700 (PDT) Cc: haddad@hpl.hp.com (Peter Haddad), pax@ankh.metrolink.com (Garry Paxinos), coco@siggraph.org (Coco Conn), bacon@cs.nps.navy.mil (Dan Bacon), tlemswil@nps.navy.mil (Tracey L Emswiler), rjbigelo@nps.navy.mil (Jon Bigelow), graphicsnet@siggraph.org (GraphicsNet mail list) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1707 Returning to our original request: We need a tunnel to SIGGRAPH GraphicsNet this Saturday 5 August through Friday 11 August late afternoon. Available information on our connection and topology follows: R. Peter Haddad writes: > From haddad@flame.hpl.hp.com Mon Jul 31 23:34:57 1995 > > ANS will not be able to provide us with an mbone tunnel. What is the > next step ? I'm getting hammered installing the physical network > infrastructure for the show and have limited time to work on this. > The no-brainer tunnel for me is BARRNet, but I don't know if that > makes sense based upon ANS's connectivity. I believe that they have > T1 connectivity to the CIX, providing access to barrnet so performance > shouldn't be horrible. However, the last conversation I had with > Vince Fuller(now of BBN) led me to believe that their mbone router > was pretty congested, but it might have been replaced with a 7000 > by now. Let me know how you'd like to proceed. Peter also tells me that ANS is connected through the Dominguez Hills POP in LA. Can someone in that area please provide a connection, or at least some suggestions regarding what sites are good candidates to work with. Since this is short term effort and since we are the main MBone content providers that week, a "good enough" solution is better than waiting further for an optimal solution. Thanks in advance. all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA [Root 200] fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv_uvw.html From list-mgr@ISI.EDU Tue Aug 1 05:26:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02842>; Tue, 1 Aug 1995 12:26:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02820>; Tue, 1 Aug 1995 12:26:09 -0700 Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA02813>; Tue, 1 Aug 1995 12:26:08 -0700 Received: by precept.com (5.x/SMI-4.1) id AA09843; Tue, 1 Aug 1995 12:26:07 -0700 Date: Tue, 1 Aug 1995 12:26:06 -0700 (PDT) From: Stephen Casner <casner@precept.com> To: mbone Subject: vat list from Stockholm IETF Message-Id: <Pine.SOL.3.91.950801121700.9183D-100000@hydra.precept.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII For each of the IETF multicasts so far, I have produced a list of the remote participants by running "vat -k" to keep all the participant names. Then I use the "l" (list) command in vat to output the list of names, and then post-process it into the list format. Since our MBone connection is not up yet at Precept Software, I could not run the "accumulator vat" for the recent Stockholm IETF. My backup at another site didn't pan out because the machine was shut down unexpectedly. I realize this is a long shot, but did anyone else run "vat -k" and then collect the participant list? -- Steve From list-mgr@ISI.EDU Tue Aug 1 05:47:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03831>; Tue, 1 Aug 1995 12:52:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03707>; Tue, 1 Aug 1995 12:47:28 -0700 Received: from Csli.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA03700>; Tue, 1 Aug 1995 12:47:27 -0700 Received: from Csli.Stanford.EDU (localhost.Stanford.EDU [127.0.0.1]) by Csli.Stanford.EDU (8.6.11/8.6.11) with ESMTP id MAA26899; Tue, 1 Aug 1995 12:47:21 -0700 Message-Id: <199508011947.MAA26899@Csli.Stanford.EDU> To: Stephen Casner <casner@precept.com> Cc: mbone Subject: Re: vat list from Stockholm IETF In-Reply-To: Your message of Tue, 01 Aug 1995 12:26:06 PDT. <Pine.SOL.3.91.950801121700.9183D-100000@hydra.precept.com> Date: Tue, 01 Aug 1995 12:47:19 -0700 From: Christian Wettergren <cwe@Csli.Stanford.EDU> | I realize this is a long shot, but did anyone else run "vat -k" and | then collect the participant list? Unfortunately, we in Stockholm didn't think of it in time, I realized I'd like to keep the stats two days into the conference, when I already had had to restart the vat several times. I believe we reached something about 350 participants per session during the rest of the week though. I believe Bill said something about him having the list. Do you Bill? /Christian From list-mgr@ISI.EDU Tue Aug 1 11:55:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04250>; Tue, 1 Aug 1995 13:01:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04231>; Tue, 1 Aug 1995 13:00:57 -0700 Received: from 3sixty.voyagerco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA04224>; Tue, 1 Aug 1995 13:00:56 -0700 Received: from voyagerco.com by 3sixty.voyagerco.com; Tue, 1 Aug 95 16:00 EST X-Sender: kaufman@3sixty.voyagerco.com Message-Id: <v02110100ac4437057e37@[204.97.9.85]> Mime-Version: 1.0 Content-Length: 107 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Aug 1995 15:55:15 -0400 To: mbone From: kaufman@voyagerco.com (Trevor Kaufman) Subject: unsubscribe unsubscribe **I know people who do this are idiots, but I can't find the right address to send this to. From list-mgr@ISI.EDU Tue Aug 1 14:35:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23501>; Tue, 1 Aug 1995 21:37:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23482>; Tue, 1 Aug 1995 21:36:02 -0700 Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA23475>; Tue, 1 Aug 1995 21:36:01 -0700 Received: by precept.com (5.x/SMI-4.1) id AA12474; Tue, 1 Aug 1995 21:35:49 -0700 Date: Tue, 1 Aug 1995 21:35:49 -0700 (PDT) From: Stephen Casner <casner@precept.com> To: Trevor Kaufman <kaufman@voyagerco.com>, Arturo Azcorra <azcorra@dit.upm.es> Cc: mbone Subject: Re: unsubscribe In-Reply-To: <v02110100ac4437057e37@[204.97.9.85]> Message-Id: <Pine.SOL.3.91.950801213052.12339C-100000@hydra.precept.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Aug 1995, Trevor Kaufman wrote: > unsubscribe > > **I know people who do this are idiots, but I can't find the right address > to send this to. It's pretty simple, unless something isn't working right. Following the usual convention, you send your request to mbone-request@isi.edu. In the case of this list, you'll get a canned message back telling you to resend your request to a specific regional sublist since the list is hierarchically structured. -- Steve From list-mgr@ISI.EDU Wed Aug 2 13:07:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02958>; Wed, 2 Aug 1995 04:09:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02938>; Wed, 2 Aug 1995 04:08:33 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA02931>; Wed, 2 Aug 1995 04:08:31 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA26848>; Wed, 2 Aug 1995 04:08:26 -0700 Message-Id: <199508021108.AA26848@quark.isi.edu> Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.25503-0@bells.cs.ucl.ac.uk>; Wed, 2 Aug 1995 12:08:06 +0100 To: mbone Subject: Asymmetric Tunnel Watch Date: Wed, 02 Aug 95 12:07:59 +0100 From: I.Wakeman@cs.ucl.ac.uk Since no-one objected last week (some people even encouraged us), and a number of asymmetric tunnels in last weeks list have now been corrected, we've decided to post the list of asymmetric tunnels again. If you manage one of these tunnels please check that they are as they should be, or else black holes can appear for metrics, and strange scoping effects can appear for ill-matched thresholds. If we're wrong in our report, please let us know, since it may indicate a bug. For each pair of hosts, a "t" indicates that the ttl thresholds are unbalanced, and an "m" indicates the metrics are unbalanced. The metric values are paired first, and then the thresholds. The information is gathered using mcollect form Atanu Ghosh and Piete Brooks <http://www.cl.cam.ac.uk/mbone/index.html>. cheers ian and atanu thor.ece.uc.edu m cyhan.csm.uc.edu [1/2][64/64] broodjeham.surfnet.nl m mbone.rus.uni-stuttgart.de [5/1][48/48] cpk-ms1.sura.net t mbone.sura.net [1/1][1/32] cdrn-sura9-c1.sura.net m mbone.sura.net [1/3][32/32] fibula.cic.net mt davros.acs.ohio-state.edu [2/1][64/32] se1-eth2-2.net.ohio-state.edu t davros.acs.ohio-state.edu [1/1][11/0] peggy.aads.net mt davros.acs.ohio-state.edu [2/1][32/64] sprint-oeb-e0.columbus.oar.net mt ernie.bgsu.edu [2/1][32/0] sprint-oeb-e0.columbus.oar.net mt thor.ece.uc.edu [2/1][32/0] grid.arl.mil t les7.arl.mil [2/2][8/2] 204.235.71.2 m 204.235.65.2 [2/1][48/48] sphinx.cc.ic.ac.uk t noc.cam.ja.net [1/1][24/64] sura-mp2-pe.sura.net t cpk-ms1.sura.net [1/1][32/1] stargate.ida.org t cpk-ms1.sura.net [1/1][32/128] generic.sura.net t cpk-ms1.sura.net [1/1][32/64] mbone.direcpc.com t cpk-ms1.sura.net [1/1][32/64] faraday.gmu.edu t noc.hpc.org [1/1][64/16] a-wing.jvnc.net t noc.hpc.org [1/1][64/32] electron-a.nasa.atd.net m copernicus.nrl.atd.net [4/1][1/1] butthead.atglab.bls.com t bstfirewall.atglab.bls.com [1/1][8/1] 139.133.210.26 t jal.cc.abdn.ac.uk [1/1][24/16] fuji.ethz.ch t mbone-transit.ethz.ch [1/1][1/16] clever.Germany.EU.net mt test-RS.ripe.net [1/3][64/1] broodjeham.surfnet.nl m ws-dus.dfn.de [1/5][48/48] directory.funet.fi t stockholm.mbone.ebone.net [1/1][40/32] lunde.runit.sintef.no t stockholm.mbone.ebone.net [1/1][40/32] patella.uni-c.dk t stockholm.mbone.ebone.net [1/1][40/32] mg.cyf-kr.edu.pl t stockholm.mbone.ebone.net [1/1][40/32] fmroute1-1.exp.edf.fr t stockholm.mbone.ebone.net [4/4][64/48] qhepuc.oeaw.ac.at mt mbone.aco.net [1/3][32/1] 128.130.5.129 t mbone.aco.net [1/1][32/64] sintef-gw.sintef.no t lunde.runit.sintef.no [1/1][6/0] sarastro.nbi.dk t patella.uni-c.dk [1/1][16/32] noc.near.net mt MBONE.CIT.CORNELL.EDU [7/1][32/64] RASTRO.MIT.EDU m MBONE.CIT.CORNELL.EDU [7/1][64/64] tipper.oit.unc.edu t mbone.ncren.net [1/1][32/10] mbone.merit.edu t a-wing.jvnc.net [1/1][32/64] 130.94.40.201 t a-wing.jvnc.net [1/1][64/0] scorpio.arc.nasa.gov t mbone2.nsi.nasa.gov [1/1][16/1] tahoe.arc.nasa.gov mt mbone2.nsi.nasa.gov [1/16][16/1] 128.250.136.2 t borromini.arbld.unimelb.EDU.AU [1/1][1/4] baiame.sep.unimelb.EDU.AU t borromini.arbld.unimelb.EDU.AU [1/1][1/8] baiame.sep.unimelb.EDU.AU t 128.250.136.2 [1/1][4/8] wehib.wehi.edu.au t vitruvius.arbld.unimelb.EDU.AU [1/1][16/1] wtn-mp1-mae-east-pe.sura.net t wtn-ms1.sura.net [1/1][32/1] appalachian.cc.gatech.edu t houdini-fddi.gatech.edu [1/1][8/4] zen.wustl.edu mt ns1.sprintlink.net [1/3][64/1] thinkpix.com t ns1.sprintlink.net [1/1][64/1] mbone.tamu.edu t ns1.sprintlink.net [1/1][64/255] boston.terra.net t ns1.sprintlink.net [1/1][64/0] nevis3.nevis.columbia.edu t 192.12.15.1 [1/1][32/1] janus.gw.utexas.edu t mis.bus.utexas.edu [1/1][32/1] mbone.chalmers.se t cth-fddi-gw.chalmers.se [1/1][0/1] merkurius.lu.se t half.dna.lth.se [1/1][8/4] bowder.ncl.ac.uk t scoat.ncl.ac.uk [1/1][1/64] news.spb.su t nic.edu.fi [1/1][64/16] alcor.vc.cvut.cz t pklunx.cvut.cz [1/1][64/1] hp18.fzu.cz mt pklunx.cvut.cz [1/3][64/32] leporello.cs.unibo.it t astra.infn.it [1/1][24/128] dunet2.router.tudelft.nl t dutepp7.et.tudelft.nl [1/1][16/32] morgul.barrnet.net t mbone.nsi.nasa.gov [1/1][64/0] schwartz.lerc.nasa.gov mt mbone.lerc.nasa.gov [1/2][1/32] charybdis.ipac.caltech.edu t elxr-fddi.jpl.nasa.gov [1/1][48/16] corvette.jpl.nasa.gov t elxr-fddi.jpl.nasa.gov [1/1][8/1] monte.cscs.ch mt swiMA8.switch.ch [2/0][16/0] oncidium.cscs.ch mt swiMA8.switch.ch [2/0][16/0] tibia.cic.net t mbone.merit.edu [1/1][64/32] Clouso.CRIM.CA t atlantis.CC.McGill.CA [1/1][32/16] loon.Music.McGill.CA t atlantis.CC.McGill.CA [1/1][8/1] cisco-red.iss.nus.sg t venus.cc.nus.sg [1/1][1/0] sununx.iscs.nus.sg t venus.cc.nus.sg [1/1][4/16] exxilon.xx.rmit.EDU.AU t aggedor.rmit.EDU.AU [1/1][16/32] bowen.cc.utas.edu.au m aggedor.rmit.EDU.AU [1/2][32/32] wtn-mp1-pe.sura.net t trivia.CSS.GOV [1/1][1/32] 128.83.134.252 t janus.gw.utexas.edu [1/1][1/64] mbone.sunet.se t merkurius.lu.se [1/1][8/16] mbone.sunet.se t aquila.udac.uu.se [1/1][8/16] mbone.sunet.se t mbone.nada.kth.se [1/1][8/16] caligola.cselt.stet.it t iclsp20.cilea.it [1/1][16/1] news.spb.su t arch.kiae.su [1/1][5/4] aquarius.Relcom.EU.net t arch.kiae.su [1/1][3/1] mbone.sunet.se t hydra.sics.se [1/1][8/16] mbone.sunet.se t lower-gw.sunet.se [1/1][8/16] nintendo.enst-bretagne.fr mt matisse.univ-rennes1.fr [1/3][32/1] CVUT-gw.cvut.cz t ns.felk.cvut.cz [1/1][1/0] sun4.iihe.ac.be m sideral.rediris.es [1/4][48/48] corbu.cnrs-mrs.fr t gauss.univ-mrs.fr [1/1][16/32] jupiter.cc.nagasaki-u.ac.jp m study-rs.mech.nagasaki-u.ac.jp [2/1][5/5] solaris.cc.vt.edu t isb-ags.e6.cns.vt.edu [1/1][32/1] ns1.nysernet.net t startide.ctr.columbia.edu [1/1][32/64] sat.t.u-tokyo.ac.jp t 130.69.127.51 [1/1][1/64] indy.cc.it-hiroshima.ac.jp t saijo.csi.ad.jp [1/1][176/174] ny-columbia-1-s0-T3.nysernet.net t ns1.nysernet.net [1/1][64/0] sbrick.cs.sunysb.edu mt ns1.nysernet.net [1/4][64/1] madoka.its.rpi.edu t ns1.nysernet.net [1/1][64/128] hibp7.ecse.rpi.edu t madoka.its.rpi.edu [1/1][2/1] cosmos.kaist.ac.kr t mindlle.cse.cau.ac.kr [3/3][1/16] cabal.Colorado.EDU m matisse.VIS.ColoState.EDU [2/1][32/32] jupiter.cc.nagasaki-u.ac.jp m nic.karrn.ad.jp [1/5][64/64] pero.sysa.csse.yamaguchi-u.ac.jp t nic.karrn.ad.jp [1/1][64/160] nakasu.csce.kyushu-u.ac.jp t starbow.cc.kyushu-u.ac.jp [1/1][1/4] Utumno.BARRNET.NET m matmos.hpl.hp.com [2/1][64/64] morgul.barrnet.net t MightyDog.Stanford.EDU [1/1][32/0] Dragonlance.Stanford.EDU t MightyDog.Stanford.EDU [2/2][16/32] Waimea.Stanford.EDU t MightyDog.Stanford.EDU [2/2][16/32] tempest.Stanford.EDU t MightyDog.Stanford.EDU [1/1][16/32] winona.Stanford.EDU t MightyDog.Stanford.EDU [1/1][16/1] morgul.barrnet.net t Utumno.BARRNET.NET [1/1][32/0] 129.213.128.9 t Utumno.BARRNET.NET [1/1][32/1] morgul.barrnet.net t PLAYGROUND.SUN.COM [1/1][32/0] morgul.barrnet.net t angband.barrnet.net [1/1][32/0] ns3.sprintlink.net mt whitman.sprintmrn.com [3/1][1/64] ace.mid.net mt hobbes.ksu.ksu.edu [3/1][1/32] mbone.ucar.edu t nist-gw.ucar.edu [1/1][64/24] tempeh.sesqui.net t PAVLOV.SSCTR.BCM.TMC.EDU [1/1][1/64] brahms.sdsc.edu mt mbone-dmz.nosc.mil [1/2][64/32] atlantis-null.brooks.af.mil t mbone-dmz.nosc.mil [1/1][64/32] mb204.isi.edu t mbone.isi.edu [1/1][32/1] nersc-noc.es.net t llnl-mr2.es.net [1/1][1/0] ostermann.cs.ohiou.edu t marconi.tcom.ohiou.edu [1/1][4/1] bowen.cc.utas.edu.au t savoy.aarnet.edu.au [1/1][64/32] caffeine.pa.dec.com t morgul.barrnet.net [1/1][0/32] cosmos.kaist.ac.kr t h2o.kotel.co.kr [1/1][32/16] oversteer.library.uwa.edu.au mt diablox.uwa.edu.au [1/3][8/1] gin.ee.umanitoba.ca t Clouso.CRIM.CA [1/1][32/64] sundiver.cnoc.imnet.ad.jp mt mbone.inoc.imnet.ad.jp [1/3][1/32] bonnou.kddlabs.co.jp t mbone.inoc.imnet.ad.jp [1/1][64/96] suzume.crl.go.jp m mbone.inoc.imnet.ad.jp [1/5][32/32] bandai.cc.kyushu-u.ac.jp t nakasu.csce.kyushu-u.ac.jp [1/1][1/16] ccmng.riken.go.jp m ns.riken.go.jp [1/3][1/1] dns2.anl.gov t benedick.ctd.anl.gov [1/1][16/32] MBONE-2.MIT.EDU t X.media.mit.edu [1/1][1/8] taro.etri.re.kr t cosmos.kaist.ac.kr [3/3][16/1] MBONE3.UU.NET m nb-gw.rutgers.edu [1/3][64/64] bandai.cc.kyushu-u.ac.jp t sakimori.cc.kyushu-u.ac.jp [1/1][1/16] ccmng.riken.go.jp t jupiter.riken.go.jp [1/1][1/16] tron.nts.uci.edu m mbone-cerfnet.sdsc.edu [1/8][32/32] utorgw.gw.utoronto.ca t mbone.on.canet.ca [1/1][1/32] biyo.csce.kyushu-u.ac.jp m bandai.cc.kyushu-u.ac.jp [1/3][4/4] elm.netcom.ubc.ca t netman.cs.ubc.ca [1/1][1/16] otsiris.ucs.sfu.ca t wizzl.ucs.sfu.ca [1/1][16/1] mbone.sunet.se t gaston.telematik.su.se [1/1][8/16] jocosus.matematik.su.se mt gaston.telematik.su.se [1/3][8/1] stisun2-f1.epfl.ch t liasg5.epfl.ch [1/1][1/16] stacer.eecs.ukans.edu mt curie.eecs.ukans.edu [2/1][10/1] davis.cecer.army.mil t dcl2.gw.uiuc.edu [1/1][64/32] jeeves.ncsa.uiuc.edu t dcl2.gw.uiuc.edu [1/1][16/1] elm.netcom.ubc.ca m mbone-seattle.nwnet.net [3/1][64/64] klaatu.fhcrc.org mt mbone-seattle.nwnet.net [1/3][32/1] gateway.ora.dnd.ca t rtr.ndhq.dnd.ca [1/1][1/16] fibula.cic.net m rossi.astro.nwu.edu [3/1][32/32] sprint-oeb-e0.columbus.oar.net mt dune.mcs.kent.edu [2/1][32/0] 164.67.3.1 t sequel.humnet.ucla.edu [1/1][4/32] polyphemus.gang.umass.edu t erlang.cs.umass.edu [1/1][1/3] RASTRO.MIT.EDU t erlang.cs.umass.edu [1/1][3/32] tiananmen.cc.nd.edu t fibula.cic.net [1/1][32/1] tdraffic.gw.psu.edu t fibula.cic.net [1/1][32/64] tron.nts.uci.edu mt john-bigboote.ics.uci.edu [1/2][1/8] ss20.mty.itesm.mx mt agave.staff.udg.mx [10/1][1/64] paris-e0.ucla.edu m tron.nts.uci.edu [8/1][64/64] draco.acs.uci.edu mt tron.nts.uci.edu [2/1][8/1] bossanova.ics.uci.edu mt tron.nts.uci.edu [2/1][8/1] isengard.barrnet.net t mbone.Berkeley.EDU [1/1][64/32] mroute.winona.msus.edu mt Riverside.MR.Net [3/1][32/1] softserv.solsource.net m sl-ana-3-S3/3-384k.sprintlink.net [1/0][0/0] 128.8.15.1 t spiderman.umbc.edu [1/1][24/0] tempest.CC.McGill.CA t cythera.unb.ca [1/1][32/1] MBONE1.UU.NET t neteye.thepoint.com [1/1][1/64] bob.EECS.Berkeley.EDU t inr-181.Berkeley.EDU [1/1][0/4] aldebaran.EECS.Berkeley.EDU t inr-181.Berkeley.EDU [1/1][0/1] navis-1.ie.org t MBONE1.UU.NET [1/1][64/32] sura-mp2-pe.sura.net t 129.2.250.1 [1/1][0/32] clove.kirc.wide.ad.jp mt garlic.sfc.wide.ad.jp [3/1][8/1] sprint-oeb-e0.columbus.oar.net mt ostermann.cs.ohiou.edu [3/1][64/0] mbone.sunet.se t mit-gw.umu.se [1/1][8/16] dsigw.drenet.dnd.ca t rtr.nrnsinc.on.ca [1/1][16/1] gateway.prep.net t igi.prep.net [1/1][1/32] gateway.crad.dnd.ca t 128.43.253.45 [1/1][100/16] sprint-oeb-e0.columbus.oar.net mt doggy.oar.net [2/1][32/0] boo.cc.columbia.edu t 128.59.247.1 [1/1][0/64] mbone.gate.uni-erlangen.de t star.gate.uni-erlangen.de [1/1][24/32] 129.250.200.14 t 129.250.200.9 [1/1][24/32] From list-mgr@ISI.EDU Wed Aug 2 01:43:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03471>; Wed, 2 Aug 1995 04:49:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03394>; Wed, 2 Aug 1995 04:44:15 -0700 Received: from wkst025 (wkst025.css.gordon.army.mil) by venera.isi.edu (5.65c/5.61+local-22) id <AA03387>; Wed, 2 Aug 1995 04:44:09 -0700 Date: Wed, 2 Aug 95 06:43:51 EST Message-Id: <9508020643.AA11608@SIMMONSN@CSS583.GORDON.ARMY.MIL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "ken simmons" <simmonsn@css583.gordon.army.mil> Reply-To: <simmonsn@css583.gordon.army.mil> X-Sender: <simmonsn@SIMMONSN@CSS583.GORDON.ARMY.MIL> To: mbone Subject: unsubscribe X-Mailer: <WS_SEND v94.12.29> unsubscribe thanks... From list-mgr@ISI.EDU Wed Aug 2 06:03:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06146>; Wed, 2 Aug 1995 07:04:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06138>; Wed, 2 Aug 1995 07:04:03 -0700 Received: from turing.mathworks.com by venera.isi.edu (5.65c/5.61+local-22) id <AA06130>; Wed, 2 Aug 1995 07:04:01 -0700 Received: from zippy.mathworks.com ([144.212.20.6]) by turing.mathworks.com (8.6.11/8.6-dp) with ESMTP id KAA12295 for <mbone@isi.edu>; Wed, 2 Aug 1995 10:03:48 -0400 Date: Wed, 2 Aug 1995 10:03:47 -0400 (EDT) From: Dave Pascoe <pascoe@mathworks.com> X-Sender: pascoe@zippy To: mbone Subject: mrouted 3.6 messages Message-Id: <Pine.SOL.3.91.950802095250.6237B-100000@zippy> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm starting to see a lot of these in /var/adm/messages on a SunOS 4.1.3 box running mrouted 3.6: --------------------------------------------------------------------- Aug 2 09:52:29 gate mrouted[115]: warning - 144.212.100.1 reports out-of-range metric 64 for origin 204.162.81/24 ---------------------------------------------------------------------- 144.212.100.1 is running Cisco IOS 10.2(2) This started (I think) after upgrading mrouted on mbone.mathworks.com to mrouted-3.6 and after configuring our internal MBone router to run on the Cisco router. So it would appear the PIM stuff on the Cisco is sending these reports to mrouted. I'm fine up to that point. My basic question is: what do these mean? The source is on network 204.162.81/24. Why does our internal mrouter (Cisco) report the metric as being out-of-range? Should I just turn these syslogging's off for now? The messages are logged in this part of route.c: ----- /* * Compute an adjusted metric, taking into account the cost of the * subnet or tunnel over which the report arrived, and normalizing * all unreachable/poisoned metrics into a single value. */ if (src != 0 && (metric < 1 || metric >= 2*UNREACHABLE)) { log(LOG_WARNING, 0, "%s reports out-of-range metric %u for origin %s", inet_fmt(src, s1), metric, inet_fmts(origin, mask, s2)); return; } adj_metric = metric + uvifs[vifi].uv_metric; if (adj_metric > UNREACHABLE) adj_metric = UNREACHABLE; ----- Thanks for any pointers..... -Dave From list-mgr@ISI.EDU Wed Aug 2 01:46:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09612>; Wed, 2 Aug 1995 08:48:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09595>; Wed, 2 Aug 1995 08:47:50 -0700 Received: from puli.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA09585>; Wed, 2 Aug 1995 08:47:49 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id IAA24661; Wed, 2 Aug 1995 08:46:48 -0700 Message-Id: <199508021546.IAA24661@puli.cisco.com> To: Dave Pascoe <pascoe@mathworks.com> Cc: multicast-support@cisco.com, mbone Subject: Re: mrouted 3.6 messages In-Reply-To: Your message of "Wed, 02 Aug 1995 10:03:47 EDT." <Pine.SOL.3.91.950802095250.6237B-100000@zippy> Date: Wed, 02 Aug 1995 08:46:47 -0700 From: "John M. Zwiebel" <jzwiebel@cisco.com> This has been fixed on the cisco's. The latest 10.2 image is (7.3). If you update the warning will go away. z > > I'm starting to see a lot of these in /var/adm/messages on a SunOS 4.1.3 > box running mrouted 3.6: > --------------------------------------------------------------------- > Aug 2 09:52:29 gate mrouted[115]: warning - 144.212.100.1 reports > out-of-range metric 64 for origin 204.162.81/24 > ---------------------------------------------------------------------- > > 144.212.100.1 is running Cisco IOS 10.2(2) From list-mgr@ISI.EDU Wed Aug 2 02:57:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13155>; Wed, 2 Aug 1995 10:02:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12955>; Wed, 2 Aug 1995 09:57:31 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA12946>; Wed, 2 Aug 1995 09:57:31 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15675(1)>; Wed, 2 Aug 1995 09:57:23 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Wed, 2 Aug 1995 09:57:14 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Dave Pascoe <pascoe@mathworks.com> Cc: mbone, multicast-support@cisco.com Subject: Re: mrouted 3.6 messages In-Reply-To: Your message of "Wed, 02 Aug 95 07:03:47 PDT." <Pine.SOL.3.91.950802095250.6237B-100000@zippy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 2 Aug 1995 09:57:01 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Aug2.095714pdt.177475@crevenia.parc.xerox.com> In message <Pine.SOL.3.91.950802095250.6237B-100000@zippy> you write: >Aug 2 09:52:29 gate mrouted[115]: warning - 144.212.100.1 reports >out-of-range metric 64 for origin 204.162.81/24 > >144.212.100.1 is running Cisco IOS 10.2(2) Your Cisco is apparently applying "poison reverse" to unreachable routes, which mrouted doesn't understand. This causes mrouted to ignore that route from the update. This should be harmless in this situation, since if the Cisco sent a poisoned route then presumably that mrouted supplied it with the route in the first place. Cisco's DVMRP implementation shouldn't be sending poisoned unreachables, though. Bill From list-mgr@ISI.EDU Wed Aug 2 03:10:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13600>; Wed, 2 Aug 1995 10:10:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13582>; Wed, 2 Aug 1995 10:10:33 -0700 Received: from beatrix.cnet.com by venera.isi.edu (5.65c/5.61+local-22) id <AB13575>; Wed, 2 Aug 1995 10:10:32 -0700 Received: (from ken@localhost) by beatrix.cnet.com (8.6.12/8.6.12) id KAA04294; Wed, 2 Aug 1995 10:10:29 -0700 Date: Wed, 2 Aug 1995 10:10:29 -0700 From: ken@CNET.Com Message-Id: <199508021710.KAA04294@beatrix.cnet.com> To: mbone, pascoe@mathworks.com Subject: Re: mrouted 3.6 messages X-Sun-Charset: US-ASCII > I'm starting to see a lot of these in /var/adm/messages on a SunOS 4.1.3 > box running mrouted 3.6: > --------------------------------------------------------------------- > Aug 2 09:52:29 gate mrouted[115]: warning - 144.212.100.1 reports > out-of-range metric 64 for origin 204.162.81/24 > ---------------------------------------------------------------------- This is us (cnet.com) and the machine is 204.162.81.12 (conundrum.cnet.com). It is an SGI running IRIX 5.3 with the default mrouted software from SGI (version 2.2?). I haven't been able to upgrade it to the latest version (3.4) as of yet. Hopefully I can get a Sun video board and move the mrouted to a Sun. > 144.212.100.1 is running Cisco IOS 10.2(2) > This started (I think) after upgrading mrouted on mbone.mathworks.com to > mrouted-3.6 and after configuring our internal MBone router to run on the > Cisco router. So it would appear the PIM stuff on the Cisco is sending > these reports to mrouted. I'm fine up to that point. Are any of your mrouted's multiply connected to the mbone? If so you may be getting duplicate packets (I think that is how Van explained it to me). > My basic question is: what do these mean? The source is on network > 204.162.81/24. Why does our internal mrouter (Cisco) report the metric > as being out-of-range? Got me, check with Dino. > Should I just turn these syslogging's off for now? > > The messages are logged in this part of route.c: > ----- > /* > * Compute an adjusted metric, taking into account the cost of the > * subnet or tunnel over which the report arrived, and normalizing > * all unreachable/poisoned metrics into a single value. > */ > if (src != 0 && (metric < 1 || metric >= 2*UNREACHABLE)) { > log(LOG_WARNING, 0, > "%s reports out-of-range metric %u for origin %s", > inet_fmt(src, s1), metric, inet_fmts(origin, mask, s2)); > return; > } > adj_metric = metric + uvifs[vifi].uv_metric; > if (adj_metric > UNREACHABLE) adj_metric = UNREACHABLE; bye, ken emery From list-mgr@ISI.EDU Wed Aug 2 03:17:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14024>; Wed, 2 Aug 1995 10:18:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14011>; Wed, 2 Aug 1995 10:18:02 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA14004>; Wed, 2 Aug 1995 10:18:01 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id KAA11842; Wed, 2 Aug 1995 10:17:43 -0700 Date: Wed, 2 Aug 1995 10:17:43 -0700 From: Dino Farinacci <dino@cisco.com> Message-Id: <199508021717.KAA11842@stilton.cisco.com> To: fenner@parc.xerox.com Cc: pascoe@mathworks.com, mbone, multicast-support@cisco.com In-Reply-To: Bill Fenner's message of Wed, 2 Aug 1995 09:57:01 PDT <95Aug2.095714pdt.177475@crevenia.parc.xerox.com> Subject: mrouted 3.6 messages >> Cisco's DVMRP implementation shouldn't be sending poisoned unreachables, >> though. This is an old bug. Please upgrade to at least 10.2(7). Dino From list-mgr@ISI.EDU Thu Aug 3 00:47:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18944>; Wed, 2 Aug 1995 11:48:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18933>; Wed, 2 Aug 1995 11:47:57 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA18919>; Wed, 2 Aug 1995 11:47:52 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.11/8.6.9) id VAA02455; Wed, 2 Aug 1995 21:47:08 +0300 Date: Wed, 2 Aug 1995 21:47:08 +0300 Message-Id: <199508021847.VAA02455@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: ken@CNET.Com Cc: mbone, pascoe@mathworks.com Subject: Re: mrouted 3.6 messages In-Reply-To: <199508021710.KAA04294@beatrix.cnet.com> References: <199508021710.KAA04294@beatrix.cnet.com> ken@cnet.com writes: > > 144.212.100.1 is running Cisco IOS 10.2(2) > > > My basic question is: what do these mean? The source is on network > > 204.162.81/24. Why does our internal mrouter (Cisco) report the metric > > as being out-of-range? > > Got me, check with Dino. > This is fixed with 10.2(7) (and actually before) but the 10.2(7) is latest of the 10.2-tree. You really should upgrade if you are going to run multicast and specially DVMRP-interaction on the box. The DVMRP stuff also leaks memory up-and-including around 10.2(5). (at least on a 7000) Pete From list-mgr@ISI.EDU Wed Aug 2 12:24:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23768>; Wed, 2 Aug 1995 13:24:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23735>; Wed, 2 Aug 1995 13:24:31 -0700 Received: from burdell.cc.gatech.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA23722>; Wed, 2 Aug 1995 13:24:29 -0700 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.6.12/8.6.9) with ESMTP id QAA12981; Wed, 2 Aug 1995 16:24:26 -0400 Received: (from kevin@localhost) by flora.cc.gatech.edu (8.6.10/8.6.9) id QAA28551; Wed, 2 Aug 1995 16:24:22 -0400 Date: Wed, 2 Aug 1995 16:24:22 -0400 From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199508022024.QAA28551@flora.cc.gatech.edu> To: kevin@cc.gatech.edu Subject: Mbone Session Membership Collection Some of the recent discussion on the rem-conf and Mbone lists have dealt with collection of vat participant lists, and estimated group size numbers for various Mbone sessions including the recent Stockholm IETF and STS-71 Shuttle Mission broadcasts. This discussion relates to a research effort here at Georgia Tech to collect membership information and then characterize the participant behavior for Mbone audio sessions. We recently submitted a paper to INFOCOM, but I thought that based on the recent discussions, a WWW pointer would be more timely and useful to this group. I've included a text copy of the abstract below, and a WWW pointer can be found in my sig. -Kevin ---------------------------------------------------------------------- Characterization of Mbone Session Dynamics: Developing and Applying a Measurement Tool Kevin C. Almeroth Mostafa H. Ammar Much of our current understanding of the operational aspects and the network support requirements of multicast communication derives from the Mbone. As an experimental network that overlays the Internet, the Mbone has served as the testbed for many ideas. Most prominent is the development of a set of audio and video conferencing tools that have been used extensively in the last few years. This paper describes our efforts in developing and using a measurement tool for characterizing the dynamic behavior of Mbone sessions. Such a characterization will be of great benefit in understanding how any future networking infrastructure with multicast and real-time capabilities will be used. We discuss the challenges in monitoring Mbone session participation and report on a methodology for pre-processing observed data to make it better reflect the true behavior of participants in an Mbone session. We also report on the results of using our tool to determine temporal, geographical and resource usage characteristics of several Mbone sessions. ---------------------------------------------------------------------- Kevin Almeroth (kevin@cc.gatech.edu) Networking and Telecommunications Research Group College of Computing, Georgia Institute of Technology http://www.cc.gatech.edu/computing/Telecomm/people/Phd/kevin/kevin.html From list-mgr@ISI.EDU Thu Aug 3 14:29:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24161>; Thu, 3 Aug 1995 05:30:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24153>; Thu, 3 Aug 1995 05:29:51 -0700 Received: from tamdhu.dcs.st-andrews.ac.uk (tamdhu.dcs.st-and.ac.uk) by venera.isi.edu (5.65c/5.61+local-22) id <AA24146>; Thu, 3 Aug 1995 05:29:43 -0700 Received: from bushmills.dcs.st-and.ac.uk by tamdhu.dcs.st-andrews.ac.uk (4.1/SMI-4.1) id AA10480; Thu, 3 Aug 95 13:31:25 BST Message-Id: <9508031231.AA10480@tamdhu.dcs.st-andrews.ac.uk> To: mbone Cc: ca@dcs.st-and.ac.uk, mjl@dcs.st-and.ac.uk, phrrngtn@dcs.st-and.ac.uk, fh@dcs.st-and.ac.uk Subject: "well-known" groups for data? Date: Thu, 03 Aug 1995 13:29:34 +0100 From: "Paul Harrington" <phrrngtn@dcs.st-and.ac.uk> [ Question is at the end after the handwaving] Hi, In an effort to learn something about 'workstation spare capacity utilisation', we did some tests with multicasting ascii collections of resource utilisation samples from networks of workstations. We are still experimenting with encoding the 'behaviour' of an entire network of workstations. One approach is to calculate parameter values for various models e.g. non-stationary probabilities for things like availability, work arrival patterns, free memory availability and so on. (I am looking at work by Mutka, NOW and the 'Idleness is not sloth' paper from a recent Usenix) Once we have _concise_, accurate and useful characterisations of _groups_ of workstations, we would like to set up a semi-permanent group on which clusters could publish their information and listen to the activities of other clusters. This data would be used for study into distributed scheduling and remote resource utilisation. Rate limitation would be used to restrict consumption to something reasonable (less than 8M has been transmitted since March ... about 1/2 a byte per second!) Q: What is the best way of going about this? Via DNS? (SGI-DOG.MCAST.NET. maps onto 224.0.1.2 for the SGI dogfight stuff) Permanent sd session announcement? Or just continue spitting them out on 224.14.5.69/1969 :-) Any ideas? pjjH From list-mgr@ISI.EDU Sat Aug 5 02:31:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05841>; Sat, 5 Aug 1995 15:30:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05833>; Sat, 5 Aug 1995 15:30:31 -0700 Received: from mailrelay.pixi.com (sirius.pixi.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA05826>; Sat, 5 Aug 1995 15:30:29 -0700 Received: by mailrelay.pixi.com (8.6.10/SMI-4.1) id MAA06912; Sat, 5 Aug 1995 12:31:31 -1000 Date: Sat, 5 Aug 1995 12:31:31 -1000 (HST) From: Antonio Querubin Jr <tony@pixi.com> To: mbone Subject: bad connectivity to Sprint tunnel? Message-Id: <Pine.S40.3.91.950805122653.6053B-100000@sirius.pixi.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Anybody else with a tunnel pointing to Sprint seeing this? PING 144.228.8.227: 56 data bytes 64 bytes from 144.228.8.227: icmp_seq=25. time=70. ms 64 bytes from 144.228.8.227: icmp_seq=136. time=69. ms 64 bytes from 144.228.8.227: icmp_seq=177. time=77. ms 64 bytes from 144.228.8.227: icmp_seq=204. time=75. ms 64 bytes from 144.228.8.227: icmp_seq=228. time=75. ms 64 bytes from 144.228.8.227: icmp_seq=345. time=77. ms 64 bytes from 144.228.8.227: icmp_seq=422. time=89. ms 64 bytes from 144.228.8.227: icmp_seq=431. time=65. ms ----144.228.8.227 PING Statistics---- 475 packets transmitted, 8 packets received, 98% packet loss round-trip (ms) min/avg/max = 65/74/89 Antonio Querubin tony@pixi.com / ah6bw@uhm.ampr.org From list-mgr@ISI.EDU Sun Aug 6 13:47:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00548>; Sun, 6 Aug 1995 13:47:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00532>; Sun, 6 Aug 1995 13:47:13 -0700 Received: from tiny.sprintlink.net by venera.isi.edu (5.65c/5.61+local-22) id <AA00525>; Sun, 6 Aug 1995 13:47:10 -0700 Received: from Slaptoy.Stupi.SE (HQ.Stupi.SE [192.108.201.202]) by tiny.sprintlink.net (8.6.9/8.6.9) with ESMTP id QAA09616; Sun, 6 Aug 1995 16:47:05 -0400 Date: Sun, 6 Aug 95 18:05:06 MET DST From: Peter Lothberg <roll@Stupi.SE> To: Antonio Querubin Jr <tony@pixi.com> Cc: mbone Subject: Re: bad connectivity to Sprint tunnel? In-Reply-To: Your message of Sat, 5 Aug 1995 12:31:31 -1000 (HST) Message-Id: <CMM.0.90.0.807725106.roll@Slaptoy.Stupi.SE> > Anybody else with a tunnel pointing to Sprint seeing this? > > PING 144.228.8.227: 56 data bytes > 64 bytes from 144.228.8.227: icmp_seq=25. time=70. ms > 64 bytes from 144.228.8.227: icmp_seq=136. time=69. ms > 64 bytes from 144.228.8.227: icmp_seq=177. time=77. ms > 64 bytes from 144.228.8.227: icmp_seq=204. time=75. ms > 64 bytes from 144.228.8.227: icmp_seq=228. time=75. ms > 64 bytes from 144.228.8.227: icmp_seq=345. time=77. ms > 64 bytes from 144.228.8.227: icmp_seq=422. time=89. ms > 64 bytes from 144.228.8.227: icmp_seq=431. time=65. ms > ----144.228.8.227 PING Statistics---- > 475 packets transmitted, 8 packets received, 98% packet loss > round-trip (ms) min/avg/max = 65/74/89 > Antonio Querubin > tony@pixi.com / ah6bw@uhm.ampr.org This is not very usefull for troubleshooting, as I asume you want the potential problems to be fixed? Please do a traceroute from your box to 144.228.8.227, and send me the output and include in the message the IP address of your box. --Peter From list-mgr@ISI.EDU Sun Aug 6 14:30:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17982>; Mon, 7 Aug 1995 03:39:03 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17909>; Mon, 7 Aug 1995 03:29:51 -0700 Received: from mailrelay.pixi.com (sirius.pixi.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA17902>; Mon, 7 Aug 1995 03:29:50 -0700 Received: by mailrelay.pixi.com (8.6.10/SMI-4.1) id AAA02969; Mon, 7 Aug 1995 00:30:44 -1000 Date: Mon, 7 Aug 1995 00:30:42 -1000 (HST) From: Antonio Querubin Jr <tony@pixi.com> To: Peter Lothberg <roll@Stupi.SE> Cc: mbone Subject: Re: bad connectivity to Sprint tunnel? In-Reply-To: <CMM.0.90.0.807725106.roll@Slaptoy.Stupi.SE> Message-Id: <Pine.S40.3.91.950807002729.2017C-100000@sirius.pixi.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 6 Aug 1995, Peter Lothberg wrote: > Date: Sun, 6 Aug 95 18:05:06 MET DST > From: Peter Lothberg <roll@Stupi.SE> > To: Antonio Querubin Jr <tony@pixi.com> > Cc: mbone@ISI.EDU > Subject: Re: bad connectivity to Sprint tunnel? > > > Anybody else with a tunnel pointing to Sprint seeing this? > > > > PING 144.228.8.227: 56 data bytes > > 475 packets transmitted, 8 packets received, 98% packet loss > > round-trip (ms) min/avg/max = 65/74/89 > > This is not very usefull for troubleshooting, as I asume you want the > potential problems to be fixed? > > Please do a traceroute from your box to 144.228.8.227, and send me the > output and include in the message the IP address of your box. Here's the trace from 204.182.46.1 to 144.228.8.227: 1 tlg-cust-link (140.174.249.1) 56 msec 56 msec 56 msec 2 gw2-sf-tlg.tlg.net (140.174.122.17) 104 msec 56 msec 60 msec 3 gw1-sf-tlg.tlg.net (140.174.125.1) 252 msec 68 msec 128 msec 4 sl-stk-3-S2-T1.sprintlink.net (144.228.43.21) 64 msec 68 msec 68 msec 5 * * * It continues on... Antonio Querubin tony@pixi.com / ah6bw@uhm.ampr.org From list-mgr@ISI.EDU Mon Aug 7 06:53:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22406>; Mon, 7 Aug 1995 07:54:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22385>; Mon, 7 Aug 1995 07:54:05 -0700 Received: from stealth.sprintlink.net by venera.isi.edu (5.65c/5.61+local-22) id <AA22378>; Mon, 7 Aug 1995 07:54:04 -0700 Received: (from rmartin@localhost) by stealth.sprintlink.net (8.6.10/8.6.9) id KAA16630; Mon, 7 Aug 1995 10:53:52 -0400 Date: Mon, 7 Aug 1995 10:53:52 -0400 (EDT) From: Richard Martin <rmartin@sprint.net> Subject: Re: bad connectivity to Sprint tunnel? To: Antonio Querubin Jr <tony@pixi.com> Cc: mbone In-Reply-To: <Pine.S40.3.91.950805122653.6053B-100000@sirius.pixi.com> Message-Id: <Pine.3.89.9508071024.J15179-0100000@stealth.sprintlink.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Antonio: 144.228.8.227 is dead, well not really dead...its a SGI in a Cabletron hub, something called a DNSMIM (don't ask, you don't want to know! :-) )...it works okay but its connected via FDDI bridging (yuck!) that is less than reliable...right now the bridging seems to be flaking out, so I just dispatched someone to powercycle the hub (nothing else is being used in the hub). As I said in a previous message, we plan on replacing it and dc-mbone-1.sprintlink.net in the next month or two with SS5's or the like. But for now, we have to live with them. Richard Martin Sprintlink Systems & Services On Sat, 5 Aug 1995, Antonio Querubin Jr wrote: > Anybody else with a tunnel pointing to Sprint seeing this? > > > PING 144.228.8.227: 56 data bytes > 64 bytes from 144.228.8.227: icmp_seq=25. time=70. ms > 64 bytes from 144.228.8.227: icmp_seq=136. time=69. ms > 64 bytes from 144.228.8.227: icmp_seq=177. time=77. ms > 64 bytes from 144.228.8.227: icmp_seq=204. time=75. ms > 64 bytes from 144.228.8.227: icmp_seq=228. time=75. ms > 64 bytes from 144.228.8.227: icmp_seq=345. time=77. ms > 64 bytes from 144.228.8.227: icmp_seq=422. time=89. ms > 64 bytes from 144.228.8.227: icmp_seq=431. time=65. ms > ----144.228.8.227 PING Statistics---- > 475 packets transmitted, 8 packets received, 98% packet loss > round-trip (ms) min/avg/max = 65/74/89 > > > Antonio Querubin > tony@pixi.com / ah6bw@uhm.ampr.org > > From list-mgr@ISI.EDU Mon Aug 7 01:54:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24916>; Mon, 7 Aug 1995 08:55:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24879>; Mon, 7 Aug 1995 08:54:50 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA24872>; Mon, 7 Aug 1995 08:54:49 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id IAA19846; Mon, 7 Aug 1995 08:54:47 -0700 Message-Id: <199508071554.IAA19846@rx7.ee.lbl.gov> To: sphicas@suncms9.cern.ch Cc: mbone Subject: sphicas@suncms9.cern.ch sending 500kb/s nv video Date: Mon, 07 Aug 95 08:54:46 PDT From: Van Jacobson <van@ee.lbl.gov> You may not be aware that the nv video that you are currently sending from suncms9.cern.ch to 224.2.176.190 is going out to over 20,000 machines all over the world. You are using 500kb/s of bandwidth. The total bandwidth available to the MBone is only 500kb/s so you are using all of it. The mbone usage guidelines say that no session should send more than 128kb/s of video & less if possible. It would be better if you did not send video or if you reduced the ttl on your sender to 63 or less so that your video stayed within your organization. Thanks. - Van Jacobson ps- It might also be good if CERN adopted a policy of educating new users on the etiquette of using the mbone since a disproportionate number of CERN users seem to make the error of using unreasonable amounts of bandwidth. From list-mgr@ISI.EDU Mon Aug 7 10:50:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20288>; Mon, 7 Aug 1995 17:55:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19738>; Mon, 7 Aug 1995 17:50:13 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA19731>; Mon, 7 Aug 1995 17:50:12 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id RAA20376; Mon, 7 Aug 1995 17:50:24 -0700 Message-Id: <199508080050.RAA20376@rx7.ee.lbl.gov> To: av4q@davis.cs.virginia.edu Cc: mbone Subject: av4q@davis.cs.virginia.edu sending 500kb/s nv video Date: Mon, 07 Aug 95 17:50:23 PDT From: Van Jacobson <van@ee.lbl.gov> You may not be aware that the nv video that you are currently sending from davis.cs.virginia.edu to 224.2.212.142/21050 is going out to over 20,000 machines all over the world. You are using 500kb/s of bandwidth. The total bandwidth available to the MBone is only 500kb/s so you are using all of it. The mbone is very busy this week with audio & video from SigGraph '95 and you are completely destroying their broadcast. The mbone usage guidelines say that no session should send more than 128kb/s of video & less if possible. It would be better if you did not send video or if you reduced the ttl on your sender to 63 or less so that your video stayed within your organization. Thanks. - Van Jacobson From list-mgr@ISI.EDU Sat Aug 8 06:08:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23862>; Mon, 7 Aug 1995 19:06:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23780>; Mon, 7 Aug 1995 19:01:25 -0700 Received: from milpitas.adaptec.com by venera.isi.edu (5.65c/5.61+local-22) id <AA23772>; Mon, 7 Aug 1995 19:01:24 -0700 Received: from corpmail.adaptec.com ([162.62.105.19]) by milpitas.adaptec.com (4.1/SMI-4.1) id AA03400; Mon, 7 Aug 95 18:59:35 PDT Received: from by corpmail.adaptec.com (4.1/SMI-4.1) id AB07690; Mon, 7 Aug 95 18:55:41 PDT X-Nvlenv-01Date-Transferred: 7-Aug-1995 18:10:44 -0400; at Mentor.Adaptec X-Nvlenv-01Date-Posted: 08-Aug-1995 10:09:11 -0400; at AJL.Adaptec Date: 08 Aug 95 10:08:00 EDT From: TMatsumu@Asia.adaptec.com Subject: ATM on mbone? Message-Id: <366D2730016B1673@-SMF-> Reply-To: TMatsumu@Asia.adaptec.com References: <376D2730026B1673@-SMF-> To: mbone Can anyone tell me where the ATM links are in the mbone? Thanks. Ted From list-mgr@ISI.EDU Mon Aug 7 16:58:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01674>; Mon, 7 Aug 1995 23:59:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01663>; Mon, 7 Aug 1995 23:58:19 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA01656>; Mon, 7 Aug 1995 23:58:18 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA05171; Mon, 7 Aug 1995 23:58:16 -0700 Date: Mon, 7 Aug 1995 23:58:16 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199508080658.XAA05171@greatdane.cisco.com> To: TMatsumu@asia.adaptec.com Cc: mbone Subject: ATM on mbone? Can anyone tell me where the ATM links are in the mbone? Thanks. The following is a complete list of all ATM links in the Internet backbones which are used to support the mbone: Tony p.s. Humorous and true! ;-) From list-mgr@ISI.EDU Sat Aug 8 12:22:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02641>; Tue, 8 Aug 1995 00:26:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02449>; Tue, 8 Aug 1995 00:21:07 -0700 Received: from milpitas.adaptec.com by venera.isi.edu (5.65c/5.61+local-22) id <AA02442>; Tue, 8 Aug 1995 00:21:06 -0700 Received: from corpmail.adaptec.com ([162.62.105.19]) by milpitas.adaptec.com (4.1/SMI-4.1) id AA11950; Tue, 8 Aug 95 00:19:17 PDT Received: from mentor.adaptec.com by corpmail.adaptec.com (4.1/SMI-4.1) id AA08217; Tue, 8 Aug 95 00:15:19 PDT X-Nvlenv-01Date-Transferred: 8-Aug-1995 0:24:05 -0400; at Mentor.Adaptec X-Nvlenv-01Date-Posted: 08-Aug-1995 16:22:22 -0400; at AJL.Adaptec Date: 08 Aug 95 16:22:00 EDT From: TMatsumu@Asia.adaptec.com Subject: re: ATM on mbone? Message-Id: <90C52730016B1673@-SMF-> In-Reply-To: <199508080658.XAA05171@greatdane.cisco.com> Reply-To: TMatsumu@Asia.adaptec.com References: <199508080658.XAA05171@greatdane.cisco.com> To: tli@cisco.com Well, what can we do to get some ATM links on the mbone? Ted Matsumura, Adaptec Japan ATM Program Manager ------------- Original Text From tli@cisco.com (Tony Li), on 8/7/95 11:58 PM: Can anyone tell me where the ATM links are in the mbone? Thanks. The following is a complete list of all ATM links in the Internet backbones which are used to support the mbone: Tony p.s. Humorous and true! ;-) From list-mgr@ISI.EDU Tue Aug 8 09:24:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02655>; Tue, 8 Aug 1995 00:28:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02473>; Tue, 8 Aug 1995 00:22:21 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA02466>; Tue, 8 Aug 1995 00:22:19 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id IAA11305; Tue, 8 Aug 1995 08:22:12 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id IAA12250; Tue, 8 Aug 1995 08:24:24 +0100 Date: Tue, 8 Aug 1995 08:24:23 +0100 (BST) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Tony Li <tli@cisco.com> Cc: TMatsumu@asia.adaptec.com, mbone Subject: Re: ATM on mbone? In-Reply-To: <199508080658.XAA05171@greatdane.cisco.com> Message-Id: <Pine.SV4.3.91.950808082029.12229B-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 7 Aug 1995, Tony Li wrote: > > Can anyone tell me where the ATM links are in the mbone? Thanks. > > The following is a complete list of all ATM links in the Internet > backbones which are used to support the mbone: > > > > > > > Tony > > p.s. Humorous and true! ;-) Humorous and totally incorrect. A great part of the European backbone is running over ATM. You also overlook such trials as BAGGNET. Or am I missing the point of your joke? ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Tue Aug 8 13:37:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03002>; Tue, 8 Aug 1995 00:43:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02860>; Tue, 8 Aug 1995 00:37:52 -0700 Received: from castor.cc.utu.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA02853>; Tue, 8 Aug 1995 00:37:49 -0700 Received: by utu.fi id <179753-2>; Tue, 8 Aug 1995 10:37:37 +0300 Subject: Re: ATM on mbone? From: Matti Aarnio <mea@utu.fi> To: tli@cisco.com (Tony Li) Date: Tue, 8 Aug 1995 10:37:27 +0300 (EET DST) Cc: mbone In-Reply-To: <199508080658.XAA05171@greatdane.cisco.com> from "Tony Li" at Aug 7, 95 11:58:16 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1248 Message-Id: <95Aug8.103737+0300_eet_dst.179753-2+50@utu.fi> > Can anyone tell me where the ATM links are in the mbone? Thanks. > > The following is a complete list of all ATM links in the Internet > backbones which are used to support the mbone: > > > On backbone, yes. On leaf networks there are some ATM. rip.funet.fi: 193.166.30.157 -> 193.166.166.2 (ressu.atm.tut.fi) [1/12/tunnel] 193.166.30.157 -> 157.24.40.2 (dior.atm.lut.fi) [1/12/tunnel] 193.166.30.157 -> 129.240.202.42 (sauce-atm.uio.no) [3/16/tunnel] sauce-atm.uio.no: 194.104.0.17 -> 194.104.0.18 (lea-atm.cs.ucl.ac.uk) [1/32/tunnel] The Finnish lines are 34 Mbps ATM, link to Norway is propably 2 Mbps. This fall (within 3-5 months) ALL of our national links will run over ATM. (This means 'ordinary IP' in addition to multimedia things.) I recall that during the IETF-33 a couple weeks ago there was an ATM- connection from Stockholm to somewhere in central Europe... Propably it was that Norway-UK link. While traffic over non-ATM had dropouts, ATM runners had very clean and trouble free connectivity (I mean in terms of packet loss, not necesserily in terms of connection setup..) > Tony > > p.s. Humorous and true! ;-) Well, we are not in the central backbone. We just use it ;-) /Matti Aarnio <mea@utu.fi> From list-mgr@ISI.EDU Mon Aug 7 17:51:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03239>; Tue, 8 Aug 1995 00:53:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03196>; Tue, 8 Aug 1995 00:51:37 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA03189>; Tue, 8 Aug 1995 00:51:37 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id AAA12477; Tue, 8 Aug 1995 00:51:01 -0700 Date: Tue, 8 Aug 1995 00:51:01 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199508080751.AAA12477@greatdane.cisco.com> To: Graeme.Wood@ucs.ed.ac.uk Cc: TMatsumu@asia.adaptec.com, mbone In-Reply-To: <Pine.SV4.3.91.950808082029.12229B-100000@scorpio.ucs.ed.ac.uk> (message from Graeme Wood on Tue, 8 Aug 1995 08:24:23 +0100 (BST)) Subject: Re: ATM on mbone? > The following is a complete list of all ATM links in the Internet > backbones which are used to support the mbone: Humorous and totally incorrect. A great part of the European backbone is running over ATM. You also overlook such trials as BAGGNET. Or am I missing the point of your joke? I chose my words quite carefully. Certainly "trials" shouldn't be counted. I certainly haven't seen any ATM connected to the Internet backbones in Europe, which seems to end at Stockholm. Perhaps when you folks get a reasonable link speed off the island. I suppose that I _should_ count the NAPs. With the caveat that we're talking DS3, not OC-3. Tony From list-mgr@ISI.EDU Tue Aug 8 14:25:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04402>; Tue, 8 Aug 1995 01:32:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04167>; Tue, 8 Aug 1995 01:25:44 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA04158>; Tue, 8 Aug 1995 01:25:40 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.11/8.6.9) id LAA01559; Tue, 8 Aug 1995 11:25:25 +0300 Date: Tue, 8 Aug 1995 11:25:25 +0300 Message-Id: <199508080825.LAA01559@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Tony Li <tli@cisco.com> Cc: Graeme.Wood@ucs.ed.ac.uk, TMatsumu@asia.adaptec.com, mbone Subject: Re: ATM on mbone? In-Reply-To: <199508080751.AAA12477@greatdane.cisco.com> References: <Pine.SV4.3.91.950808082029.12229B-100000@scorpio.ucs.ed.ac.uk> <199508080751.AAA12477@greatdane.cisco.com> Tony Li writes: > I chose my words quite carefully. Certainly "trials" shouldn't be > counted. I certainly haven't seen any ATM connected to the > Internet backbones in Europe, which seems to end at Stockholm. > Perhaps when you folks get a reasonable link speed off the island. > > I suppose that I _should_ count the NAPs. With the caveat that we're > talking DS3, not OC-3. > So you _ARE_ counting the links internal to the US but you are _NOT_ counting the links internal to the countries connected to the Internet? For example major parts of the FUNET are running ATM at OC-3 speeds for production use. Pete From list-mgr@ISI.EDU Mon Aug 7 18:34:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04508>; Tue, 8 Aug 1995 01:35:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04500>; Tue, 8 Aug 1995 01:35:17 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA04493>; Tue, 8 Aug 1995 01:35:16 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA13137; Tue, 8 Aug 1995 01:34:41 -0700 Date: Tue, 8 Aug 1995 01:34:41 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199508080834.BAA13137@greatdane.cisco.com> To: pete@sms.fi Cc: Graeme.Wood@ucs.ed.ac.uk, TMatsumu@asia.adaptec.com, mbone In-Reply-To: <199508080825.LAA01559@silver.sms.fi> (message from Petri Helenius on Tue, 8 Aug 1995 11:25:25 +0300) Subject: Re: ATM on mbone? So you _ARE_ counting the links internal to the US but you are _NOT_ counting the links internal to the countries connected to the Internet? For example major parts of the FUNET are running ATM at OC-3 speeds for production use. Seems to me that there's a major choke point between here and there. Tony From list-mgr@ISI.EDU Tue Aug 8 10:31:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04550>; Tue, 8 Aug 1995 01:38:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04460>; Tue, 8 Aug 1995 01:33:31 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA04424>; Tue, 8 Aug 1995 01:33:10 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA20159>; Tue, 8 Aug 1995 01:33:07 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.06369-0@bells.cs.ucl.ac.uk>; Tue, 8 Aug 1995 09:32:00 +0100 To: Tony Li <tli@cisco.com> Cc: mbone Subject: Re: ATM on mbone? In-Reply-To: Your message of "Mon, 07 Aug 95 23:58:16 PDT." <199508080658.XAA05171@greatdane.cisco.com> Date: Tue, 08 Aug 95 09:31:56 +0100 Message-Id: <5943.807870716@cs.ucl.ac.uk> From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> > Can anyone tell me where the ATM links are in the mbone? Thanks. >The following is a complete list of all ATM links in the Internet >backbones which are used to support the mbone: Tony clearly you don't think europe has a backbone, or the UK .... >p.s. Humorous and true! ;-) not terribly funny, and wrong.... typical cisco igno/arro-gance jon ----------------------------------- p.s. despite having plenty of cisco7000s, which we use as traffic shapers [read my message to end to end ages ago about the findings - supported by BAGNet and other IP over ATM backbones:-), ok, ok so you think they're regionals, that's splitting hairs tho'], we cannot use cisco's PIM, for reasons also publicaly explained, so we use cisco + sun (or HP) at the ingress/egress to the ATM, the Sun (or HP) using DVMRP, while the cisco is just a port expander... interesting that we need to use products from both the major vendors to benefit from ARPA's Internet investments to cope with the ITU's major design mistake:-) From list-mgr@ISI.EDU Tue Aug 8 12:46:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04760>; Tue, 8 Aug 1995 01:47:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04740>; Tue, 8 Aug 1995 01:46:37 -0700 Received: from runix.runit.sintef.no by venera.isi.edu (5.65c/5.61+local-22) id <AA04733>; Tue, 8 Aug 1995 01:46:36 -0700 Received: from runit.sintef.no by runix.runit.sintef.no id <18925-0@runix.runit.sintef.no>; Tue, 8 Aug 1995 10:46:13 +0200 Date: Tue, 8 Aug 1995 10:46:11 +0200 (MET DST) From: Steinar Haug <Steinar.Haug@runit.sintef.no> To: Petri Helenius <pete@sms.fi> Cc: Tony Li <tli@cisco.com>, Graeme.Wood@ucs.ed.ac.uk, TMatsumu@asia.adaptec.com, mbone Subject: Re: ATM on mbone? In-Reply-To: <199508080825.LAA01559@silver.sms.fi> Message-Id: <Pine.SUN.3.90.950808104332.14126G-100000@runix> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Steinar.Haug@runit.sintef.no > > I suppose that I _should_ count the NAPs. With the caveat that we're > > talking DS3, not OC-3. > > > So you _ARE_ counting the links internal to the US but you are _NOT_ > counting the links internal to the countries connected to the Internet? > > For example major parts of the FUNET are running ATM at OC-3 speeds for > production use. Maybe we should have a show of hands here. Graeme Wood's statement was > Humorous and totally incorrect. A great part of the European backbone is > running over ATM. A report from Norway is very simple: There is *no* ATM used in the backbone here. (Yes, we have ATM trials.) Other European countries, please? Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug@runit.sintef.no From list-mgr@ISI.EDU Tue Aug 8 14:49:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04938>; Tue, 8 Aug 1995 01:51:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04923>; Tue, 8 Aug 1995 01:50:22 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA04916>; Tue, 8 Aug 1995 01:50:13 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.11/8.6.9) id LAA01623; Tue, 8 Aug 1995 11:49:57 +0300 Date: Tue, 8 Aug 1995 11:49:57 +0300 Message-Id: <199508080849.LAA01623@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Tony Li <tli@cisco.com> Cc: Graeme.Wood@ucs.ed.ac.uk, TMatsumu@asia.adaptec.com, mbone Subject: Re: ATM on mbone? In-Reply-To: <199508080834.BAA13137@greatdane.cisco.com> References: <199508080825.LAA01559@silver.sms.fi> <199508080834.BAA13137@greatdane.cisco.com> Tony Li writes: > > So you _ARE_ counting the links internal to the US but you are _NOT_ > counting the links internal to the countries connected to the Internet? > > For example major parts of the FUNET are running ATM at OC-3 speeds for > production use. > > Seems to me that there's a major choke point between here and there. > Yes, there is couple dual-E1's along the path. Also many US providers have congested East-West links. Pete From list-mgr@ISI.EDU Mon Aug 7 18:53:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05069>; Tue, 8 Aug 1995 01:58:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04983>; Tue, 8 Aug 1995 01:53:37 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA04976>; Tue, 8 Aug 1995 01:53:36 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA13319; Tue, 8 Aug 1995 01:53:33 -0700 Date: Tue, 8 Aug 1995 01:53:33 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199508080853.BAA13319@greatdane.cisco.com> To: Steinar.Haug@runit.sintef.no Cc: pete@sms.fi, tli@cisco.com, Graeme.Wood@ucs.ed.ac.uk, TMatsumu@asia.adaptec.com, mbone In-Reply-To: <Pine.SUN.3.90.950808104332.14126G-100000@runix> (message from Steinar Haug on Tue, 8 Aug 1995 10:46:11 +0200 (MET DST)) Subject: Re: ATM on mbone? All right, all right. So I can see that I'm going to be annoyed to death until I fix what I said. So: There are NO native ATM interfaces in use in the US Internet backbone provider networks which I normally help maintain and to which I have the enable passwords. There, does that help? All right all ready. Quit it with the private mail pelting. I apologize for trying to help. I won't make that mistake again. Tony From list-mgr@ISI.EDU Tue Aug 8 15:01:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05266>; Tue, 8 Aug 1995 02:02:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05257>; Tue, 8 Aug 1995 02:01:23 -0700 Received: from castor.cc.utu.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA05250>; Tue, 8 Aug 1995 02:01:21 -0700 Received: by utu.fi id <179747-2>; Tue, 8 Aug 1995 12:01:10 +0300 Subject: Re: ATM on mbone? From: Matti Aarnio <mea@utu.fi> To: tli@cisco.com (Tony Li) Date: Tue, 8 Aug 1995 12:01:09 +0300 (EET DST) Cc: mbone In-Reply-To: <199508080834.BAA13137@greatdane.cisco.com> from "Tony Li" at Aug 8, 95 01:34:41 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 552 Message-Id: <95Aug8.120110+0300_eet_dst.179747-2+65@utu.fi> > So you _ARE_ counting the links internal to the US but you are _NOT_ > counting the links internal to the countries connected to the Internet? > > For example major parts of the FUNET are running ATM at OC-3 speeds for > production use. > > Seems to me that there's a major choke point between here and there. Yes, FUNET-NORDUnet line is now only 4 Mbps (and not ATM). NORDUnet-USA is 34 Mbps. We are working on intra-NORDUnet lines.. (Telcos can sell us N*2Mbps, but not so easily an OC-3..) > Tony /Matti Aarnio <mea@utu.fi> From list-mgr@ISI.EDU Tue Aug 8 13:17:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05629>; Tue, 8 Aug 1995 02:19:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05614>; Tue, 8 Aug 1995 02:18:23 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-22) id <AA05607>; Tue, 8 Aug 1995 02:18:16 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id LAA14250 (8.6.12/7.4b-FAU);; Tue, 8 Aug 1995 11:17:41 +0200 From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de> Message-Id: <199508080917.LAA14250@faui40.informatik.uni-erlangen.de> Subject: Re: ATM on mbone? To: Steinar.Haug@runit.sintef.no (Steinar Haug) Date: Tue, 8 Aug 1995 11:17:39 +0200 (MET DST) Cc: pete@sms.fi, tli@cisco.com, Graeme.Wood@ucs.ed.ac.uk, TMatsumu@asia.adaptec.com, mbone In-Reply-To: <Pine.SUN.3.90.950808104332.14126G-100000@runix> from "Steinar Haug" at Aug 8, 95 10:46:11 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 529 > A report from Norway is very simple: There is *no* ATM used in the backbone > here. (Yes, we have ATM trials.) > > Other European countries, please? Yes, we do have ATM here, for example an E3 between Erlangen and Munich and quite some other ones (Berlin, Hamburg - Hannover, etc, pp). Yes, we do run Mbone over it. Yes, those are native ATM interface on Cisco 7000, and yes, it was much faster 2 years ago when we ran the same E3 link with HDLC/HSSI. Anyone wants to buy a pair of AGS+ HSSI interfaces ? *sigh* Toerless From list-mgr@ISI.EDU Tue Aug 8 11:33:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06087>; Tue, 8 Aug 1995 02:40:27 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06028>; Tue, 8 Aug 1995 02:35:18 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA06014>; Tue, 8 Aug 1995 02:34:51 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA22847>; Tue, 8 Aug 1995 02:34:50 -0700 Received: from speedy.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.08223-0@bells.cs.ucl.ac.uk>; Tue, 8 Aug 1995 10:33:20 +0100 To: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de> Cc: Steinar.Haug@runit.sintef.no (Steinar Haug), pete@sms.fi, tli@cisco.com, Graeme.Wood@ucs.ed.ac.uk, TMatsumu@asia.adaptec.com, mbone Subject: Re: ATM on mbone? In-Reply-To: Your message of "Tue, 08 Aug 95 11:17:39 +0100." <199508080917.LAA14250@faui40.informatik.uni-erlangen.de> Date: Tue, 08 Aug 95 10:33:13 +0100 Message-Id: <1173.807874393@cs.ucl.ac.uk> From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> >> A report from Norway is very simple: There is *no* ATM used in the backbone >> here. (Yes, we have ATM trials.) >> Other European countries, please? there is soem confusion here - as far as i know, there is no Mbone _service_ as such in most european countries anyhow - at the level the Mbone is supported, it is supported over ATM (at the level ATM is supported....except in the UK, where IP over ATM is supported to a higher level i nthe backbone than ip multicast over ATM) >Yes, we do have ATM here, for example an E3 between Erlangen and Munich >and quite some other ones (Berlin, Hamburg - Hannover, etc, pp). Yes, >we do run Mbone over it. Yes, those are native ATM interface on Cisco 7000, >and yes, it was much faster 2 years ago when we ran the same E3 link with >HDLC/HSSI. Anyone wants to buy a pair of AGS+ HSSI interfaces ? *sigh* i'd be interested in the _status_ of Mbone services (pilot, experimental, supported or what) in different providers' networks - is this documented at all in one place? jon From list-mgr@ISI.EDU Mon Aug 7 21:30:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07446>; Tue, 8 Aug 1995 04:33:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07439>; Tue, 8 Aug 1995 04:32:58 -0700 Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA07432>; Tue, 8 Aug 1995 04:32:57 -0700 From: bmanning@ISI.EDU Posted-Date: Tue, 8 Aug 1995 04:30:22 -0700 (PDT) Message-Id: <199508081130.AA04234@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id <AA04234>; Tue, 8 Aug 1995 04:30:22 -0700 Subject: Re: ATM on mbone? To: pete@sms.fi (Petri Helenius) Date: Tue, 8 Aug 1995 04:30:22 -0700 (PDT) Cc: tli@cisco.com, Graeme.Wood@ucs.ed.ac.uk, TMatsumu@asia.adaptec.com, mbone In-Reply-To: <199508080825.LAA01559@silver.sms.fi> from "Petri Helenius" at Aug 8, 95 11:25:25 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 311 > So you _ARE_ counting the links internal to the US but you are _NOT_ > counting the links internal to the countries connected to the Internet? > > For example major parts of the FUNET are running ATM at OC-3 speeds for > production use. > > Pete > For Tony, the Internet appears to be US centric. --bill From list-mgr@ISI.EDU Mon Aug 7 21:27:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07502>; Tue, 8 Aug 1995 04:34:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07408>; Tue, 8 Aug 1995 04:29:32 -0700 Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA07401>; Tue, 8 Aug 1995 04:29:30 -0700 From: bmanning@ISI.EDU Posted-Date: Tue, 8 Aug 1995 04:27:01 -0700 (PDT) Message-Id: <199508081127.AA04217@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id <AA04217>; Tue, 8 Aug 1995 04:27:01 -0700 Subject: Re: ATM on mbone? To: tli@cisco.com (Tony Li) Date: Tue, 8 Aug 1995 04:27:01 -0700 (PDT) Cc: TMatsumu@asia.adaptec.com, mbone In-Reply-To: <199508080658.XAA05171@greatdane.cisco.com> from "Tony Li" at Aug 7, 95 11:58:16 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 521 > > Can anyone tell me where the ATM links are in the mbone? Thanks. > > The following is a complete list of all ATM links in the Internet > backbones which are used to support the mbone: > > > > Tony > > p.s. Humorous and true! ;-) > Not quite: UCL, UNInett, FUNnet, KTH, SURFnet, ULB/STC, SWITCH, GMD, RedIRIS, UofStuttgart, UofLinz, INFN/CSLET check http://www.nic.surfnet.nl/surfnet/persons/bos/mbone But then Tony may be counting the number of native cisco routers running multicast over ATM. --bill From list-mgr@ISI.EDU Tue Aug 8 01:49:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13333>; Tue, 8 Aug 1995 08:50:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13304>; Tue, 8 Aug 1995 08:50:10 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA13297>; Tue, 8 Aug 1995 08:50:09 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id IAA21404; Tue, 8 Aug 1995 08:49:51 -0700 Date: Tue, 8 Aug 1995 08:49:51 -0700 From: Dino Farinacci <dino@cisco.com> Message-Id: <199508081549.IAA21404@stilton.cisco.com> To: J.Crowcroft@cs.ucl.ac.uk Cc: tli@cisco.com, mbone In-Reply-To: Jon Crowcroft's message of Tue, 08 Aug 95 09:31:56 +0100 <5943.807870716@cs.ucl.ac.uk> Subject: ATM on mbone? >> p.s. despite having plenty of cisco7000s, which we use as traffic >> shapers [read my message to end to end ages ago about the findings - >> supported by BAGNet and other IP over ATM backbones:-), ok, ok so you >> think they're regionals, that's splitting hairs tho'], >> we cannot use cisco's PIM, for reasons also publicaly explained, so we >> use cisco + sun (or HP) at the ingress/egress to the ATM, the Sun (or >> HP) using DVMRP, while the cisco is just a port expander... Jon, we have addressed the concerns of the European MBONE community by implementing either PIM over DVMRP unicast routing or multicast static routing in release 11.0. In fact, PIM over DVMRP unicast routing has been put into 10.2 and 10.3 due to the high demand. Its been available for a couple months now. No one has turned it on, go figure. PIM over DVMRP unicast routing allows one to do sparse-mode PIM over the MBONE topology. PIM RPFs for both the shared and source tree using the DVMRP routing table. Are you interested in deploying this? I talked to several folks that run the ATM net over there and they indicated this is exactly what they need. Dino From list-mgr@ISI.EDU Tue Aug 8 18:32:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15585>; Tue, 8 Aug 1995 09:33:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15566>; Tue, 8 Aug 1995 09:32:50 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA15558>; Tue, 8 Aug 1995 09:32:48 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA00637>; Tue, 8 Aug 1995 09:32:47 -0700 Received: from cronus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.24123-0@bells.cs.ucl.ac.uk>; Tue, 8 Aug 1995 17:32:18 +0100 To: Dino Farinacci <dino@cisco.com> Cc: mbone Subject: Re: ATM on mbone? In-Reply-To: Your message of "Tue, 08 Aug 95 08:49:51 PDT." <199508081549.IAA21404@stilton.cisco.com> Date: Tue, 08 Aug 95 17:32:14 +0100 Message-Id: <1622.807899534@cs.ucl.ac.uk> From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> >>> p.s. despite having plenty of cisco7000s, which we use as traffic >>> shapers [read my message to end to end ages ago about the findings - >>> supported by BAGNet and other IP over ATM backbones:-), ok, ok so you >>> think they're regionals, that's splitting hairs tho'], >>> we cannot use cisco's PIM, for reasons also publicaly explained, so we >>> use cisco + sun (or HP) at the ingress/egress to the ATM, the Sun (or >>> HP) using DVMRP, while the cisco is just a port expander... > Jon, we have addressed the concerns of the European MBONE community by > implementing either PIM over DVMRP unicast routing or multicast static > routing in release 11.0. In fact, PIM over DVMRP unicast routing has been > put into 10.2 and 10.3 due to the high demand. Its been available for > a couple months now. No one has turned it on, go figure. > PIM over DVMRP unicast routing allows one to do sparse-mode PIM over the > MBONE topology. PIM RPFs for both the shared and source tree using the > DVMRP routing table. > Are you interested in deploying this? I talked to several folks that run > the ATM net over there and they indicated this is exactly what they need this is excellent information - thanks for this - we can use this (mark says) in the UK, and beyond - plus lots of places o nthe ATM pilot round europe could start using this now meanwhile, UCL CS havn't a cisco with the horsepower to run it, but then we have a 150MIPS HP workstatio nto do the job, so we're not fussed thanks for this... jon From list-mgr@ISI.EDU Tue Aug 8 02:38:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15814>; Tue, 8 Aug 1995 09:38:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15781>; Tue, 8 Aug 1995 09:38:17 -0700 Received: from servo.ipsilon.com (foobar.Ipsilon.COM) by venera.isi.edu (5.65c/5.61+local-22) id <AA15774>; Tue, 8 Aug 1995 09:38:16 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id JAA09334; Tue, 8 Aug 1995 09:35:59 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: <v02130502ac4d3e98d053@[204.160.241.224]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 8 Aug 1995 09:38:32 -0700 To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> From: hinden@Ipsilon.COM (Bob Hinden) Subject: Re: ATM on mbone? Cc: mbone >i'd be interested in the _status_ of Mbone services (pilot, >experimental, supported or what) in different providers' networks - is >this documented at all in one place? Another question of interest: Is anyone using ATM to provide MBONE services for anything other than point-to-point circuits (e.g., any native ATM point-to-multipoint, or similar)? Bob From list-mgr@ISI.EDU Tue Aug 8 19:22:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18129>; Tue, 8 Aug 1995 10:25:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18092>; Tue, 8 Aug 1995 10:24:48 -0700 Received: from clus1.ulcc.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA18085>; Tue, 8 Aug 1995 10:24:46 -0700 Received: from clus1.ulcc.ac.uk (clus1.ulcc.ac.uk [192.12.72.60]) by clus1.ulcc.ac.uk (8.6.9/8.6.9) with SMTP id SAA06374; Tue, 8 Aug 1995 18:22:13 +0100 Message-Id: <199508081722.SAA06374@clus1.ulcc.ac.uk> X-Authentication-Warning: clus1.ulcc.ac.uk: Host clus1.ulcc.ac.uk didn't use HELO protocol To: Dino Farinacci <dino@cisco.com> Cc: J.Crowcroft@cs.ucl.ac.uk, tli@cisco.com, mbone Subject: Re: ATM on mbone? Reply-To: s.brown@ulcc.ac.uk X-Organisation: University of London Computer Centre X-Phone: +44 171 405 8400 ext 406 In-Reply-To: Message from Dino Farinacci of Tue, 08 Aug 95 08:49:51 -0800. <199508081549.IAA21404@stilton.cisco.com> Date: Tue, 08 Aug 95 18:22:12 +0100 From: Syngen Brown <syngen@clus1.ulcc.ac.uk> > Jon, we have addressed the concerns of the European MBONE community by > implementing either PIM over DVMRP unicast routing or multicast static > routing in release 11.0. In fact, PIM over DVMRP unicast routing has been > put into 10.2 and 10.3 due to the high demand. Its been available for > a couple months now. No one has turned it on, go figure. > > PIM over DVMRP unicast routing allows one to do sparse-mode PIM over the > MBONE topology. PIM RPFs for both the shared and source tree using the > DVMRP routing table. > > Are you interested in deploying this? I talked to several folks that run > the ATM net over there and they indicated this is exactly what they need. What are the implications of this for maintenance of pruning across a DVMRP-PIM boundary? Our position in the UK is still that we will not be deploying anything which will compromise the integrity of pruning. Syngen > > Dino From list-mgr@ISI.EDU Tue Aug 8 10:11:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20786>; Tue, 8 Aug 1995 11:11:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20754>; Tue, 8 Aug 1995 11:11:21 -0700 Received: from davinci.gmu.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA20742>; Tue, 8 Aug 1995 11:11:20 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id OAA13638; Tue, 8 Aug 1995 14:11:02 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199508081811.OAA13638@davinci.gmu.edu> Subject: Mbone over slip? To: mbone Date: Tue, 8 Aug 1995 14:11:02 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 613 Ok, now that you have stopped laughing... I realize the limitations of this, however, I would like to know if there is any way that this can be done? I am referring to a small feed, perhaps just voice or data, channeled through a system that is already on a network with an mbone feed. I was thinking perhaps a version of mrouted that prunes everything except the actual data requested through SD. Is this possible? Michael -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Tue Aug 8 22:24:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22492>; Tue, 8 Aug 1995 11:25:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22189>; Tue, 8 Aug 1995 11:24:37 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-22) id <AA22125>; Tue, 8 Aug 1995 11:24:32 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id UAA13531 (8.6.12/7.4b-FAU);; Tue, 8 Aug 1995 20:24:25 +0200 From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de> Message-Id: <199508081824.UAA13531@faui40.informatik.uni-erlangen.de> Subject: Re: ATM on mbone? To: dino@cisco.com (Dino Farinacci) Date: Tue, 8 Aug 1995 20:24:23 +0200 (MET DST) Cc: J.Crowcroft@cs.ucl.ac.uk, tli@cisco.com, mbone In-Reply-To: <199508081549.IAA21404@stilton.cisco.com> from "Dino Farinacci" at Aug 8, 95 08:49:51 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1448 > PIM over DVMRP unicast routing allows one to do sparse-mode PIM over the > MBONE topology. PIM RPFs for both the shared and source tree using the > DVMRP routing table. I hate to repeat myself but to put the argument up again in this forum: That's really a good thing to do, but it doesn't solve the one problem that 9at least in my impression) hits people with cisco systems hardest: They've got some backbone MBONE connections to peoples without Ciscos and for those they will still need pure dvmrp routers or pruning will not correct work on these direct links. I understand that real dvmrp pruning support may once make it into IOS, but i'm still wondering about this scheduling of feature implementation. As for me i could have waited for fast switching multicasting and neat sd support and all the other goodies until that damned-dvmrp thing would have been implemented. My biggest concern is just connectivity. Well i guess we're not the usual cisco user. Given the porsche kind of price of ciscos people might also expect the same behaviour: First the speed and later the comfort *grin*. I just hope it's something like this and not the fear that better dvmrp support will reduce the chance of people deploying PIM. Just the opposite is true in my opinion: it's just that bad DVMRP support will reduce the chance of people deployinh ciscos for multicasting due to connectivity and routing problems. Best regards Toerless From list-mgr@ISI.EDU Tue Aug 8 09:50:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09429>; Tue, 8 Aug 1995 16:54:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09158>; Tue, 8 Aug 1995 16:50:23 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA09151>; Tue, 8 Aug 1995 16:50:22 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id QAA09411; Tue, 8 Aug 1995 16:50:18 -0700 Date: Tue, 8 Aug 1995 16:50:18 -0700 From: Dino Farinacci <dino@cisco.com> Message-Id: <199508082350.QAA09411@stilton.cisco.com> To: s.brown@ulcc.ac.uk Cc: J.Crowcroft@cs.ucl.ac.uk, tli@cisco.com, mbone In-Reply-To: Syngen Brown's message of Tue, 08 Aug 95 18:22:12 +0100 <199508081722.SAA06374@clus1.ulcc.ac.uk> Subject: ATM on mbone? >> What are the implications of this for maintenance of pruning across a >> DVMRP-PIM boundary? Our position in the UK is still that we will not >> be deploying anything which will compromise the integrity of pruning. This is independent of Pruning/Grafting into the DVMRP multicast cloud. BTW, we are working on DVMRP Pruning/Grafting. Dino From list-mgr@ISI.EDU Tue Aug 8 10:10:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10401>; Tue, 8 Aug 1995 17:16:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10118>; Tue, 8 Aug 1995 17:10:51 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA10111>; Tue, 8 Aug 1995 17:10:50 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id RAA09944; Tue, 8 Aug 1995 17:10:16 -0700 Date: Tue, 8 Aug 1995 17:10:16 -0700 From: Dino Farinacci <dino@cisco.com> Message-Id: <199508090010.RAA09944@stilton.cisco.com> To: Toerless.Eckert@Informatik.Uni-Erlangen.de Cc: J.Crowcroft@cs.ucl.ac.uk, tli@cisco.com, mbone, multicast-support@cisco.com In-Reply-To: Toerless Eckert's message of Tue, 8 Aug 1995 20:24:23 +0200 (MET DST) <199508081824.UAA13531@faui40.informatik.uni-erlangen.de> Subject: ATM on mbone? >> Well i guess we're not the usual cisco user. Given the porsche kind >> of price of ciscos people might also expect the same behaviour: First >> the speed and later the comfort *grin*. I just hope it's something like >> this and not the fear that better dvmrp support will reduce the chance >> of people deploying PIM. Just the opposite is true in my opinion: it's >> just that bad DVMRP support will reduce the chance of people deployinh >> ciscos for multicasting due to connectivity and routing problems. Sigh, cisco bashing again, Toerless, you'll be the first to test our DVMRP Pruning/Grafting implementation. I take your comments as a firm commitment to doing so. No one is grinning and no one ever claimed full DVMRP support in ciscos in past releases. Dino From list-mgr@ISI.EDU Tue Aug 8 12:32:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15710>; Tue, 8 Aug 1995 19:33:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15683>; Tue, 8 Aug 1995 19:32:36 -0700 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA15676>; Tue, 8 Aug 1995 19:32:35 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA25844; Tue, 8 Aug 95 19:32:31 PDT Message-Id: <9508090232.AA25844@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 8 Aug 1995 19:32:34 -0700 To: mbone From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: ATM on mbone? What does it mean? Regarding comments such as: >From: Steinar Haug <Steinar.Haug@runit.sintef.no> >Maybe we should have a show of hands... I am a little confused about just what it would/does mean to have MBone running "on" ATM. I think this was mentioned previously in this thread, but would ATM point to point links (e.g. as I believe ESnet is using) for link level communication between ordinary IP routers "count"? If more than this is implied (and such point to point uses of ATM I don't consider very valuable? or interesting) then I would like to understand better just what is implied. If direct use of ATM multicast virtual circuits (e.g as with PVCs in Bagnet) is implied then I would be interested to hear (perhaps not to the list) about any such ATM multicast use, whether pilot or production. My guess is that that IP multicast over unicast ATM (PVCs or SVCs but including ATM switching, e.g. "Classic" IP over ATM) is the most likely thing for it (MBone "on" ATM) to mean at this point. Can anyone confirm, deny, or clarify this (mis?)understanding? If this is what it means, isn't this essentially equivalent to asking how much of the Internet "backbone" (infrastructure, whatever) is being run with IP over ATM? Does using MBone (IP multicast) over IP over ATM contribute anything of interest over just using IP over ATM? --Jed http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Sun Aug 9 08:05:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18214>; Tue, 8 Aug 1995 21:09:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18200>; Tue, 8 Aug 1995 21:09:07 -0700 Received: from milpitas.adaptec.com by venera.isi.edu (5.65c/5.61+local-22) id <AA18192>; Tue, 8 Aug 1995 21:09:06 -0700 Received: from corpmail.adaptec.com ([162.62.105.19]) by milpitas.adaptec.com (4.1/SMI-4.1) id AA13335; Tue, 8 Aug 95 21:06:46 PDT Received: from by corpmail.adaptec.com (4.1/SMI-4.1) id AB12054; Tue, 8 Aug 95 21:02:34 PDT X-Nvlenv-01Date-Transferred: 8-Aug-1995 21:00:53 -0400; at Mentor.Adaptec X-Nvlenv-01Date-Posted: 09-Aug-1995 12:06:06 -0400; at AJL.Adaptec Date: 09 Aug 95 12:05:00 EDT From: TMatsumu@Asia.adaptec.com Subject: Re: ATM on mbone? What does it mean? Message-Id: <D6BE2830016B1673@-SMF-> In-Reply-To: <9508090232.AA25844@ocfmail.ocf.llnl.gov> Reply-To: TMatsumu@Asia.adaptec.com References: <9508090232.AA25844@ocfmail.ocf.llnl.gov> To: mbone Jed, I'm not sure if you'd consider this pilot or production, but we ran Multicast ATM over LAN Emulation specifications at last month's Tokyo Interop for a week. I believe Bay Networks supplied the servers, and we had two Sbus ATM clients showing live video (various sources, TV, videos, live camera) in our booth, as well as in Bay Network's booth. There were about 20 other vendors hooked up to the ATM backbone, but only a handful were broadcasting the MCS, others were doing AVI or P to P/MP video conference apps. etc. Ted Matsumura, Adaptec ATM Program Manager ------------- Original Text From jed@llnl.gov (James E. [Jed] Donnelley), on 8/8/95 7:32 PM: Regarding comments such as: >From: Steinar Haug <Steinar.Haug@runit.sintef.no> >Maybe we should have a show of hands... I am a little confused about just what it would/does mean to have MBone running "on" ATM. I think this was mentioned previously in this thread, but would ATM point to point links (e.g. as I believe ESnet is using) for link level communication between ordinary IP routers "count"? If more than this is implied (and such point to point uses of ATM I don't consider very valuable? or interesting) then I would like to understand better just what is implied. If direct use of ATM multicast virtual circuits (e.g as with PVCs in Bagnet) is implied then I would be interested to hear (perhaps not to the list) about any such ATM multicast use, whether pilot or production. My guess is that that IP multicast over unicast ATM (PVCs or SVCs but including ATM switching, e.g. "Classic" IP over ATM) is the most likely thing for it (MBone "on" ATM) to mean at this point. Can anyone confirm, deny, or clarify this (mis?)understanding? If this is what it means, isn't this essentially equivalent to asking how much of the Internet "backbone" (infrastructure, whatever) is being run with IP over ATM? Does using MBone (IP multicast) over IP over ATM contribute anything of interest over just using IP over ATM? --Jed http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Wed Aug 9 12:27:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24966>; Wed, 9 Aug 1995 01:33:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AB24916>; Wed, 9 Aug 1995 01:28:20 -0700 Received: from cismsun.univ-lyon1.fr by venera.isi.edu (5.65c/5.61+local-22) id <AA24905>; Wed, 9 Aug 1995 01:28:16 -0700 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id KAA21729; Wed, 9 Aug 1995 10:28:01 +0200 Message-Id: <199508090828.KAA21729@cismsun.univ-lyon1.fr> Subject: Re: ATM on mbone? To: dino@cisco.com (Dino Farinacci) Date: Wed, 9 Aug 1995 10:27:59 +0200 (MET DST) From: "Lucia Gradinariu" <lucia@univ-lyon1.fr> Cc: mbone In-Reply-To: <199508090010.RAA09944@stilton.cisco.com> from "Dino Farinacci" at Aug 8, 95 05:10:16 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3387 > > >> Well i guess we're not the usual cisco user. Given the porsche kind > >> of price of ciscos people might also expect the same behaviour: First > >> the speed and later the comfort *grin*. I just hope it's something like > >> this and not the fear that better dvmrp support will reduce the chance > >> of people deploying PIM. Just the opposite is true in my opinion: it's > >> just that bad DVMRP support will reduce the chance of people deployinh > >> ciscos for multicasting due to connectivity and routing problems. > > Sigh, cisco bashing again, Toerless, you'll be the first to test our > DVMRP Pruning/Grafting implementation. I take your comments as a firm > commitment to doing so. >***************************************************************************** > No one is grinning and no one ever claimed full DVMRP support in ciscos > in past releases. > > Dino >***************************************************************************** That is once too often! Remember the beta-test we've done last year for IOS10.2, our reports on how to configure PIM-DVMRP tunnel without "imploding" DVMRP routing tables on Mbone and on the deployment of packets exchanged between mrouted and PIM. Brief, skipping through the folder of Cisco beta-test mails, the following paragraph may change your opinion (although it didn't help the beta-test to run better :-(! ): Dino Farinacci ecrit: >From dino@cisco.com Wed Oct 26 18:07 MET 1994 Date: 26 Oct 1994 10:07:26 -0700 From: Dino Farinacci <dino@cisco.com> Subject: 10.2(1) DVMRP prune & graft In-Reply-To: Gilles Rech's message of Wed, 26 Oct 1994 09:52:35 +0100 (MET) <199410260852.AA164941555@cismhp.univ-lyon1.fr> To: gilles@CISM.UNIV-LYON1.FR Cc: lucia@CISM.UNIV-LYON1.FR, vmuzzoli@cisco.com, beta@cisco.com, vboulang@cisco.com Message-Id: <199410261707.KAA25826@feta.cisco.com> Content-Transfer-Encoding: 7BIT >> Don't you think that PRUNE & GRAFT are more urgent than ASK_NEIGHBORS, >> in perspective of a migration of Mbone from DVMRP to PIM ? I'm People want to know where ciscos are in a DVMRP path, that is why we will answer mrinfo requests (ASK_NEIGHBORS). We are reluctant to do a full blown DVMRP because PIM is the better solution. >> CISCO), but the remote DVMRP router manager will be reluctant to set up >> a tunnel with me if he knows I can't prune. Multicast applications are >> not yet welcome by network providers because of the bandwith issue; >> the pruning mechanism is necessary to make them accepted. Then have him run a PIM router at his site. This is precisely why sparse-mode PIM was designed. >> Have you received my previous message about the "ip dvmrp metric" >> command ? Looking at Mbone forums, I can see I've not been the only one >> to fall into the trap (bug ?). There is nothing cisco can do about this. I have put as much fool-proof hooks in there. By default, routes are not flooded into the MBONE. The problem is that people are misconfiguring their routers and don't understand what the "ip dvmrp metric" command does. Dino -- Our Mbone tunnel provider is still not convinced he has to run a PIM router even though he has a Cisco router. So Toerless is right but it took one year to say this on a public list! Lucia GRADINARIU CISM-Univ. Cl. Bernard, Lyon, FRANCE lucia@univ-lyon1.fr From list-mgr@ISI.EDU Wed Aug 9 10:55:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25642>; Wed, 9 Aug 1995 02:01:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25455>; Wed, 9 Aug 1995 01:56:03 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA25448>; Wed, 9 Aug 1995 01:56:02 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA27361>; Wed, 9 Aug 1995 01:56:01 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.06587-0@bells.cs.ucl.ac.uk>; Wed, 9 Aug 1995 09:55:42 +0100 To: jed@llnl.gov (James E. [Jed] Donnelley) Cc: mbone Subject: Re: ATM on mbone? What does it mean? In-Reply-To: Your message of "Tue, 08 Aug 95 19:32:34 PDT." <9508090232.AA25844@ocfmail.ocf.llnl.gov> Date: Wed, 09 Aug 95 09:55:39 +0100 Message-Id: <1118.807958539@cs.ucl.ac.uk> From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> >I am a little confused about just what it would/does mean to have >MBone running "on" ATM. there are about 7 things it can mean 1/ you are using ATM point to point PVCs between mrouted suns (or HPs) 2/ you are using ATM point to point PVCs between real routers, and mbone tunnels across that 3/ you are using ATM point to point PVCs between real routers running MOSPF, PIM, DVMRP or CBT ... 4/ you are using ATM point to multipoint PVCs between any of the above 5/ you are able to distinguish the mbone IP traffic from other IP traffic on the ATM hop, and give it sepeartate controlled QoS (instead, or as well as using the mrouted rate limiter to put a mx on how much is sent, to provide a min...) 6/ Any of the above with SVCs, but driven simple by IP traffic arrival and routing driving a call setup... 7/ any of the above with SVCs but with Q.2931 and RSVP interacting.... as far as i can tell, we've got to 2, except for BAGNet which has done 3.... any advance on 3? jon From list-mgr@ISI.EDU Wed Aug 9 01:00:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03131>; Wed, 9 Aug 1995 08:01:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03114>; Wed, 9 Aug 1995 08:01:15 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA03107>; Wed, 9 Aug 1995 08:01:14 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15431(3)>; Wed, 9 Aug 1995 08:00:49 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 9 Aug 1995 08:00:42 -0700 To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> Cc: mbone, deering@parc.xerox.com Subject: Re: ATM on mbone? What does it mean? In-Reply-To: J.Crowcroft's message of Wed, 09 Aug 95 01:55:39 -0800. <1118.807958539@cs.ucl.ac.uk> Date: Wed, 9 Aug 1995 08:00:40 PDT Sender: Steve Deering <deering@parc.xerox.com> From: Steve Deering <deering@parc.xerox.com> Message-Id: <95Aug9.080042pdt.75270@digit.parc.xerox.com> Jon, > as far as i can tell, we've got to 2, except for BAGNet which has done > 3.... BAGNet has done 4, i.e., it uses point-to-multipoint PVCs. I *think* it is using general-purpose workstations running mrouted as the endpoints of those PVCs. > any advance on 3? Proceeding down your list would be retarding, not advancing. Steve From list-mgr@ISI.EDU Wed Aug 9 17:41:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09573>; Wed, 9 Aug 1995 08:42:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09561>; Wed, 9 Aug 1995 08:42:37 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA09553>; Wed, 9 Aug 1995 08:42:36 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA04646>; Wed, 9 Aug 1995 08:42:34 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.21723-0@bells.cs.ucl.ac.uk>; Wed, 9 Aug 1995 16:41:33 +0100 From: Mark Handley <M.Handley@cs.ucl.ac.uk> Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: mbenson@davinci.gmu.edu (Michael Benson) Cc: mbone Subject: Re: Mbone over slip? In-Reply-To: Your message of "Tue, 08 Aug 95 14:11:02 EDT." <199508081811.OAA13638@davinci.gmu.edu> Date: Wed, 09 Aug 95 16:41:32 +0100 Message-Id: <8227.807982892@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >I am referring to a small feed, perhaps just voice or data, channeled >through a system that is already on a network with an mbone feed. I >was thinking perhaps a version of mrouted that prunes everything except >the actual data requested through SD. Is this possible? Yes, we were looking at doing this for use over ISDN. It is possible (and easier with a modified sd), we plan to do it, we haven't yet... You probably want to run application specific mixers on the mbone site, so when several people start speaking at once, you don't saturate your ISDN link. None of this is very hard, but it does require work... Mark From list-mgr@ISI.EDU Wed Aug 9 09:10:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25396>; Wed, 9 Aug 1995 14:09:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25377>; Wed, 9 Aug 1995 14:09:05 -0700 Received: from titan.iingen.unam.mx ([132.248.156.245]) by venera.isi.edu (5.65c/5.61+local-22) id <AA25370>; Wed, 9 Aug 1995 14:09:03 -0700 Received: by titan.iingen.unam.mx (940816.SGI.8.6.9/940406.SGI.AUTO) for mbone@isi.edu id PAA06252; Wed, 9 Aug 1995 15:10:16 -0600 Date: Wed, 9 Aug 1995 15:10:16 -0600 From: mbone@titan.iingen.unam.mx (Cristina Casimiro) Message-Id: <199508092110.PAA06252@titan.iingen.unam.mx> To: mbone Hi, We have sent several msg asking for a feed to joining to the MBONE. Our network provider is ANS, we have seen that they can provide this feed. We are going to use a SUN SPARCClassic as the mroute, the videoconferencing tools are up-and-running. Could it be possible that somebody give us a pointer to get the feed ? Thanks in advance Cristina Casimiro Coordinacion de Sistemas de Computo Instituto de Ingenieria - UNAM Phone (525)6 22 80 92 Fax (525)6 22 80 91 From list-mgr@ISI.EDU Thu Aug 10 03:04:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01143>; Wed, 9 Aug 1995 16:06:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01122>; Wed, 9 Aug 1995 16:06:12 -0700 Received: from noc.BelWue.DE by venera.isi.edu (5.65c/5.61+local-22) id <AA01115>; Wed, 9 Aug 1995 16:06:04 -0700 Received: from pi4.informatik.uni-mannheim. (pi4.informatik.uni-mannheim.de [134.155.48.96]) by noc.belwue.de with SMTP id BAA04118 (8.6.12/IDA-1.6); Thu, 10 Aug 1995 01:05:02 +0200 Received: from eratosthenes by pi4.informatik.uni-mannheim.de (5.65/BelWue-1.1DEC) id AA19837; Thu, 10 Aug 95 01:04:45 +0200 From: whd@pi4.informatik.uni-mannheim.de (Wieland Holfelder) Received: by eratosthenes; (5.65/1.1.8.2/02May95-1040AM) id AA20488; Thu, 10 Aug 1995 01:04:44 +0200 Message-Id: <9508092304.AA20488@eratosthenes> Subject: Re: ATM on mbone? What does it mean? To: deering@parc.xerox.com (Steve Deering) Date: Thu, 10 Aug 1995 01:04:44 +0200 (MET DST) Cc: J.Crowcroft@cs.ucl.ac.uk, mbone In-Reply-To: <95Aug9.080042pdt.75270@digit.parc.xerox.com> from "Steve Deering" at Aug 9, 95 08:00:40 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1285 Steve Deering writes: > > as far as i can tell, we've got to 2, except for BAGNet which has done > > 3.... > BAGNet has done 4, i.e., it uses point-to-multipoint PVCs. I *think* it > is using general-purpose workstations running mrouted as the endpoints of > those PVCs. Actually the endpoints in BAGNet don't necessarily need to run mrouted and in fact most of them do not (to my last knowledge). The configuration is more or less static which means that - depending on the ATM interfaces and driver software - the mapping from point to multipoint PVCs to a particular class D address may even be hard-wired. Which, of course, isn't the perfect solution and should only be seen as a workaround for those interfaces that don't support full ip-multicast in the classical ip over atm approach yet. -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder University of Mannheim Praktische Informatik IV Email: whd@pi4.informatik.uni-mannheim.de L 15,16 Fax : +49-621-292-5745 68131 Mannheim Phone: +49-621-292-3300 Germany http://www.informatik.uni-mannheim.de/~whd ------------------------------------------------------------------------------- From list-mgr@ISI.EDU Wed Aug 9 14:26:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05924>; Wed, 9 Aug 1995 17:32:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05915>; Wed, 9 Aug 1995 17:31:25 -0700 Received: from ACADEM.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA05908>; Wed, 9 Aug 1995 17:31:24 -0700 Received: (from sob@localhost) by academ.com (8.6.12/8.6.9) id TAA24319; Wed, 9 Aug 1995 19:26:23 -0500 Message-Id: <199508100026.TAA24319@academ.com> From: sob@academ.com (Stan Barber) Date: Wed, 9 Aug 1995 19:26:22 CDT In-Reply-To: mbone@titan.iingen.unam.mx (Cristina Casimiro) "" (Aug 9, 3:10pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: mbone@titan.iingen.unam.mx (Cristina Casimiro), mbone You can contact the folks at the UNAM NOC about this and they can setup a feed from SESQUINET for UNAM and other sites in Mexico. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From list-mgr@ISI.EDU Wed Aug 9 13:34:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09019>; Wed, 9 Aug 1995 18:45:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08787>; Wed, 9 Aug 1995 18:39:42 -0700 Received: from ss20 (ss20.mty.itesm.mx) by venera.isi.edu (5.65c/5.61+local-22) id <AA08780>; Wed, 9 Aug 1995 18:39:41 -0700 Received: by ss20 (5.x/SMI-SVR4) id AA29348; Wed, 9 Aug 1995 19:34:23 -0600 From: lcorlay@ss20.mty.itesm.mx Message-Id: <9508100134.AA29348@ss20> Subject: Re: your mail To: sob@academ.com (Stan Barber) Date: Wed, 9 Aug 1995 19:34:23 -0600 (CST) Cc: mbone In-Reply-To: <199508100026.TAA24319@academ.com> from "Stan Barber" at Aug 9, 95 07:26:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Stan we can give them mbone feed. We are receiving the mbone feed from sprintlink, and passing it to another universities in mexico Lino > > You can contact the folks at the UNAM NOC about this and they can setup > a feed from SESQUINET for UNAM and other sites in Mexico. > > -- > Stan | Academ Consulting Services |internet: sob@academ.com > Olan | For more info on academ, see this |uucp: amdahl!academ!sob > Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. > From list-mgr@ISI.EDU Wed Aug 9 13:47:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13350>; Wed, 9 Aug 1995 20:48:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13338>; Wed, 9 Aug 1995 20:48:05 -0700 Received: from blob.best.net by venera.isi.edu (5.65c/5.61+local-22) id <AA13331>; Wed, 9 Aug 1995 20:48:05 -0700 Received: from rsf.vip.best.com (rsf.vip.best.com [204.156.129.162]) by blob.best.net (8.6.12/8.6.5) with SMTP id UAA04976 for <mbone@ISI.EDU>; Wed, 9 Aug 1995 20:47:59 -0700 Date: Wed, 9 Aug 1995 20:47:59 -0700 Message-Id: <199508100347.UAA04976@blob.best.net> X-Sender: rsf@shell1.best.com X-Mailer: Windows Eudora Light Version 1.5.2b1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: Ross Finlayson <finlayson@live.com> Subject: Re: Mbone over slip? >>I am referring to a small feed, perhaps just voice or data, channeled >>through a system that is already on a network with an mbone feed. I >>was thinking perhaps a version of mrouted that prunes everything except >>the actual data requested through SD. Is this possible? > >Yes, we were looking at doing this for use over ISDN. It is possible >(and easier with a modified sd), we plan to do it, we haven't yet... I may be missing something here, but I'm not sure what SD (or SDP) has to do with the problem of getting MBone over a SLIP (or PPP or ISDN) connection; it seems like the completely wrong level. Isn't all that's needed is for the node that's sitting at the other end of your SLIP connection to be able to intercept the node's IGMP requests, and join/leave multicast groups as appropriate? Is the problem that current SLIP (etc.) routers don't do this? (If they don't, then they're broken, IMHO.) If the SLIP (etc.) routers really are 'deficient' (to use a gentler word :-), then I guess there's not much more you can do than set up a remotely-controlled mrouted-like server that sets up/tears down point-to-point connections on demand. To avoid packet duplication you'd probably want to have this running on the same node as your SLIP (etc.) router, which further points out that this is something that the SLIP (etc.) router should really be doing itself, using IGMP as the "remote control" mechanism. I gather you're talking about using the "SD" program as the remote control mechanism. This is pretty gross (as you'd probably agree), because it requires that MBone applications be launched by "SD", and doesn't help you in handling the leaving of the appropriate group(s) when these applications exit. The trouble is, I can't think of a better solution either :-( Ross. From list-mgr@ISI.EDU Thu Aug 10 11:30:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16562>; Wed, 9 Aug 1995 22:31:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16551>; Wed, 9 Aug 1995 22:30:30 -0700 Received: from castor.cc.utu.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA16544>; Wed, 9 Aug 1995 22:30:27 -0700 Received: by utu.fi id <179835-3>; Thu, 10 Aug 1995 08:30:19 +0300 Subject: Re: Mbone over slip? From: Matti Aarnio <mea@utu.fi> To: finlayson@live.com (Ross Finlayson) Date: Thu, 10 Aug 1995 08:30:13 +0300 (EET DST) Cc: mbone In-Reply-To: <199508100347.UAA04976@blob.best.net> from "Ross Finlayson" at Aug 9, 95 08:47:59 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 2226 Message-Id: <95Aug10.083019+0300_eet_dst.179835-3+45@utu.fi> > >>I am referring to a small feed, perhaps just voice or data, channeled > >>through a system that is already on a network with an mbone feed. I > >>was thinking perhaps a version of mrouted that prunes everything except > >>the actual data requested through SD. Is this possible? > > > >Yes, we were looking at doing this for use over ISDN. It is possible > >(and easier with a modified sd), we plan to do it, we haven't yet... > > I may be missing something here, but I'm not sure what SD (or SDP) has to do > with the problem of getting MBone over a SLIP (or PPP or ISDN) connection; > it seems like the completely wrong level. Isn't all that's needed is for > the node that's sitting at the other end of your SLIP connection to be able > to intercept the node's IGMP requests, and join/leave multicast groups as > appropriate? Is the problem that current SLIP (etc.) routers don't do this? > (If they don't, then they're broken, IMHO.) All routers are (/have been) lacking somewhat in this respect. Ideal would be to have a SLIP-/WHATEVER-server (which is a small router in itself, anyway) doing full prune/craft of mbone, AND the other end of the link doing the same. Umm.. Of course if the point-to-point link (SLIP/PPP) would flag MULTICAST capability, then perhaps starting a multicast application in the remote host (like SD) should report joining that particular group over the p2p line. To a server such a situation looks like it has changeing set of ethernets on which it should do mrouting. If remote user wants to run mrouted (for a local lan, for example), link should not be flagged MULTICAST, but mrouted on the server should accept tunnel formation. To do it - with *BSD -based machines perhaps ? - several changes need to be made into mrouted, however as my own hacking platform is Linux, I can't do/try it.. (My time-slicing priorities are elsewere as well..) (Btw: I WOULD do this on our SLIP/PPP modem server, if it would have mrouted kernel aspects -- but it runs on Linux 1.2.8..) Like people have said, relying on "sd" to determine what should be delivered is incomplete method (if "wrong" is too strong word..) > Ross. /Matti Aarnio <mea@utu.fi> From list-mgr@ISI.EDU Thu Aug 10 10:26:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22324>; Thu, 10 Aug 1995 01:39:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22033>; Thu, 10 Aug 1995 01:27:28 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA22026>; Thu, 10 Aug 1995 01:27:27 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA26520>; Thu, 10 Aug 1995 01:27:23 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.05812-0@bells.cs.ucl.ac.uk>; Thu, 10 Aug 1995 09:26:58 +0100 To: Ross Finlayson <finlayson@live.com> Cc: mbone Subject: Re: Mbone over slip? In-Reply-To: Your message of "Wed, 09 Aug 95 20:47:59 PDT." <199508100347.UAA04976@blob.best.net> Date: Thu, 10 Aug 95 09:26:55 +0100 Message-Id: <6264.808043215@cs.ucl.ac.uk> From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> >I may be missing something here, but I'm not sure what SD (or SDP) has to do >with the problem of getting MBone over a SLIP (or PPP or ISDN) connection; see below... jon Mark Handley & Jon Crowcroft & Saleem Bhatti & Ian Wakeman Unicast access to the Mbone - The UMbone. Extending the Session Description protocol to provide mbone access from unicast sites (behind ISDN or other links into the net). Components: Session Directory Servers (SDS). Mixers (Application level multicast to Unicast Traffic Forwarder). A Modified SDP client. Two new protocols: 1/ Session Lookup Protocol SLP 2/ Remote Multicast Join/Leave Protocol RLJMP Lookup and Control: Somewhere in the mbone, there is a mixer (or several), known to session directories servers around the place. Ideally these mixers will be situated close to the point where the ISDN/Unicast feed hits the Mbone. [In RTP, this "mixer" is known as a translator]. A Session Directory Server is a daemon that listens to SDP announcements and caches them. On demand, it provides the latest list to clients that query it. When a client queries an SDS , the sessions reported include the mixer to use for the session with a unicast session address, but the media all have multicast address. The choice of mixer is dependant on the locations of the SDS and the client. A unicast SDP client program runs on a unicast host at a site 1 or more hops removed from the mbone (i.e. one incapable of using multicast IP). On demand, the SDP client contacts an SDS to get the current list of sessions, by making a TCP call to a well known port and forumalting an HTTP GET request. The returned type is (TBD) and contains the list of all sessions. I.e. the SLP is based on HTTP over TCP. A user then starts the media associated with a particular session by clicking on that entry in the SDP (modified) client. The modified client then sends a remote "join" request to the mixer address (either configured, or retrieved from the SLP lookup), and starts the media application on the unicast address+port of their choice. The RMJLP join message contains an SDP session description, but with added media fields ("mix-to") with the media tool's unicast address and port. RMJLP messages are text based SDP v2 messages sent in a TCP connection to the mixer on a well known port (TBD) and preceded by a line containing the RMJLP command ("JOIN" or "LEAVE"). The mixer joins the group, and adds the maplet from this group to the "mix-to" site to its forwarding table. The session directory client on the monitors the reciver program, and when it exits, sends a RMJLP leave message to the mixer. Mixer Operation: The mixer is an application level program that is table driven. Basically, it is a cousin of the NV to CUSeeMe reflector program (or monstermash program), that receives multicast, and forwards to unicast, and receives on unicast and forwards to multicast based on maplets based on table entries created and deleted by RLJMP messages. The mixer may optionally apply priorities to the traffic (a la Class Based Queueing). For example a site might be down the end of a 64kbps ISDN dial up uncast link to the remote mbone. A default might be that a mixer priorities audio, then whiteboard, then video. An implementation hack might be that the forwarding loop of the mixer simply ignores overlimit input queues (this is tricky if people multiplex media on the same port and the same multicast address or we want to treat different sources differently, but will be easy otherwise). i.e. while(1) { readmask = setupSelectMaskForThisTimeAround(); select(readmask); dealWithReadDescritporsAndUpdateClassUsage(mask); } As well as configured defaults at the mixer, we may want to specify priorities. One possibility is to implement an RSVP client in the modified session descriptor client and an RSVP server in the mixer. Easier might be a simply mix-to-priority. To decide on overlimit actions, the mixer also needs to know the bandwidth between it and the unicast client. This can be configured or monitored through spying on RR messages perhaps or (TBD). Finally, a refinement of the model above might permit a user to specify priorities w.r.t sources of traffic (Source Descriptor fields or source IP address + port if avaialble can be used to decide which class a flow belongs to). The bandwith (shared link) between the mixer and the unicast site is gleaned through some other process (e.g. configured through management). For further study is how an overlimit action might trigger demand for more bandwidth, again through some other configured information (basically derived from policies at the mixer and user site concerning costs and so forth). Soft State The mixer MUST fail to not forwarding to a unicast site, since the act of forwarding uses possibly expensive bandwidth. This is aceived by timing out maplets in the table. Though the entry can be kept, it is marked as "idle" after timeout T1, and only deleted after a longer timeout T2 (TBD). The entry is refreshed by repeated RLJMP messages from the modified SD client at the unicast site. The refresh time (T3) is hopefully shorter than the idle timeout T1. Typical values of T1 will be set long enough to not incur costly control traffic on the link, and T2 short enough to close the link after application failure or abort/hangup by abrupt user without incurring costly forwarding of multicast traffic down the unicast link. Unicast Hop: The mixer and session directory server may be co-located. Further, they may be co-located on the unicast router immediately at the end of the unicast hop from the user site to the mbone. More likely, they are a little way off from this. If the unicast hop is a bandwidth on demand circuit, the RLJMP is a way of implicitly controlling whether traffic goes to and from on this hop (keeping any potentially costly call open). T3 can be set high (its really a resource protection timeout). Example values might be T3 = 3600 secs, T2 = 120 secs and T1 = 60 secs. Futures: 1. You can connect two mbones with two umbone configurations - simplest example is a small site (e.g. a school) with a unicast router and a local mbone router and an ISDN link and a unciast router. There might be administrative reasons for not running a tunnel over the link. 2. You can extend this model to allow non-mbone-application level gatewaying - e.g. an analog phone gateway. A touch tone dial interface to a remote SD client would be the obvious control interface [c.f.. Internet Phone model in the glorious rfc 1789]. Simplifications The modified sd server and mixer may be co-located or even the same process. In some cases (e.g. no ISDN), the SLP step might not be needed, and the user site might simply get session advertisements mixed down to them always. In other cases, the RLJMP step might not be needed, if there were few sessions, and all could be accomodated. Implementation The Session Directory tool is being modified to accomodate SLP, and to be able to run as a daemon/server without a GUI. The mash program can be extended easily to accomodate RLJMP, and then enhanced through a user space version of CBQ to provide appropriate action when inbound traffic to the mixer exceeds outbound bandwidth. References RTP: A Transport Protocol for Real-Time Applications Internet Engineering Task Force Audio-Video Transport WG Schulzrinne/Casner/Frederick/Jacobson GMD/ISI/Xerox/LBL draft-ietf-avt-rtp-07.txt SDP: Session Description Protocol Mark Handley/Van Jacobson UCL/LBL 26th March Internet Engineering Task Force MMUSIC WG INTERNET-DRAFT 1995 Expires: 26th Sept 1995 draft-ietf-mmusic-sdp-00.ps INETPhone: Telephone Services and Servers on Internet C. Yang, University of North Texas Request for Comments: 1789 Category: Informational April 1995 The Design and Implementation of Class Based Queueing in a Streams Module I. Wakeman, A. Ghosh, J. Crowcroft, V. Jacobson, S. Floyd Usenix '95 Conference, January 16-20 1995, New Orleans ftp://cs.ucl.ac.uk/darpa/monstermash.[c1].Z telnet://cs.ucl.ac.uk/~mhandley/sdr/* From list-mgr@ISI.EDU Fri Aug 11 05:20:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23911>; Thu, 10 Aug 1995 02:33:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23757>; Thu, 10 Aug 1995 02:22:48 -0700 Received: from mail.telstra.com.au by venera.isi.edu (5.65c/5.61+local-22) id <AA23750>; Thu, 10 Aug 1995 02:22:45 -0700 Received: from mail_gw.fwall.telecom.com.au(192.148.147.10) by mail via smap (V1.3) id sma028885; Thu Aug 10 18:05:34 1995 Received: from shiva.trl.oz.au(137.147.20.34) by mail_gw.telecom.com.au via smap (V1.3) id sma026777; Thu Aug 10 19:21:01 1995 Received: from [137.147.13.75] (arethusa.trl.OZ.AU [137.147.13.75]) by shiva.trl.OZ.AU (8.6.10/8.6.12) with SMTP id TAA14111; Thu, 10 Aug 1995 19:20:57 +1000 Message-Id: <199508100920.TAA14111@shiva.trl.OZ.AU> X-Sender: oneill@shiva (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Aug 1995 19:20:59 +1000 To: mbone From: c.oneill@trl.oz.au (Chris O'Neill) Subject: Re: IETF transmission quality... Cc: avg@sprint.net Vadim Antonov wrote: >>> A typical ethernet breaks down at about 3Mbps *total*, and the >>> E-1 pipe can easily run at 4Mbps (it's full duplex). >You are also forgetting that point-to-point pipes tend to deliver >more-less constant-rate traffic, which does not fit very well into >the stochastic Ethernet model. I.e. you end up with D/M/1 kind of >situation, with performance quite worse than M/M/1 model of Ethernet What makes you think ethernet follows a Markovian service discipline and that an ethernet with Markovian arrivals follows the M/M/1 queuing model. It doesn't. The service behaviour is in one sense worse than Markovian. Also, what makes you think that performance of D/M/1 is worse than M/M/1 (as far as queuing delay is concerned I take it)? It isn't. >The fact is neither of studies you mentioned is directly applicable, >as even the crude queueing theory models behave quite differently >for LAN-with-hosts and LAN-with-WAN-gateway. I should point out the obvious case of a single station feeding an ethernet. In this case it can saturate the ethernet, i.e. 10 Mbps. I would imagine that having two stations feeding an ethernet would get somewhere between this and the capacity with a large number of stations which is about 3.4 Mbps for average queuing delay equal to average packet transmission time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris O'Neill Telstra Research Labs Melbourne Australia c.oneill@trl.oz.au From list-mgr@ISI.EDU Thu Aug 10 01:10:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01659>; Thu, 10 Aug 1995 08:16:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01568>; Thu, 10 Aug 1995 08:10:54 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA01561>; Thu, 10 Aug 1995 08:10:52 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15287(1)>; Thu, 10 Aug 1995 08:10:42 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Thu, 10 Aug 1995 08:10:34 -0700 To: Matti Aarnio <mea@utu.fi> Cc: mbone Subject: Re: Mbone over slip? In-Reply-To: Your message of "Wed, 09 Aug 95 22:30:13 PDT." <95Aug10.083019+0300_eet_dst.179835-3+45@utu.fi> Date: Thu, 10 Aug 1995 08:10:31 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Aug10.081034pdt.177475@crevenia.parc.xerox.com> In message <95Aug10.083019+0300_eet_dst.179835-3+45@utu.fi> Matti Aarnio writes: > If remote user wants to run mrouted (for a local lan, for example), > link should not be flagged MULTICAST, but mrouted on the server > should accept tunnel formation. Actually, a point-to-point MULTICAST link is a perfectly fine MBONE transit; all of DARTNet is native multicasting over T1 links. > To do it - with *BSD -based machines perhaps ? - several changes > need to be made into mrouted No changes to mrouted are needed, as long as each link is on its own subnet. The BSD multicasting model requires each interface to have their own subnets, since it forwards based on source address. Bill From list-mgr@ISI.EDU Thu Aug 10 21:42:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02496>; Thu, 10 Aug 1995 08:47:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02321>; Thu, 10 Aug 1995 08:42:49 -0700 Received: from castor.cc.utu.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA02314>; Thu, 10 Aug 1995 08:42:47 -0700 Received: by utu.fi id <179871-1>; Thu, 10 Aug 1995 18:42:40 +0300 Subject: Re: Mbone over slip? From: Matti Aarnio <mea@utu.fi> To: fenner@parc.xerox.com (Bill Fenner) Date: Thu, 10 Aug 1995 18:42:33 +0300 (EET DST) Cc: mbone In-Reply-To: <95Aug10.081034pdt.177475@crevenia.parc.xerox.com> from "Bill Fenner" at Aug 10, 95 08:10:31 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1941 Message-Id: <95Aug10.184240+0300_eet_dst.179871-1+144@utu.fi> > In message <95Aug10.083019+0300_eet_dst.179835-3+45@utu.fi> Matti Aarnio writes: > > If remote user wants to run mrouted (for a local lan, for example), > > link should not be flagged MULTICAST, but mrouted on the server > > should accept tunnel formation. > > Actually, a point-to-point MULTICAST link is a perfectly fine MBONE transit; > all of DARTNet is native multicasting over T1 links. Umm... Yes, it is a corollary from mrouted-enet-mrouted connection, isn't it ? > > To do it - with *BSD -based machines perhaps ? - several changes > > need to be made into mrouted > > No changes to mrouted are needed, as long as each link is on its own > subnet. The BSD multicasting model requires each interface to have > their own subnets, since it forwards based on source address. Speaking without reading the source (a serious sinn, I admit), I was thinking of two kinds of situations on server which has interfaces coming and going (a dialup connection server/router): (Each link is in its own subnet) - Remote is incapable/unwilling to run mrouted, but understands multicast (like lonely PC user via dialup link.) - Remote is actually a network, where smart router dials the service provider router/server, and estabilishes MBONE tunnel. Questions (unclearly stated previously): - Will the current mrouted notice that there is a new interface, and that it can send traffic there ? (Multicasting SLIP/PPP to remote PC.) - Can it accept tunnel formation over a newly activated point-to- point link without advance configuration into /etc/mrouted.conf ? I am thinking of cases where we can get dozens of active tunnels (each thru their own pipe) from a pool of several hundred (users) each with their own IP-numbers - or sharing a dynamic pool.. In my current case the V.34 modems limit maximum speed, but who knows when we have dialup-ATM at home ? > Bill /Matti Aarnio <mea@utu.fi> From list-mgr@ISI.EDU Thu Aug 10 09:30:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06377>; Thu, 10 Aug 1995 09:41:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05888>; Thu, 10 Aug 1995 09:30:40 -0700 Received: from sydney.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA05880>; Thu, 10 Aug 1995 09:30:38 -0700 Received: (from thalerd@localhost) by sydney.eecs.umich.edu (8.6.8/8.6.10) id MAA16966; Thu, 10 Aug 1995 12:29:36 -0400 Date: Thu, 10 Aug 1995 12:26:03 From: "Dave Thaler" <thalerd@eecs.umich.edu> Subject: SNMP-mrouted/mstat announcements Message-Id: <19950810122603.29534@sydney.eecs.umich.edu> To: mbone 1) The SNMP-mrouted distribution directory has moved (along with our project home page - see signature). The new location is: ftp://ftp.merit.edu/research.and.development/mbone/ A description of the distribution files is available at: http://www.merit.edu/research.and.development/mbone/.download.html 2) The mstat utility now works on a DEC Alpha. Mstat can be obtained from the directory above. 3) The SNMP-3.6 release contained a bug in which only the first entry in the DVMRP Neighbor table was available. A patch to snmp.c is available for those with the old SNMP-3.6 code as snmp.c.diff. This patch has already been applied to the distribution files now labelled as the SNMP-3.6.1 release. For example, the current snmp-mrouted source is: ftp://ftp.merit.edu/research.and.development/mbone/snmp-mrouted3.6.1.tar.Z -- ----------------------------------------------------------------------- Dave Thaler thalerd@eecs.umich.edu Project home page: http://www.merit.edu/research.and.development/mbone/ From list-mgr@ISI.EDU Thu Aug 10 03:36:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10160>; Thu, 10 Aug 1995 10:48:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09644>; Thu, 10 Aug 1995 10:37:43 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA09637>; Thu, 10 Aug 1995 10:37:42 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15102(3)>; Thu, 10 Aug 1995 10:37:03 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Thu, 10 Aug 1995 10:36:59 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Matti Aarnio <mea@utu.fi> Cc: mbone Subject: Re: Mbone over slip? In-Reply-To: Your message of "Thu, 10 Aug 95 08:42:33 PDT." <95Aug10.184240+0300_eet_dst.179871-1+144@utu.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Aug 1995 10:36:44 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Aug10.103659pdt.177475@crevenia.parc.xerox.com> In message <95Aug10.184240+0300_eet_dst.179871-1+144@utu.fi> Matti Aarnio writes: > - Remote is incapable/unwilling to run mrouted, but understands > multicast (like lonely PC user via dialup link.) > > - Remote is actually a network, where smart router dials the > service provider router/server, and estabilishes MBONE tunnel. These are both handled by multicast-capable SLIP interfaces. In the first case, you run IGMP on the SLIP interface. In the second, you run mrouted and it will peer across the SLIP interface. > Questions (unclearly stated previously): > > - Will the current mrouted notice that there is a new interface, > and that it can send traffic there ? (Multicasting SLIP/PPP > to remote PC.) Yes, it will notice when an interface that was configured down when it started comes up, and will start sending IGMP queries over it. > - Can it accept tunnel formation over a newly activated point-to- > point link without advance configuration into /etc/mrouted.conf ? No, it cannot handle a tunnel that is not in /etc/mrouted.conf . However, it *can* handle a new native peering over the P-P link; put an mrouted on each side and they will discover each other and talk to each other using native multicast. This eliminates the tunnel encapsulation overhead on this link, and is already dynamically possible. Of course, running real MBONE feeds over even a v.34 connection is a pretty silly thing to try. What you really want to do is application-level mixing and re-encoding on the high-bandwidth side, so that you can re-compress everyone's 70kbps PCM into 17kbps GSM, or even 9kbps LPC. Some of Ross Finlayson's firewall work might be applicable here, at least to launch the mixers on the high-bandwidth side. And, of course, the work being done at UCL which Jon Crowcroft just posted something about. Bill From list-mgr@ISI.EDU Thu Aug 10 10:22:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29819>; Thu, 10 Aug 1995 17:32:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28906>; Thu, 10 Aug 1995 17:22:07 -0700 Received: from upeksa.sdsc.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA28898>; Thu, 10 Aug 1995 17:22:06 -0700 Received: by upeksa.sdsc.edu id RAA03239; Thu, 10 Aug 1995 17:22:05 -0700 From: kc@upeksa.sdsc.edu (k claffy) Message-Id: <199508110022.RAA03239@upeksa.sdsc.edu> Subject: mbone tunnel to sdsc To: postmster, mbone Date: Thu, 10 Aug 1995 17:22:05 -0700 (PDT) Cc: hwb@upeksa.sdsc.edu (Hans-Werner Braun), rpg@sdsc.edu (Rich Gallup), dombrowh@sdsc.edu (Jay Dombrowski) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 519 [could you make sure this gets to the mbone administrator at ISI?] were you relying on an mbone tunnel to sdsc? the disk on sdsc's mrouter crashed this weekend, and the system won't get rebuilt till next week it looks like (we're going to use this opportunity to put mrouted3.6 on there) but i was wondering, when we do, will you want to tunnel to us (you haven't had a tunnel from us for a week, i assume. please let me know if you have a different impression.) or did already have coverage elsewhere? tnx k From list-mgr@ISI.EDU Thu Aug 10 10:24:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00785>; Thu, 10 Aug 1995 17:41:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29646>; Thu, 10 Aug 1995 17:30:22 -0700 Received: from inet-gw-2.pa.dec.com by venera.isi.edu (5.65c/5.61+local-22) id <AA29637>; Thu, 10 Aug 1995 17:30:21 -0700 Received: from bigpink.pa.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA29165; Thu, 10 Aug 95 17:24:32 -0700 Received: by bigpink.pa.dec.com; id AA01208; Thu, 10 Aug 1995 17:24:40 -0700 Message-Id: <9508110024.AA01208@bigpink.pa.dec.com> To: rem-conf@es.net, mbone Cc: bagnet@george.lbl.gov, berc@pa.dec.com, templin@pa.dec.com, ajay@zk3.dec.com Subject: *Alpha version* Pruning Multicast for Digital Unix 3.2 Date: Thu, 10 Aug 95 17:24:40 -0700 From: berc@pa.dec.com X-Mts: smtp We're making an *alpha* kit of pruning IP-multicast code for Digital Unix 3.2 available for those who would like to help test it. The kit replaces several .o files and has binaries for several IP multicast tools (mrouted-3.6, mrinfo, etc.). You can't run the new mrouted without the kernel modifications. Although we think it works, Digital makes no warrantees against damage or loss due to bugs, fire, flood, acts of God, or Severe Tire Damage MCasts. The kit is available at: http://chocolate.research.digital.com/mbone/ipm35_decosf_v32.tar.Z Please send any comments to Ajay Kacharni, ajay@zk3.dec.com. lance Lance M Berc Systems Research Center Digital Equipment Corporation berc@src.dec.com From list-mgr@ISI.EDU Fri Aug 11 20:37:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02007>; Thu, 10 Aug 1995 17:57:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01228>; Thu, 10 Aug 1995 17:47:03 -0700 Received: from staff.cs.su.OZ.AU by venera.isi.edu (5.65c/5.61+local-22) id <AA01216>; Thu, 10 Aug 1995 17:47:00 -0700 Message-Id: <199508110047.AA01216@venera.isi.edu> Received: from staff.cs.su.oz.au by staff.cs.su.OZ.AU (mail from chrisw for mbone@ISI.EDU) with MHSnet; Fri, 11 Aug 1995 10:44:25 +1000 Date: Fri, 11 Aug 1995 10:37:35 +1000 From: chrisw@staff.cs.su.oz.au (Christoph Willing) Subject: sd protocol? To: mbone Reply-To: chrisw@cs.su.oz.au I am trying to implement multicasting in an experimental operating system and have got to the stage of implementing an sd type of tool. Is the source code for sd available anywhere? or source for something similar ? In fact I'd be happy if I could just get hold of the actual message protocol and structure. I could hopefully work out the rest of it. chris willing From list-mgr@ISI.EDU Fri Aug 11 05:26:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03681>; Thu, 10 Aug 1995 18:39:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03328>; Thu, 10 Aug 1995 18:27:25 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA03319>; Thu, 10 Aug 1995 18:27:23 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id DAA11970; Fri, 11 Aug 1995 03:26:16 +0200 Message-Id: <199508110126.DAA11970@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: chrisw@cs.su.oz.au Cc: mbone, e93_mda@it.kth.se Subject: Re: sd protocol? In-Reply-To: Your message of "Fri, 11 Aug 1995 10:37:35 +1000." <199508110047.AA01216@venera.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 11 Aug 1995 03:26:11 +0200 From: Magnus <e93_mda@it.kth.se> > I am trying to implement multicasting in an experimental operating system > and have got to the stage of implementing an sd type of tool. Is the source > code for sd available anywhere? or source for something similar ? Van Jacobson at LBL has written it, but has not realeased the sources yet (to my knowledge... I migth be blind). Take a look at ftp://ftp.ee.lbl.gov/conferencing/sd/ > In fact I'd be happy if I could just get hold of the actual message protocol > and structure. I could hopefully work out the rest of it. Van, help us on this one :-) Magnus Danielson From list-mgr@ISI.EDU Fri Aug 11 11:51:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16157>; Fri, 11 Aug 1995 03:14:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16053>; Fri, 11 Aug 1995 03:03:29 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA16046>; Fri, 11 Aug 1995 03:03:19 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA02193>; Fri, 11 Aug 1995 03:03:17 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.08006-0@bells.cs.ucl.ac.uk>; Fri, 11 Aug 1995 10:51:56 +0100 From: Mark Handley <M.Handley@cs.ucl.ac.uk> Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: Magnus <e93_mda@it.kth.se> Cc: chrisw@cs.su.oz.au, mbone Subject: Re: sd protocol? In-Reply-To: Your message of "Fri, 11 Aug 95 03:26:11 +0100." <199508110126.DAA11970@piraya.electrum.kth.se> Date: Fri, 11 Aug 95 10:51:53 +0100 Message-Id: <14098.808134713@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >> I am trying to implement multicasting in an experimental operating system >> and have got to the stage of implementing an sd type of tool. Is the source >> code for sd available anywhere? or source for something similar ? > >Van Jacobson at LBL has written it, but has not realeased the sources yet (to >my knowledge... I migth be blind). >Take a look at ftp://ftp.ee.lbl.gov/conferencing/sd/ Take a look at http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.01.ps and the minutes of the Stockholm MMUSIC working group. There will be a new internet draft as soon as I have time, and compliant code shortly after. Mark From list-mgr@ISI.EDU Sat Aug 12 04:19:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05496>; Sat, 12 Aug 1995 09:20:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05488>; Sat, 12 Aug 1995 09:19:29 -0700 Received: from barajas.fciencias.unam.mx by venera.isi.edu (5.65c/5.61+local-22) id <AA05481>; Sat, 12 Aug 1995 09:19:28 -0700 Received: by barajas.fciencias.unam.mx (920330.SGI/921111.SGI.AUTO) for mbone@ISI.EDU id AA02102; Sat, 12 Aug 95 10:19:48 -0600 Date: Sat, 12 Aug 95 10:19:48 -0600 From: jluis@barajas.fciencias.unam.mx (Jose Luis Torres Rodriguez) Message-Id: <9508121619.AA02102@barajas.fciencias.unam.mx> To: mbone Subject: unsubscribe unsubscribe thanks. From list-mgr@ISI.EDU Sat Aug 12 18:23:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17773>; Sat, 12 Aug 1995 18:25:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17757>; Sat, 12 Aug 1995 18:23:55 -0700 Received: from bee.uspnet.usp.br by venera.isi.edu (5.65c/5.61+local-22) id <AA17750>; Sat, 12 Aug 1995 18:23:51 -0700 Return-Path: uratsuka@lsi.usp.br Received: from jaguar.lsi.usp.br (jaguar.lsi.usp.br [143.107.3.253]) by bee.uspnet.usp.br (8.6.10/SPARC10-CCE2.0)id WAA21076 Date: Sat, 12 Aug 1995 22:21:41 +24000 From: Andre Uratsuka Manoel <uratsuka@lsi.usp.br> To: mbone <mbone> Subject: Establishing a tunnel From Brazil to MCI Message-Id: <Pine.SGI.3.90.950812213258.12089B-100000@jaguar.lsi.usp.br> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello all, I am from the Laboratory of Integrated Systems at the University of Sao Paulo (USP), Brazil. We are since the last year trying to arrange things so that we would get connected to the MBONE. We first tried to establish a tunnel to the Fermilab, but the lack of bandwidth made it impossible earlier. Now, FAPESP, USP's access provider, is stablishing a T-1 link to MCI. It will probably be on-line in the next few days so FAPESP told me to go ahead and get an MBONE feed. Multicast traffic will probably not pass through the T-1 link, but through a slower parallel 256K link that is currently our main Internet connection. This is going to be the first non-temporary MBone tunnel in Brazil, so there is no other possible tunnel provider besides MCI. Who should I talk to in MCI? Regards, Andre From list-mgr@ISI.EDU Mon Aug 14 06:25:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20824>; Mon, 14 Aug 1995 09:07:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16423>; Mon, 14 Aug 1995 07:26:23 -0700 Received: from watserv2.uwaterloo.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA16416>; Mon, 14 Aug 1995 07:26:22 -0700 Received: from watarts.uwaterloo.ca ([129.97.42.10]) by watserv2.uwaterloo.ca with SMTP id <90308-4>; Mon, 14 Aug 1995 10:26:19 -0400 Received: from cnts4p03.uwaterloo.ca by watarts.uwaterloo.ca; (5.65/1.1.8.2/13Jun95-0851AM) id AA09106; Mon, 14 Aug 1995 10:26:14 -0400 Message-Id: <9508141426.AA09106@watarts.uwaterloo.ca> X-Sender: nrandall@watarts X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Aug 1995 10:25:54 -0400 To: mbone From: Neil Randall <nrandall@watarts.uwaterloo.ca> Subject: MBONE development? Is someone there doing MBONE work at this point? I'm doing a book on the MBONE, and I'd like to speak with someone about past and future developments. On the phone, if possible (my dime), but e-mail is fine as well. Thanks Neil Randall nrandall@watarts.uwaterloo.ca Author: Teach Yourself the Internet Co-author: The World Wide Web Unleashed From list-mgr@ISI.EDU Mon Aug 14 17:57:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26353>; Mon, 14 Aug 1995 10:50:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20807>; Mon, 14 Aug 1995 09:06:59 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA20800>; Mon, 14 Aug 1995 09:06:58 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA16105>; Mon, 14 Aug 1995 09:06:55 -0700 Message-Id: <199508141606.AA16105@quark.isi.edu> Received: from thud.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.21304-0@bells.cs.ucl.ac.uk>; Mon, 14 Aug 1995 16:57:37 +0100 To: mbone Subject: Asymmetric tunnel report Date: Mon, 14 Aug 95 16:57:39 +0100 From: I.Wakeman@cs.ucl.ac.uk 28 tunnels removed from this list, but around 30 new tunnels appearing. Doesn't look good folks. Please run your eyes over this to see if you manage or are connected to one of the listed tunnels. Bad metrics cause black holes and worse, whilst bad ttls cause some very annoying propagation effects. cheers ian and atanu r-s-hub.fnal.gov t kashgar.fnal.gov [1/1][1/0] thor.ece.uc.edu m cyhan.csm.uc.edu [1/2][64/64] mbone.hq.nasa.gov t microgravity.msad.hq.nasa.gov [1/1][32/8] sura-mp2-pe.sura.net t mbone.sura.net [1/1][32/1] fibula.cic.net mt davros.acs.ohio-state.edu [2/1][64/32] se1-eth2-2.net.ohio-state.edu t davros.acs.ohio-state.edu [1/1][11/0] sprint-oeb-e0.columbus.oar.net mt ernie.bgsu.edu [2/1][32/0] sprint-oeb-e0.columbus.oar.net mt thor.ece.uc.edu [2/1][32/0] sprint-oeb-e0.columbus.oar.net mt hobbes.mathsci.denison.edu [2/1][32/0] grid.arl.mil t les7.arl.mil [2/2][8/2] poly.arl.mil t les7.arl.mil [2/2][8/2] sphinx.cc.ic.ac.uk t noc.cam.ja.net [1/1][24/64] sura-mp2-pe.sura.net t cpk-ms1.sura.net [1/1][32/1] mbone.direcpc.com t cpk-ms1.sura.net [1/1][32/64] faraday.gmu.edu t noc.hpc.org [1/1][64/16] a-wing.jvnc.net t noc.hpc.org [1/1][64/32] electron-a.nasa.atd.net m copernicus.nrl.atd.net [4/1][1/1] butthead.atglab.bls.com t bstfirewall.atglab.bls.com [1/1][8/1] 139.133.210.26 t jal.cc.abdn.ac.uk [1/1][24/16] fuji.ethz.ch t mbone-transit.ethz.ch [1/1][1/16] directory.funet.fi t stockholm.mbone.ebone.net [1/1][40/32] lunde.runit.sintef.no t stockholm.mbone.ebone.net [1/1][40/32] patella.uni-c.dk t stockholm.mbone.ebone.net [1/1][40/32] fmroute1-1.exp.edf.fr t stockholm.mbone.ebone.net [4/4][64/48] qhepuc.oeaw.ac.at mt mbone.aco.net [1/3][32/1] 128.130.5.129 t mbone.aco.net [1/1][32/64] sintef-gw.sintef.no t lunde.runit.sintef.no [1/1][6/0] sarastro.nbi.dk t patella.uni-c.dk [1/1][16/32] wasat.astro.ku.dk t patella.uni-c.dk [1/1][16/1] noc.near.net mt MBONE.CIT.CORNELL.EDU [7/1][32/64] RASTRO.MIT.EDU m MBONE.CIT.CORNELL.EDU [7/1][64/64] tipper.oit.unc.edu t mbone.ncren.net [1/1][32/10] mbone.merit.edu t a-wing.jvnc.net [1/1][32/64] 130.94.40.201 t a-wing.jvnc.net [1/1][64/0] bamboo.nas.nasa.gov t mbone2.nsi.nasa.gov [1/1][32/16] wehib.wehi.edu.au t vitruvius.arbld.unimelb.EDU.AU [1/1][16/1] springfield.mame.mu.OZ.AU t vitruvius.arbld.unimelb.EDU.AU [1/1][16/32] wtn-mp1-mae-east-pe.sura.net t wtn-ms1.sura.net [1/1][32/1] sprint-oeb-e0.columbus.oar.net t ns1.sprintlink.net [1/1][64/0] thinkpix.com t ns1.sprintlink.net [1/1][64/1] mbone.tamu.edu t ns1.sprintlink.net [1/1][64/255] boston.terra.net t ns1.sprintlink.net [1/1][64/0] nevis3.nevis.columbia.edu t 192.12.15.1 [1/1][32/1] kermit.PrakInf.TU-Ilmenau.DE t herkules-f.hrz.tu-chemnitz.de [1/1][1/32] risum.prz.tu-berlin.de t charles.prz.tu-berlin.de [1/1][1/2] janus.gw.utexas.edu t mis.bus.utexas.edu [1/1][32/1] mbone.chalmers.se t cth-fddi-gw.chalmers.se [1/1][0/1] merkurius.lu.se t half.dna.lth.se [1/1][8/4] news.spb.su t nic.edu.fi [1/1][64/16] alcor.vc.cvut.cz t pklunx.cvut.cz [1/1][64/1] hp18.fzu.cz mt pklunx.cvut.cz [1/3][64/32] leporello.cs.unibo.it t astra.infn.it [1/1][24/128] rip.funet.fi t directory.funet.fi [1/1][12/16] charybdis.ipac.caltech.edu t elxr-fddi.jpl.nasa.gov [1/1][48/16] corvette.jpl.nasa.gov t elxr-fddi.jpl.nasa.gov [1/1][8/1] monte.cscs.ch mt swiMA8.switch.ch [2/0][16/0] oncidium.cscs.ch mt swiMA8.switch.ch [2/0][16/0] tibia.cic.net t mbone.merit.edu [1/1][64/32] Clouso.CRIM.CA t atlantis.CC.McGill.CA [1/1][32/16] loon.Music.McGill.CA t atlantis.CC.McGill.CA [1/1][8/1] cisco-red.iss.nus.sg t venus.cc.nus.sg [1/1][1/0] sununx.iscs.nus.sg t venus.cc.nus.sg [1/1][4/16] exxilon.xx.rmit.EDU.AU t aggedor.rmit.EDU.AU [1/1][16/32] wtn-mp1-pe.sura.net t trivia.CSS.GOV [1/1][1/32] mbone.sunet.se t merkurius.lu.se [1/1][8/16] mbone.sunet.se t aquila.udac.uu.se [1/1][8/16] robur.slu.se t aquila.udac.uu.se [1/1][8/16] mbone.sunet.se t mbone.nada.kth.se [1/1][8/16] rip.funet.fi m uiah.fi [2/1][16/16] rip.funet.fi mt noknic.nokia.com [3/1][32/16] news.spb.su t arch.kiae.su [1/1][5/4] aquarius.Relcom.EU.net t arch.kiae.su [1/1][3/1] nastol.astro.lu.se mt hydra.sics.se [1/3][16/1] mbone.sunet.se t lower-gw.sunet.se [1/1][8/16] visitor1.larc.nasa.gov t ra-iris18.arc.nasa.gov [1/1][1/64] gauss.univ-mrs.fr m whisky.ens-lyon.fr [3/1][32/32] nintendo.enst-bretagne.fr mt matisse.univ-rennes1.fr [1/3][32/1] CVUT-gw.cvut.cz t ns.felk.cvut.cz [1/1][1/0] sun4.iihe.ac.be m sideral.rediris.es [1/4][48/48] corbu.cnrs-mrs.fr t gauss.univ-mrs.fr [1/1][16/32] jupiter.cc.nagasaki-u.ac.jp m study-rs.mech.nagasaki-u.ac.jp [2/1][5/5] solaris.cc.vt.edu t isb-ags.e6.cns.vt.edu [1/1][32/1] ns1.nysernet.net t startide.ctr.columbia.edu [1/1][32/64] sat.t.u-tokyo.ac.jp t 130.69.127.51 [1/1][1/64] ny-columbia-1-s0-T3.nysernet.net t ns1.nysernet.net [1/1][64/0] sbrick.cs.sunysb.edu mt ns1.nysernet.net [1/4][64/1] madoka.its.rpi.edu t ns1.nysernet.net [1/1][64/128] hibp7.ecse.rpi.edu t madoka.its.rpi.edu [1/1][2/1] cosmos.kaist.ac.kr t mindlle.cse.cau.ac.kr [3/3][1/16] mr1.lbl.gov m vet.ee.lbl.gov [4/3][1/1] jupiter.cc.nagasaki-u.ac.jp m nic.karrn.ad.jp [1/5][64/64] csis100.csis.oita-u.ac.jp t nic.karrn.ad.jp [1/1][96/64] pero.sysa.csse.yamaguchi-u.ac.jp t nic.karrn.ad.jp [1/1][64/160] Utumno.BARRNET.NET m matmos.hpl.hp.com [2/1][64/64] Dragonlance.Stanford.EDU t MightyDog.Stanford.EDU [2/2][16/32] Waimea.Stanford.EDU t MightyDog.Stanford.EDU [2/2][16/32] tempest.Stanford.EDU t MightyDog.Stanford.EDU [1/1][16/32] winona.Stanford.EDU t MightyDog.Stanford.EDU [1/1][16/1] 129.213.128.9 t Utumno.BARRNET.NET [1/1][32/1] ace.mid.net mt hobbes.ksu.ksu.edu [3/1][1/32] mbone.ucar.edu t nist-gw.ucar.edu [1/1][64/24] tempeh.sesqui.net t PAVLOV.SSCTR.BCM.TMC.EDU [1/1][1/64] atlantis-null.brooks.af.mil t mbone-dmz.nosc.mil [1/1][64/32] defiant-bb.cs.odu.edu t galileo.cs.odu.edu [1/1][1/32] nersc-noc.es.net t llnl-mr2.es.net [1/1][1/0] cleland.phyast.pitt.edu m oday-114.psc.edu [1/3][64/64] YERTLE.DCCS.UPENN.EDU t oday-114.psc.edu [1/1][64/2] slayer.its.Hawaii.Edu mt spike-3.uhcc.Hawaii.Edu [1/3][7/1] sahara.ics.Hawaii.Edu t spike-3.uhcc.Hawaii.Edu [1/1][7/64] cosmos.kaist.ac.kr t h2o.kotel.co.kr [1/1][32/16] oversteer.library.uwa.edu.au mt diablox.uwa.edu.au [1/3][8/1] gin.ee.umanitoba.ca t Clouso.CRIM.CA [1/1][32/64] bonnou.kddlabs.co.jp t mbone.inoc.imnet.ad.jp [1/1][64/96] suzume.crl.go.jp m mbone.inoc.imnet.ad.jp [1/5][32/32] bandai.cc.kyushu-u.ac.jp t nakasu.csce.kyushu-u.ac.jp [1/1][1/16] ccmng.riken.go.jp m ns.riken.go.jp [1/3][1/1] dns2.anl.gov t benedick.ctd.anl.gov [1/1][16/32] MBONE-2.MIT.EDU t X.media.mit.edu [1/1][1/8] taro.etri.re.kr m cosmos.kaist.ac.kr [3/1][16/16] MBONE3.UU.NET m nb-gw.rutgers.edu [1/3][64/64] bandai.cc.kyushu-u.ac.jp t sakimori.cc.kyushu-u.ac.jp [1/1][1/16] ccmng.riken.go.jp t jupiter.riken.go.jp [1/1][1/16] defiant-bb.cs.odu.edu t pong.cs.odu.edu [1/1][1/32] defiant-bb.cs.odu.edu t brahma.cs.odu.edu [1/1][1/32] utorgw.gw.utoronto.ca t mbone.on.canet.ca [1/1][1/32] elm.netcom.ubc.ca t netman.cs.ubc.ca [1/1][1/16] otsiris.ucs.sfu.ca t wizzl.ucs.sfu.ca [1/1][16/1] mbone.sunet.se t gaston.telematik.su.se [1/1][8/16] jocosus.matematik.su.se mt gaston.telematik.su.se [1/3][8/1] stacer.eecs.ukans.edu mt curie.eecs.ukans.edu [2/1][10/1] davis.cecer.army.mil t dcl2.gw.uiuc.edu [1/1][64/1] jeeves.ncsa.uiuc.edu t dcl2.gw.uiuc.edu [1/1][16/1] elm.netcom.ubc.ca m mbone-seattle.nwnet.net [3/1][64/64] hubsrv.alaska.edu t mbone-seattle.nwnet.net [1/1][32/45] klaatu.fhcrc.org mt mbone-seattle.nwnet.net [1/3][32/1] gateway.ora.dnd.ca t rtr.ndhq.dnd.ca [1/1][1/16] fibula.cic.net m rossi.astro.nwu.edu [3/1][32/32] sprint-oeb-e0.columbus.oar.net mt dune.mcs.kent.edu [2/1][32/0] 164.67.3.1 t sequel.humnet.ucla.edu [1/1][4/32] RASTRO.MIT.EDU t erlang.cs.umass.edu [1/1][3/32] tiananmen.cc.nd.edu t fibula.cic.net [1/1][32/1] tron.nts.uci.edu mt john-bigboote.ics.uci.edu [1/2][1/8] ss20.mty.itesm.mx mt agave.staff.udg.mx [10/1][1/64] paris-e0.ucla.edu m tron.nts.uci.edu [8/1][64/64] draco.acs.uci.edu mt tron.nts.uci.edu [2/1][8/1] bossanova.ics.uci.edu mt tron.nts.uci.edu [2/1][8/1] mroute.winona.msus.edu mt Riverside.MR.Net [3/1][32/1] softserv.solsource.net m sl-ana-3-S3/3-384k.sprintlink.net [1/0][0/0] 128.8.15.1 t spiderman.umbc.edu [1/1][24/0] MBONE1.UU.NET t neteye.thepoint.com [1/1][1/64] wang.EECS.Berkeley.EDU t inr-181.Berkeley.EDU [1/1][0/1] bob.EECS.Berkeley.EDU t inr-181.Berkeley.EDU [1/1][0/4] aldebaran.EECS.Berkeley.EDU t inr-181.Berkeley.EDU [1/1][0/1] mbone.Berkeley.EDU t isengard.barrnet.net [1/1][32/64] navis-1.ie.org t MBONE1.UU.NET [1/1][64/32] 204.235.65.2 m 204.235.71.2 [1/2][48/48] 193.166.30.157 mt sauce-atm.uio.no [1/3][32/16] sura-mp2-pe.sura.net t 129.2.250.1 [1/1][0/32] sprint-oeb-e0.columbus.oar.net mt ostermann.cs.ohiou.edu [3/1][64/0] 202.30.64.27 t taro.etri.re.kr [1/1][16/4] mbone.sunet.se t mit-gw.umu.se [1/1][8/16] gateway.prep.net t igi.prep.net [1/1][1/32] gateway.crad.dnd.ca t 128.43.253.45 [1/1][100/16] sprint-oeb-e0.columbus.oar.net mt doggy.oar.net [2/1][32/0] boo.cc.columbia.edu t 128.59.247.1 [1/1][0/64] mbone.gate.uni-erlangen.de t star.gate.uni-erlangen.de [1/1][24/32] 129.250.200.14 t 129.250.200.9 [1/1][24/32] gw-meduse.ift.ulaval.ca t gwift.ulaval.ca [1/1][0/1] hydra.pixi.com t 206.40.72.100 [1/1][64/0] 192.67.203.200 t ananas.igd.fhg.de [3/3][16/1] flip.igd.fhg.de t ananas.igd.fhg.de [3/3][16/1] 192.67.203.170 t ananas.igd.fhg.de [3/3][16/1] 192.67.201.67 t ananas.igd.fhg.de [3/3][16/1] kahuna.Berkeley.EDU t 128.32.155.100 [1/1][0/1] From list-mgr@ISI.EDU Tue Aug 15 70:59:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12582>; Mon, 14 Aug 1995 15:39:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10525>; Mon, 14 Aug 1995 15:02:12 -0700 Received: from bee.uspnet.usp.br by venera.isi.edu (5.65c/5.61+local-22) id <AA10491>; Mon, 14 Aug 1995 15:02:00 -0700 Return-Path: uratsuka@lsi.usp.br Received: from mozart.lsi.usp.br (mozart.lsi.usp.br [143.107.3.237]) by bee.uspnet.usp.br (8.6.10/SPARC10-CCE2.0)id TAA02268 Date: Mon, 14 Aug 1995 14:59:39 +48000 From: Andre Uratsuka Manoel <uratsuka@lsi.usp.br> To: mbone <mbone> Subject: Tunnel from MCI to Brazil Message-Id: <Pine.SGI.3.90.950814145612.15026A-100000@mozart.lsi.usp.br> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, All Sorry to bother you and waste precious bandwidth but I got some mailing problems and I ended up loosing part of my mail. Unhappily, one of the messages I lost was an answer to my mail concerning the establishment of a Tunnel to MCI. I have no way to recover that message, so would the person who sent that message please re-send it? Sorry for the inconvenient and thanks in advance, Regards, Andre From list-mgr@ISI.EDU Tue Aug 15 04:22:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17755>; Tue, 15 Aug 1995 07:54:03 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17533>; Tue, 15 Aug 1995 07:48:46 -0700 Received: from watserv2.uwaterloo.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA17526>; Tue, 15 Aug 1995 07:48:44 -0700 Received: from watarts.uwaterloo.ca ([129.97.42.10]) by watserv2.uwaterloo.ca with SMTP id <90475-3>; Tue, 15 Aug 1995 10:48:29 -0400 Received: from cnts4p21.uwaterloo.ca by watarts.uwaterloo.ca; (5.65/1.1.8.2/13Jun95-0851AM) id AA00525; Tue, 15 Aug 1995 08:22:28 -0400 Message-Id: <9508151222.AA00525@watarts.uwaterloo.ca> X-Sender: nrandall@watarts X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Aug 1995 08:22:06 -0400 To: mbone From: Neil Randall <nrandall@watarts.uwaterloo.ca> Subject: MBONE Work Hi, folks. I'm the guy who posted the request for people doing MBONE research and development, for a book I'm writing. I didn't realize when I posted the message that it was going -- or at least seemed to be going -- to a mailing list. I got the mbone@isi.edu address from Steve Casner's automatic "I've moved" message, and gave it a try. Sorry if I spammed unkowingly. On the other hand, thanks to all for the responses. Very useful, and those who said I could be in touch with I will. Neil Randall nrandall@watarts.uwaterloo.ca From list-mgr@ISI.EDU Tue Aug 15 10:05:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04636>; Tue, 15 Aug 1995 13:09:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04589>; Tue, 15 Aug 1995 13:09:22 -0700 Received: from espsun.space.swri.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA04576>; Tue, 15 Aug 1995 13:09:21 -0700 Received: by espsun.space.swri.edu (4.1/0.0) id AA23779; Tue, 15 Aug 95 15:05:51 CDT Date: Tue, 15 Aug 95 15:05:51 CDT From: richard@espsun.space.swri.edu (Richard Murphy) Message-Id: <9508152005.AA23779@espsun.space.swri.edu> To: mbone Subject: mrouted and Solaris 2.4 Does anyone successfully run ANY version of mrouted on Solaris 2.4? I need some help with this. Thanks. R. Murphy =========================================================== Richard Murphy richard@swri.edu Division 15 210-522-3259 Southwest Research Institute 210-647-4325 fax 6220 Culebra Road San Antonio TX 78228-0510 "It's not what you know, it's what you think you know." - Steve Martin =========================================================== From list-mgr@ISI.EDU Tue Aug 15 23:59:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10680>; Tue, 15 Aug 1995 15:02:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10458>; Tue, 15 Aug 1995 14:56:50 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA10451>; Tue, 15 Aug 1995 14:56:48 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id WAA15193; Tue, 15 Aug 1995 22:56:30 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id WAA06057; Tue, 15 Aug 1995 22:59:11 +0100 Date: Tue, 15 Aug 1995 22:59:10 +0100 (BST) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Richard Murphy <richard@espsun.space.swri.edu> Cc: mbone Subject: Re: mrouted and Solaris 2.4 In-Reply-To: <9508152005.AA23779@espsun.space.swri.edu> Message-Id: <Pine.SV4.3.91.950815225845.6041B-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 15 Aug 1995, Richard Murphy wrote: > Does anyone successfully run ANY version of mrouted on Solaris 2.4? > I need some help with this. Thanks. Yes, I run version 3.4. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Tue Aug 15 10:26:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11953>; Tue, 15 Aug 1995 15:31:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11701>; Tue, 15 Aug 1995 15:26:23 -0700 Received: from ncar.ucar.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA11694>; Tue, 15 Aug 1995 15:26:22 -0700 Received: from niwot.scd.ucar.EDU by ncar.ucar.EDU (NCAR-local/ NCAR Central Post Office 03/11/93) id QAA12961; Tue, 15 Aug 1995 16:26:21 -0600 Received: from triceratops.scd.ucar.edu by niwot.scd.ucar.EDU (NCAR-local/ NCAR Mail Server 04/10/90) id QAA29042; Tue, 15 Aug 1995 16:26:20 -0600 Received: from localhost by triceratops.scd.ucar.edu via SMTP (940816.SGI.8.6.9/930416.SGI) for <mbone@isi.edu> id QAA02791; Tue, 15 Aug 1995 16:26:16 -0600 Message-Id: <199508152226.QAA02791@triceratops.scd.ucar.edu> To: mbone Reply-To: hyder@ncar.ucar.edu Subject: SGI mrouted help Date: Tue, 15 Aug 1995 16:26:15 -0600 From: Paul Hyder <hyder@triceratops.scd.ucar.edu> Time to ask for help. I just upgraded to IRIX 5.3 to install the mrouted [3.4] (and my new indycam on this Indigo 2 :). The mrouted running to my central Sun mrouted shows as up, I see routes, and everything seems to be working. Problem is I don't seem to be forwarding anything except routes. No session information goes in or out. Looking at Mbone Audio is a very lonesome experience. If anyone out there has had experience with SGI's behaving like this please let me know what I've missed. As ever TIA Paul Hyder NCAR From list-mgr@ISI.EDU Wed Aug 16 07:33:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09613>; Wed, 16 Aug 1995 08:34:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09579>; Wed, 16 Aug 1995 08:33:26 -0700 Received: from mailer.jhuapl.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA09572>; Wed, 16 Aug 1995 08:33:21 -0700 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA15280; Wed, 16 Aug 1995 11:33:19 -0400 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA23248; Wed, 16 Aug 1995 11:33:18 -0400 Date: Wed, 16 Aug 1995 11:33:17 -0400 (EDT) From: Jim Bogard BIX <jimbo@aplcomm.jhuapl.edu> To: mbone <mbone> Subject: wb images Message-Id: <Pine.SOL.3.91.950816113148.23030C-100000@aplcomm.jhuapl.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 310 Is there any way to get a postscript file greater than 32K into WB? I can't seem to find anything about being able to change that... Thanks. J-. ---- Jim Bogard JHU/APL BIX Group "This is my banjo. There are many Backbone Network Engineer like it, but this one is mine." From list-mgr@ISI.EDU Wed Aug 16 02:12:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11538>; Wed, 16 Aug 1995 09:12:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11401>; Wed, 16 Aug 1995 09:12:15 -0700 Received: from blob.best.net by venera.isi.edu (5.65c/5.61+local-22) id <AA11394>; Wed, 16 Aug 1995 09:12:14 -0700 Received: from shell1.best.com (shell1.best.com [204.156.128.10]) by blob.best.net (8.6.12/8.6.5) with ESMTP id JAA18705; Wed, 16 Aug 1995 09:12:31 -0700 Received: (prince@localhost) by shell1.best.com (8.6.12/8.6.5) id JAA19212; Wed, 16 Aug 1995 09:12:21 -0700 Date: Wed, 16 Aug 1995 09:12:21 -0700 From: Vinay Kumar <prince@best.com> Message-Id: <199508161612.JAA19212@shell1.best.com> To: jimbo@aplcomm.jhuapl.edu, mbone Subject: Re: wb images Jim, You may have to take a look at the wb README file, but you can increase the WB file size to 1 Meg by adding the following to your .Xdefaults: Wb.MaxPostscriptsize: 1000000 (please check the resource name from the README). Hope this helps. --- Vinay From list-mgr@ISI.EDU Wed Aug 16 18:33:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12545>; Wed, 16 Aug 1995 09:35:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12500>; Wed, 16 Aug 1995 09:34:05 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA12493>; Wed, 16 Aug 1995 09:34:01 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA21953>; Wed, 16 Aug 1995 09:34:00 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.18911-0@bells.cs.ucl.ac.uk>; Wed, 16 Aug 1995 17:33:32 +0100 From: Mark Handley <M.Handley@cs.ucl.ac.uk> Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: Vinay Kumar <prince@best.com> Cc: jimbo@aplcomm.jhuapl.edu, mbone Subject: Re: wb images In-Reply-To: Your message of "Wed, 16 Aug 95 09:12:21 PDT." <199508161612.JAA19212@shell1.best.com> Date: Wed, 16 Aug 95 17:33:31 +0100 Message-Id: <1649.808590811@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >You may have to take a look at the wb README file, but you can >increase the WB file size to 1 Meg by adding the following to >your .Xdefaults: Wb.MaxPostscriptsize: 1000000 >(please check the resource name from the README). You can also use the -P <size> flag. HOWEVER I don't believe wb was designed to transfer very large files around the place - it will be slow, and may use significant bandwidth. The 32K limit was in there for a good reason. It's always worth putting a fair amount of work into ensuring the image files are as small as possible, and then lzps them too. Don't just set the resource name and forget about it and start shipping big images around at high ttls. If you're using a Mac, get the version 8.0 laserwiter driver (it's *much* better than previous versions) and don't include any fonts - many powerpoint slides will then come in under the 32K limit then anyway. Mark From list-mgr@ISI.EDU Wed Aug 16 05:54:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21941>; Wed, 16 Aug 1995 12:55:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21917>; Wed, 16 Aug 1995 12:55:03 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA21910>; Wed, 16 Aug 1995 12:55:03 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15559(5)>; Wed, 16 Aug 1995 12:54:21 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Wed, 16 Aug 1995 12:54:13 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: richard@espsun.space.swri.edu (Richard Murphy) Cc: mbone Subject: Re: mrouted and Solaris 2.4 In-Reply-To: Your message of "Tue, 15 Aug 95 13:05:51 PDT." <9508152005.AA23779@espsun.space.swri.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Aug 1995 12:54:03 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Aug16.125413pdt.177475@crevenia.parc.xerox.com> In message <9508152005.AA23779@espsun.space.swri.edu> you write: >Does anyone successfully run ANY version of mrouted on Solaris 2.4? >I need some help with this. Thanks. You can get mrouted 3.4 and the necessary kernel modifications from ftp://playground.sun.com/pub/multicast/Solaris_mc33.2.4.tar.Z . Bill From list-mgr@ISI.EDU Fri Aug 18 02:39:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16189>; Wed, 16 Aug 1995 23:45:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16162>; Wed, 16 Aug 1995 23:39:47 -0700 Received: from octavia.anu.edu.au by venera.isi.edu (5.65c/5.61+local-22) id <AA16155>; Wed, 16 Aug 1995 23:39:41 -0700 Received: (from markus@localhost) by octavia.anu.edu.au (8.6.12/8.6.12) id QAA05316; Thu, 17 Aug 1995 16:39:24 +1000 Date: Thu, 17 Aug 1995 16:39:24 +1000 From: Markus Buchhorn <markus@octavia.anu.edu.au> Message-Id: <199508170639.QAA05316@octavia.anu.edu.au> To: mbone Subject: Mbone Accounting Cc: markus@octavia.anu.edu.au G'day all With the advent of capitalism on the Internet we are faced with such fun novelties like per-packet billing. This means that large bodies look at what is generating a lot of traffic, and chop anything with it's head too high. In Australia we are currently looking at paying for all incoming traffic, or paying for combination of pipe-bandwidth and percentage utilisation. The Australian National Uni (ANU) has recently requested that our incoming tunnel be closed, pending an analysis of 'what can be done'. Since I complained the loudest I got the job of looking at what is the best way to have the Mbone and pay little for it :-). Ultimately this may also extend to other Video/RT gadgets like Cu-SeeMe. I'm currently writing a set of notes on the problem and guidelines for the implementation of a structured mbone feed, with accounting. During the development of these notes I came across several problems/thoughts and I would greatly appreciate input on them. (i) Is anybody else out there in the same situation ? In Australia or anywhere else ? (ii) My understanding of pruning may be flawed. Is it correct that if you have a tunnel to the external MBONE that you will receive session-directory (sd) packets regardless, and that when somebody opens a session then and only then does the actual AV stream come your way ? And when you leave that session then (eventually) your upstream mrouted stops sending you the AV stream ? (iii) Consider the following cheesy diagram: mbone-south <-------MGW---------> mbone-north | incoming tunnel | | ANU-GW /-----------+-----------\ | | | | | | x.x.x.a-z -----GWX---- ... ... | /-------+-----\ | | | y.y.y.a-z --GWY--- ... ... MGW = Mbone Gateway to the outside world. Those with a geographical interest may associate south with Melbourne (and thence the US) and north with Sydney and Queensland. :-) An mrouted running on a CISCO or a Sun. ANU-GW = ANU's gateway - the first mrouted inside the ANU. Maybe a CISCO or a Sun. It provides several tunnels, subject to topology. GWX = Gateway X, an mrouted running on a Sun on the x.x.x subnet, and it also provides several tunnels GWY = I think you get the idea... Now - let's say a host on the y.y.y subnet sees a session in sd - NASA say. They open vat/nv and <magic happens>. This magic I'd like to clear up. I believe a request packet goes to GWY to bring the NASA stream in. GWY sends a packet up to GWX, GWX sends to ANU-GW, ANU-GW to MGW and the packets that already happened to be going from south to north get copied down to ANU-GW. (iii-a) Is this a correct picture ? Now let's say somebody on the x.x.x wants to see NASA. They start vat/nv and a request packet goes to GWX (iii-b) true ? and since GWX is already shipping packets down to GWY it also copies them onto the local subnet. You can probably see where I'm going here. What we want to be able to do is apportion the cost of having NASA packets going across the MGW<->ANU-GW line, which is where we pay for it. So, there are two parts to the problem: 1. Who is asking for the traffic to be sent across the line 2. How much traffic is there in a given stream Now '2' could be done with some basic packet sniffer, restricted to a given IP multi address. '1' is the hard part (or is it..). (iii-c) is there a hook in mrouted (or can one be added) to catch and log the request packets ? (iii-d) Does a request packet come labelled as from the originating host or from the downstream mrouted ? (iii-e) what is a _good_ way to measure the stream bandwidth/total packets in an mbone stream ? I assume it would have to be done at each mrouted.. Assuming that it is possible, we can take care of the logging and apportioning (even with overlapping requests) with postprocessing of the log files. I have some further questions :-) , but they depend on the answers to the above. Any help is *GREATLY* appreciated. Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] From list-mgr@ISI.EDU Thu Aug 17 13:23:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17423>; Thu, 17 Aug 1995 00:30:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17251>; Thu, 17 Aug 1995 00:25:21 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA17241>; Thu, 17 Aug 1995 00:25:05 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.11/8.6.9) id KAA18058; Thu, 17 Aug 1995 10:23:31 +0300 Date: Thu, 17 Aug 1995 10:23:31 +0300 Message-Id: <199508170723.KAA18058@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Markus Buchhorn <markus@octavia.anu.edu.au> Cc: mbone Subject: Mbone Accounting In-Reply-To: <199508170639.QAA05316@octavia.anu.edu.au> References: <199508170639.QAA05316@octavia.anu.edu.au> Markus Buchhorn writes: > > Any help is *GREATLY* appreciated. > > Cheers, > Markus > If any of these are downstream from the point you are accounted for, you are going to get all the MBone traffic there is. In any case, you might want to get rid of old mrouteds around anyway. Pete 2.2 mrouteds 128.250.252.5 (wehib.wehi.edu.au) [version 2.2]: 7 mins 22 secs 131.170.9.1 (exxilon.xx.rmit.EDU.AU) [version 2.2]: 7 mins 10 secs 128.184.16.10 (libra.ccs.deakin.edu.au) [version 2.2]: 6 mins 21 secs 128.184.1.4 (rana.ccs.deakin.edu.au) [version 2.2]: 7 mins 15 secs 128.250.118.20 (springfield.mame.mu.OZ.AU) [version 2.2]: 7 mins 14 secs From list-mgr@ISI.EDU Fri Aug 18 01:49:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20096>; Thu, 17 Aug 1995 02:49:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20081>; Thu, 17 Aug 1995 02:47:23 -0700 Received: from mail.ncku.edu.tw by venera.isi.edu (5.65c/5.61+local-22) id <AA20073>; Thu, 17 Aug 1995 02:47:19 -0700 Received: (from ckwen@localhost) by mail.ncku.edu.tw (8.6.12/8.6.12) id RAA23041; Thu, 17 Aug 1995 17:49:08 +0800 From: Cheng-Kang Wen <ckwen@mail.ncku.edu.tw> Message-Id: <199508170949.RAA23041@mail.ncku.edu.tw> Subject: Re: wb images To: jimbo@aplcomm.jhuapl.edu (Jim Bogard BIX) Date: Thu, 17 Aug 1995 17:49:08 +0800 (WST) Cc: mbone In-Reply-To: <Pine.SOL.3.91.950816113148.23030C-100000@aplcomm.jhuapl.edu> from "Jim Bogard BIX" at Aug 16, 95 11:33:17 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 622 > > Is there any way to get a postscript file greater than 32K into WB? I > can't seem to find anything about being able to change that... > You have two options to do this. One is to specify the "-P FileSize" at the wb commannd line. The other is to put MaxPostScriptSize to your X source. ------------------------------------------------------------------------ Cheng-Kang Wen E-mail: ckwen@mail.ncku.edu.tw Distributed Systems Lab. Institute of Electrical Engineering National Cheng Kung University Tainan Taiwan ------------------------------------------------------------------------ From list-mgr@ISI.EDU Thu Aug 17 02:34:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01755>; Thu, 17 Aug 1995 09:41:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01571>; Thu, 17 Aug 1995 09:36:10 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA01564>; Thu, 17 Aug 1995 09:36:08 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15665(1)>; Thu, 17 Aug 1995 09:35:14 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Thu, 17 Aug 1995 09:35:02 -0700 To: Markus Buchhorn <markus@octavia.anu.edu.au> Cc: mbone Subject: Re: Mbone Accounting In-Reply-To: Your message of "Wed, 16 Aug 95 23:39:24 PDT." <199508170639.QAA05316@octavia.anu.edu.au> Date: Thu, 17 Aug 1995 09:34:59 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Aug17.093502pdt.177475@crevenia.parc.xerox.com> I'll try to answer some of your questions with some explanation. When multicast traffic flows, a data distribution tree gets created for it. When the traffic gets to a router at a leaf of the tree that has no group members on any of its attached networks, that router sends a prune upstream. When a router has received prunes from all of the routers downstream of it, and there are no members on any of its locally attached members, it also sends a prune upstream. Thus, prunes will propogate all the way up the tree to the source, if nobody is listening. Note that Cisco's DVMRP implementation doesn't do pruning, nor do mrouted's previous to 3.0 (as Petri Helenius noted). Therefore, if you have either a Cisco or a 2.x mrouted in the middle of your distribution tree, you will get *all* multicast traffic down to that point in the tree. Now, when a member appears on a network attached to a router that has sent a prune upstream, it sends a graft, requesting to cancel the prune that was previously sent. If the router receiving the graft has sent a prune upstream as well, it sends a graft upstream. The grafts then "chase" the previous prunes upstream until they hit a point on the real distribution tree. At that point, the data starts getting forwarded and the tree gets recreated as before. Hosts use IGMP to notify routers of their group memberships. When a router gets an IGMP membership report, that is what triggers a graft; when a router gets no membership reports (or a leave message, in IGMPv2), that triggers a prune. >Now let's say somebody on the x.x.x wants to see NASA. They start vat/nv >and a request packet goes to GWX > >(iii-b) true ? The host reports its membership using IGMP to all multicast routers on the attached network. Since traffic is already flowing through GWX, it simly turns on forwarding on the interface to the x.x.x network. > 1. Who is asking for the traffic to be sent across the line You will need to put some kind of monitoring at the entrance point to each site, to monitor prunes and grafts sent by each multicast router. The prunes and grafts are only identified by the downstream router that sent them, not by the original requestor. > 2. How much traffic is there in a given stream The kernel keeps track of packet counts and byte counts. The SNMP version of mrouted can report this information; perhaps you can use SNMP to collect the data. In fact, you can probably get enough information from SNMP to trace the full multicast forwarding tree all the way from the entrance point. Bill From list-mgr@ISI.EDU Thu Aug 17 03:23:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04121>; Thu, 17 Aug 1995 10:24:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04110>; Thu, 17 Aug 1995 10:24:34 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA04103>; Thu, 17 Aug 1995 10:24:33 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15470(3)>; Thu, 17 Aug 1995 10:23:21 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 17 Aug 1995 10:23:12 -0700 To: Bill Fenner <fenner@parc.xerox.com> Cc: mbone, deering@parc.xerox.com Subject: Re: Mbone Accounting In-Reply-To: fenner's message of Thu, 17 Aug 95 09:34:59 -0800. <95Aug17.093502pdt.177475@crevenia.parc.xerox.com> Date: Thu, 17 Aug 1995 10:23:00 PDT Sender: Steve Deering <deering@parc.xerox.com> From: Steve Deering <deering@parc.xerox.com> Message-Id: <95Aug17.102312pdt.75270@digit.parc.xerox.com> > Hosts use IGMP to notify routers of their group memberships. When a router > gets an IGMP membership report, that is what triggers a graft; when a router > gets no membership reports (or a leave message, in IGMPv2), that triggers a > prune. To be a little a more precise, when a router learns through IGMP that a member of a new group has appeared on an attached network, it sends a graft message *if and only if* it has recently sent a prune message for that group (recently = within the lifetime specified when the prune was sent); it will have sent a prune message only if multicast packets had been recently received for that group. When a router detects through IGMP that the last member of a group has disappeared from an attached network, it does *not* trigger a prune. Rather, if subsequently a packet arrives for that group, at *that* point a prune is sent, assuming the packet arrived from the expected upstream interface for the source of the packet. Note that this behaviour is specific to DVMRP (and probably Dense-Mode PIM). Other multicast routing protocols, such as MOSPF, Sparse-Mode PIM, or CBT, act differently. Steve From list-mgr@ISI.EDU Thu Aug 17 21:46:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05223>; Thu, 17 Aug 1995 10:47:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05194>; Thu, 17 Aug 1995 10:47:17 -0700 Received: from basil.cdt.luth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA05187>; Thu, 17 Aug 1995 10:47:16 -0700 Received: from salt.cdt.luth.se (salt.cdt.luth.se [130.240.3.63]) by basil.cdt.luth.se (8.6.12/8.6.12) with ESMTP id TAA11225; Thu, 17 Aug 1995 19:46:22 +0200 Received: from salt (localhost [127.0.0.1]) by salt.cdt.luth.se (8.6.12/8.6.12) with ESMTP id TAA07639; Thu, 17 Aug 1995 19:46:30 +0200 Message-Id: <199508171746.TAA07639@salt.cdt.luth.se> X-Mailer: exmh version 1.6.2 7/18/95 To: deering@parc.xerox.com Cc: fenner@parc.xerox.com, mbone Subject: Re: Mbone Accounting In-Reply-To: Your message of "Thu, 17 Aug 1995 10:23:00 PDT." <95Aug17.102312pdt.75270@digit.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Aug 1995 19:46:30 +0200 From: Peter Parnes <peppar@cdt.luth.se> deering@parc.xerox.com said: > Other multicast routing protocols, such as MOSPF, Sparse-Mode PIM, or > CBT, act differently. Could someone briefly explain how it works in these different protocols? /P From list-mgr@ISI.EDU Thu Aug 17 20:12:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06458>; Thu, 17 Aug 1995 11:14:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06447>; Thu, 17 Aug 1995 11:13:52 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA06429>; Thu, 17 Aug 1995 11:13:31 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA19100>; Thu, 17 Aug 1995 11:13:29 -0700 Message-Id: <199508171813.AA19100@quark.isi.edu> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.25058-0@bells.cs.ucl.ac.uk>; Thu, 17 Aug 1995 19:12:44 +0100 Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3462 or +44 71 387 7050 ext 3462 Fax: ++44 71 387 1397 To: Peter Parnes <peppar@cdt.luth.se> Cc: deering@parc.xerox.com, fenner@parc.xerox.com, mbone Subject: Re: Mbone Accounting In-Reply-To: Your message of "Thu, 17 Aug 95 19:46:30 +0100." <199508171746.TAA07639@salt.cdt.luth.se> Date: Thu, 17 Aug 95 19:12:45 +0100 From: Tony Ballardie <A.Ballardie@cs.ucl.ac.uk> > deering@parc.xerox.com said: > > Other multicast routing protocols, such as MOSPF, Sparse-Mode PIM, or > > CBT, act differently. > > Could someone briefly explain how it works in these different protocols? In CBT, the delivery tree is only built between receivers that want to receive data -- this diverges from the "broadcast and prune" approach of DVMRP and PIM-dense. Receivers (or rather, their directly attached routers) must join a tree explicitly. One of the subnet's routers does this subsequent to receiving an IGMP membership report. CBT protocol mechanism ensures that, when there are no more receivers on a subnet, that particular branch can be torn down (provided the router has no downstream children). Sparse-mode PIM does something similar, in that delivery trees are only built between receivers that explicitly request the data. MOSPF uses special multicast link-state advertisements to establish domain-wide group membership. With "global" membership topology information, a source-based delivery tree can be built on-demand that spans only the receivers. New delivery trees are built as members come and go, as established through the distribution of M-LSAs. Tony From list-mgr@ISI.EDU Thu Aug 17 05:53:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11230>; Thu, 17 Aug 1995 12:55:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11209>; Thu, 17 Aug 1995 12:54:18 -0700 Received: from ocfmail.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA11202>; Thu, 17 Aug 1995 12:54:17 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA21892; Thu, 17 Aug 95 12:53:01 PDT Message-Id: <9508171953.AA21892@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Aug 1995 12:53:14 -0700 To: Markus Buchhorn <markus@octavia.anu.edu.au> From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Mbone Accounting Cc: mbone It seems to me that implicit in the comments and questions Markus Buchhorn had about identifying receivers of multicast data: >Date: Thu, 17 Aug 1995 16:39:24 +1000 >From: Markus Buchhorn <markus@octavia.anu.edu.au> >To: mbone@ISI.EDU >Subject: Mbone Accounting > >With the advent of capitalism on the Internet... was a model where receivers would be charged for what they receive. I believe that a more appropriate model (if we are getting into a charging for traffic scenario) is one in which the transmitter is charged for multicast transmissions. The transmitter is easier to identify. Such a model is more like that used by the current broadcast media where there is a cost for broadcasting (multicasting) that must be recouped from advertising, direct charging (pay per view), or other sources. I have no idea how ISPs can levy such charges, mix them in with their current (largely flat rate) charging, deal with such charging across administrative areas, etc. One could imagine (in looking way up at the blue sky) a scenario where a multicaster would not want to pay for transmission into an area (e.g. Australia) unless there were some number of listeners (e.g. don't route unless there are <n> graft requests). In general I would say that the multicasters tend to have deeper pockets than receivers (shuttle multicasts notwithstanding). Both transmitters and receivers may derive value from communicated multicasts. Either or both could be charged. It just seems to me easier and more in keeping with current broadcast practice to charge the transmitter directly and the receiver indirectly through the transmitter. Naturally with a scheme in which the transmitter pays for multicasted data, a questioner in a conference session would pay for any question. The tradeoff between having a question multicast out directly to the multicast group and the alternative of having it unicast to a conference session (moderated) and then multicast to the audience takes on another dimension in this case. It is likely the case that the unicast of a question would take fewer resources than multicasting it directly, but unicasting it and then multicasting it certainly takes more overall resources. I expect that issues relating to charging for multicast would likely be effectively aired on the comm priv mailing list, but since I am not on that list, I will not relay it there. --Jed http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Thu Aug 17 13:32:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12895>; Thu, 17 Aug 1995 13:33:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12869>; Thu, 17 Aug 1995 13:32:21 -0700 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA12862>; Thu, 17 Aug 1995 13:32:20 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.6.12/8.6.12) id QAA20010; Thu, 17 Aug 1995 16:32:19 -0400 Date: Thu, 17 Aug 1995 16:00:51 From: "Dave Thaler" <thalerd@eecs.umich.edu> Subject: Mbone Accounting Message-Id: <19950817160051.29534@dip.eecs.umich.edu> To: mbone Markus Buchhorn writes: > (iii-e) what is a _good_ way to measure the stream bandwidth/total packets > in an mbone stream ? I assume it would have to be done at each > mrouted.. Bill Fenner writes: > The kernel keeps track of packet counts and byte counts. The SNMP version > of mrouted can report this information; perhaps you can use SNMP to collect > the data. I'll second this. You must be running an SNMP-capable mrouted (http://www.merit.edu/research.and.development/mbone/.download.html) for this to happen. You can use any standard SNMP utilities to retrieve the packet and byte counts from the DVMRP Virtual Interface Table (if you are interested in counts per subnet and tunnel) or the IP Multicast Cache Table (if you want counts per group/source). One easy way to do this is to use mstat. (http://www.merit.edu/research.and.development/mbone/.mstat.html) > In fact, you can probably get enough information from SNMP to trace the > full multicast forwarding tree all the way from the entrance point. True (at least as far as the mrouted's are SNMP-capable). This information is available in the IP Multicast MIB. Currently, there is no utility already written to do this for you, but we're working on that. Markus Buchhorn writes: > (iii-c) is there a hook in mrouted (or can one be added) to catch and log > the request packets ? One problem is in defining what you really want to know. Do you want to know the first host on a subnet which requested a stream? Do you want to know all hosts on the subnet which have requested the stream? (The latter can be very difficult). Or do you only want to know which subnets have requested the stream (and you don't care which hosts or how many)? With current SNMP queries, you can only determine the subnets, and some member on each subnet. Dave Thaler From list-mgr@ISI.EDU Wed Aug 16 22:06:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17124>; Thu, 17 Aug 1995 15:07:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17102>; Thu, 17 Aug 1995 15:06:49 -0700 Received: from grace.waikato.ac.nz by venera.isi.edu (5.65c/5.61+local-22) id <AA17095>; Thu, 17 Aug 1995 15:06:47 -0700 Received: from wally (wally.cc.waikato.ac.nz) by waikato.ac.nz (PMDF V5.0-3 #11755) id <01HU7QOL5AHSAH72DR@waikato.ac.nz> for mbone@isi.edu; Fri, 18 Aug 1995 10:06:37 +1200 Date: Wed, 16 Aug 1995 10:06:50 +1200 From: d.neal@waikato.ac.nz (Donald Neal) Subject: Re: Mbone Accounting X-Sender: dmneal@mail.waikato.ac.nz To: mbone Message-Id: <01HU7QOL8RVMAH72DR@waikato.ac.nz> Mime-Version: 1.0 X-Mailer: Windows Eudora Version 1.4.4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT >It seems to me that implicit in the comments and questions >Markus Buchhorn had about identifying receivers of multicast >data: > >>Date: Thu, 17 Aug 1995 16:39:24 +1000 >>From: Markus Buchhorn <markus@octavia.anu.edu.au> >>To: mbone@ISI.EDU >>Subject: Mbone Accounting >> >>With the advent of capitalism on the Internet... > >was a model where receivers would be charged for what they >receive. > >I believe that a more appropriate model (if we are getting >into a charging for traffic scenario) is one in which the >transmitter is charged for multicast transmissions. The >transmitter is easier to identify. Such a model is more like >that used by the current broadcast media where there is >a cost for broadcasting (multicasting) that must be recouped >from advertising, direct charging (pay per view), or other >sources. But the practical difficulties in a provider in, say, Australia extracting payment from a transmitter in, say, the US are considerable. The cost of such collection is likely to be a problem also. And that's without taking into account the belief still held by many in the US that Internet infrastructure is somehow free and that charging for bandwidth is evil. Any scheme to pay for the general roll-out of Mbone in Australia, New Zealand, or countries which have as yet very limited IP connections in any kind of short term is surely going to have to start by extracting money from the people from whom money can most easily be extracted - the in-country users. -- Donald Neal | Why would we have a telephone connection in a Systems Programmer | computer lab? University of Waikato | Hamilton, New Zealand | - High School Teacher, Hamilton, 1995 --------------------------------------------------------------------------- From list-mgr@ISI.EDU Fri Aug 18 18:40:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18713>; Thu, 17 Aug 1995 15:41:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18674>; Thu, 17 Aug 1995 15:40:35 -0700 Received: from octavia.anu.edu.au by venera.isi.edu (5.65c/5.61+local-22) id <AA18667>; Thu, 17 Aug 1995 15:40:33 -0700 Received: (from markus@localhost) by octavia.anu.edu.au (8.6.12/8.6.12) id IAA12839; Fri, 18 Aug 1995 08:40:12 +1000 Date: Fri, 18 Aug 1995 08:40:12 +1000 From: Markus Buchhorn <markus@octavia.anu.edu.au> Message-Id: <199508172240.IAA12839@octavia.anu.edu.au> To: deering@parc.xerox.com, fenner@parc.xerox.com Subject: Re: Mbone Accounting Cc: markus@octavia.anu.edu.au, mbone > > Hosts use IGMP to notify routers of their group memberships. When a router > > gets an IGMP membership report, that is what triggers a graft; when a router > > gets no membership reports (or a leave message, in IGMPv2), that triggers a > > prune. > > To be a little a more precise, when a router learns through IGMP that a > member of a new group has appeared on an attached network, it sends a > graft message *if and only if* it has recently sent a prune message for that > group (recently = within the lifetime specified when the prune was sent); > it will have sent a prune message only if multicast packets had been recently > received for that group. So what happens when a new session is started somewhere - e.g. the latest NASA? I'm sitting here and see sd packets for NASA STS-99, so I say 'cool' and join. I'm the first person on the ANU to do so, but not the first in Australia. Thus STS-99 packets are going past us, but nobody on the ANU has generated a 'join STS-99 group' yet. Doesn't my joining then generate a graft ? Or does it generate a different kind of 'join' ? i.e. is a 'graft' purely the thing to do to get back on after a 'prune' ? (my gardening jargon is too limited... :-)). Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] From list-mgr@ISI.EDU Fri Aug 18 18:50:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19193>; Thu, 17 Aug 1995 15:56:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19055>; Thu, 17 Aug 1995 15:51:00 -0700 Received: from octavia.anu.edu.au by venera.isi.edu (5.65c/5.61+local-22) id <AA19048>; Thu, 17 Aug 1995 15:50:59 -0700 Received: (from markus@localhost) by octavia.anu.edu.au (8.6.12/8.6.12) id IAA12891; Fri, 18 Aug 1995 08:50:55 +1000 Date: Fri, 18 Aug 1995 08:50:55 +1000 From: Markus Buchhorn <markus@octavia.anu.edu.au> Message-Id: <199508172250.IAA12891@octavia.anu.edu.au> To: mbone Subject: Re: Mbone Accounting Cc: markus@octavia.anu.edu.au > Markus Buchhorn writes: > > (iii-e) what is a _good_ way to measure the stream bandwidth/total packets > > in an mbone stream ? I assume it would have to be done at each > > mrouted.. > > Bill Fenner writes: > > The kernel keeps track of packet counts and byte counts. The SNMP version > > of mrouted can report this information; perhaps you can use SNMP to collect > > the data. Dave Thaler writes: > I'll second this. You must be running an SNMP-capable mrouted Is there a Solaris 2.x version as well ? [...info and URL's...] Thanks for that info. > > In fact, you can probably get enough information from SNMP to trace the > > full multicast forwarding tree all the way from the entrance point. > > True (at least as far as the mrouted's are SNMP-capable). This information > is available in the IP Multicast MIB. Currently, there is no utility > already written to do this for you, but we're working on that. Looking forward to it ! :-). If you need a beta-tester.... > Markus Buchhorn writes: > > (iii-c) is there a hook in mrouted (or can one be added) to catch and log > > the request packets ? > > One problem is in defining what you really want to know. Do you want to > know the first host on a subnet which requested a stream? Do you want > to know all hosts on the subnet which have requested the stream? (The > latter can be very difficult). Or do you only want to know which subnets > have requested the stream (and you don't care which hosts or how many)? Basically I only need to know subnets, as subnets=departments. On a given subnet there will probably be some political control as to who can use mbone tools (e.g. by setting group execute only, or packet filtering restricting it to a given set of machines on people's desks.). Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] From list-mgr@ISI.EDU Thu Aug 17 09:33:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21769>; Thu, 17 Aug 1995 16:34:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21735>; Thu, 17 Aug 1995 16:33:38 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA21728>; Thu, 17 Aug 1995 16:33:37 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15373(5)>; Thu, 17 Aug 1995 16:33:25 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Thu, 17 Aug 1995 16:33:17 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Markus Buchhorn <markus@octavia.anu.edu.au> Cc: mbone Subject: Re: Mbone Accounting In-Reply-To: Your message of "Thu, 17 Aug 95 15:40:12 PDT." <199508172240.IAA12839@octavia.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Aug 1995 16:33:13 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Aug17.163317pdt.177475@crevenia.parc.xerox.com> In message <199508172240.IAA12839@octavia.anu.edu.au> you write: >So what happens when a new session is started somewhere - e.g. the latest NASA? The first packet from scorpio.arc.nasa.gov gets flooded through the whole MBONE, and builds the data distribution trees. This packet triggers prunes from leaf routers who have no group members on their local nets, and the prunes flow up the tree as I described initially. I omitted one important piece of information from my original description, which is that prunes time out. That is, whenever a router sends a prune, it gives the message a lifetime. When that lifetime is over, if the source is still generating packets, these packets will start flowing through the routers again, and will trigger another prune message. The max. prune lifetime is configurable in your /etc/mrouted.conf and defaults to 10 minutes. >Doesn't my joining then generate a graft ? Yes, if the data has been flowing constantly and generating prunes. If there is no data flowing (and thus no prunes have been generated) then your joining does nothing at all. >i.e. is a 'graft' purely the thing to do to get back on >after a 'prune' ? Yes, it is, but you pruned the traffic when it initially showed up because there were no listeners. When a listener appears, a graft is sent to cancel the prunes. Bill From list-mgr@ISI.EDU Fri Aug 18 19:37:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21920>; Thu, 17 Aug 1995 16:38:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21901>; Thu, 17 Aug 1995 16:38:04 -0700 Received: from octavia.anu.edu.au by venera.isi.edu (5.65c/5.61+local-22) id <AA21887>; Thu, 17 Aug 1995 16:37:51 -0700 Received: (from markus@localhost) by octavia.anu.edu.au (8.6.12/8.6.12) id JAA13258; Fri, 18 Aug 1995 09:37:41 +1000 Date: Fri, 18 Aug 1995 09:37:41 +1000 From: Markus Buchhorn <markus@octavia.anu.edu.au> Message-Id: <199508172337.JAA13258@octavia.anu.edu.au> To: mbone Subject: Mbone Accounting (political) Cc: markus@octavia.anu.edu.au I didn't want to get into this, but a few people have asked questions which I think deserve answers. Whether I agree with the principles is up to you to figure out :-). (i) Why pay for incoming traffic ? Why not transmission ? Several issues here - As Donald Neal noted it's hard to send a bill to the US and Europe for some packets you guys sent me - A pay-for-transmission policy would hurt ftp mirrors, information servers etc. Just because we have the data, the disk space and the httpd or mrouted to ship it out doesn't mean we have the money to pay for it to be sent out. - Australia's link to the Internet is a single cable to the US (with some standby options). The cost of this link is a significantly large fraction of the Internet costs within Australia. - Australia is a greater information importer than exporter (this is probably true of every Internet-connected country on earth except the US sheerly due to weight of numbers). - Thus the vast majority of bandwidth on the single largest expense is taken up by incoming traffic. Receivers are the people who initiated that traffic. Our Academic network (AARNet) recently was sold to our main commercial telco. Before the sale was finalised the initial policy was paying for incoming traffic that originated overseas, while internal traffic would be free (sort-of). After the sale I get the impression that this approach was considered too hard, and becoming harder, with things like mbone (which *looks* like local traffic, from your downstream mrouted) and proxy servers for many things. (ii) Why MBONE ? Why (or why not) CU-SeeMe ? Usenet ? WWW ? Note that this only applies to the ANU - I can make no comments on other campuses (campii ?). I can't even claim that these opinions are those of the ANU, but are purely my view of how I think they're thinking. Two main reasons here: market share and access control. - MBONE is used by a very small group of people on the campus. OTOH, without pruning it is continually bringing in traffic even with nobody watching anything. At one point (I think it was IETF, NASA and various sundry others) 70% (yes: 7-0) of traffic on our incoming line was MBONE. So, a very small group of people had to be billed for a large amount of traffic (figuratively speaking, fortunately). Personally I think that if the Solaris pruning mrouted had been out 6 months earlier then this problem would not have arisen until *much* later, when mbone ruled the Net. - MBONE takes a bit of setting up. CU-SeeMe OTOH is trivial and it's spreading. At this stage nobody has complained about it (here at the ANU at any rate) but I can see it happening. (I started the EUNet thread when I posted an item from the CUSM list to the mbone list.) At this stage I will propose that point-to-point is basically uncontrollable, but large sessions can be run via an ANU reflector which receives it's traffic either unicast or multicast from other reflectors (depending on the source). It's a separate problem but being linked to the MBONE ("it's video on a desktop, via the Internet, right? ") means that my name may crop up when they start looking at CUSM. I'm just trying to be ready for it :-). - Usenet is controlled by having a single well-run newshost on campus (single actually is 2 or 3, but single point of control). Nobody else thus feels the urge to organise a newsfeed from anywhere else. It's a lot of traffic with a lot of users. If somebody decides that Usenet is too big they can always drop the expire time, or drop the larger alt.* groups. Usenet however is currently a small chunk of incoming traffic. - WWW and ftp aren't really controllable. The ANU provides a nice proxy/cache server (with a 30%+ strike rate apparently). There are also ftp mirrors. Finally - there are a lot of people using them. So, cost per user per packet is reduced. Ok - hopefully that covers the points, as I see them. I'd prefer to restrict this thread to the more technical side (which for me at least is turning out to be very interesting and edcuational. Thanks!) and leave the political aspects to the bean counters up above. Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] From list-mgr@ISI.EDU Thu Aug 17 12:04:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27080>; Thu, 17 Aug 1995 19:05:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27069>; Thu, 17 Aug 1995 19:04:38 -0700 Received: from blob.best.net by venera.isi.edu (5.65c/5.61+local-22) id <AA27062>; Thu, 17 Aug 1995 19:04:37 -0700 Received: from rsf.vip.best.com (rsf.vip.best.com [204.156.129.162]) by blob.best.net (8.6.12/8.6.5) with SMTP id TAA23343 for <mbone@ISI.EDU>; Thu, 17 Aug 1995 19:04:30 -0700 Date: Thu, 17 Aug 1995 19:04:30 -0700 Message-Id: <199508180204.TAA23343@blob.best.net> X-Sender: rsf@shell1.best.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: Ross Finlayson <finlayson@live.com> Subject: Re: Mbone Accounting At 04:39 PM 8/17/95 +1000, Markus Buchhorn wrote: >With the advent of capitalism on the Internet we are faced with such >fun novelties like per-packet billing. The hidden, and incorrect, assumption here is that "capitalism on the Internet" necessarily implies "per-packet billing". As a New Zealander, I'm usually happy whenever Australia adopts a concept from its neighbour (sic :-) across the Tasman Sea, but in this case the concept - traffic-based accounting and billing - appears to be a mistake. In fact it's "multicast", in the most general sense, that illustrates why this approach is so problematic. Any individual packet may *logically* lead to any number of subsequent packets in ways that can be impossible to detect, let alone be 'fairly' accounted for. In particular, Markus has already acknowleged (in a later message) that mrouted makes it difficult to keep track of which packets that *appear* to be of local origin are *logically* of local origin. Even if you could somehow keep track of packets in the MBone, you've still got to solve the problem of dealing with higher-level examples of multicast - such as CU-SeeMe, NetNews, and email mailing lists. You soon find yourself in a tarpit... Noone denies that Australia's Internet connection(s) from the rest of the world costs real money (per unit time), but what's not clear to me is why the provider of this connection feels the need to charge the attached networks for each packet (or byte) that traverses this connection? The alternative model - which is predominant here in the U.S. - is to charge for the *bandwidth available* to the attached (physical or logical) network, regardless of how it is utilized. In other words, you're paying not for bytes or packets, but instead for a (physical or logical) *pipe*. The cost (per unit time) of the international link can then be passed on to each of the internal attached 'pipes' - e.g., proportion to their relative sizes, and so on down through the rest of the Australian internal Internet. Furthermore, routing technology exists (e.g., CBQ) that can be used to ensure that each attached network gets (or sends) at least the fair share of the pipe that it's paid for. In this model, problems of accounting and settlement still exist (e.g., to avoid MBone traffic drowning out other traffic, you might decide that you wish to treat the MBone as being a separate logical 'pipe' with its own bandwidth limits), but this accounting and settlement will generally happen at a much courser granularity in time (e.g., per-month), and so should be easier to deal with. Of course, it sounded like Markus was asking for a short-term solution, and if so, I guess this response doesn't really help him... On a closely-related topic: Donald Neil mentioned "the belief still held by many in the US that Internet infrastructure is somehow free and that charging for bandwidth is evil". In fact, I know of few, if any, people of consequence here in the U.S. who hold this view. Although many (most?) academic institutions' Internet connections are subsidised to some extent by grant money, almost every Internet-connected company here in the U.S., and every individual who accesses the Internet from his home, is paying real money for the bandwidth of their connections. But the key thing to note here is that it's *bandwidth* that they're paying for - not bytes or packets. Ross. From list-mgr@ISI.EDU Thu Aug 17 15:07:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28718>; Thu, 17 Aug 1995 20:17:27 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28706>; Thu, 17 Aug 1995 20:16:14 -0700 Received: from crimelab.com by venera.isi.edu (5.65c/5.61+local-22) id <AA28699>; Thu, 17 Aug 1995 20:16:13 -0700 Received: (chasin@localhost) by crimelab.com (8.6.10/8.6.4) id VAA01975 for mbone@isi.edu; Thu, 17 Aug 1995 21:07:56 -0600 Date: Thu, 17 Aug 1995 21:07:56 -0600 From: Scott Chasin <chasin@crimelab.com> Message-Id: <199508180307.VAA01975@crimelab.com> To: mbone Subject: Information Content-Length: 113 Please send me more information on how I can receive multicast packets from the mbone. --S chasin@crimelab.com From list-mgr@ISI.EDU Thu Aug 17 20:23:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28798>; Thu, 17 Aug 1995 20:23:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28777>; Thu, 17 Aug 1995 20:23:05 -0700 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA28769>; Thu, 17 Aug 1995 20:23:04 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.6.12/8.6.12) id XAA08824; Thu, 17 Aug 1995 23:23:03 -0400 Date: Thu, 17 Aug 1995 23:15:48 From: "Dave Thaler" <thalerd@eecs.umich.edu> Subject: Mbone Accounting Message-Id: <19950817231548.29534@dip.eecs.umich.edu> To: mbone > Bill Fenner writes: > > The kernel keeps track of packet counts and byte counts. The SNMP version > > of mrouted can report this information; perhaps you can use SNMP to collect > > the data. Markus Buchhorn writes: > Is there a Solaris 2.x version as well ? I believe the latest kernel for Solaris is only a 3.3 kernel, which doesn't keep track of all the stuff SNMP requires. According to Sun's README file, "This 3.3 version of multicast will soon be replaced by version 3.5. Multicast 3.5 will also be included as part of a future release of Solaris." [dated June 15] Once the 3.5 kernel is available, then the SNMP-capable mrouted 3.6 should run on Solaris. Dave Thaler From list-mgr@ISI.EDU Fri Aug 18 10:42:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29468>; Fri, 18 Aug 1995 11:41:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29455>; Fri, 18 Aug 1995 11:41:43 -0700 Received: from FAUST.BBN.SAN-DIEGO.CA.US ([199.56.164.6]) by venera.isi.edu (5.65c/5.61+local-22) id <AA29448>; Fri, 18 Aug 1995 11:41:41 -0700 Received: (mfausett@localhost) by FAUST.BBN.SAN-DIEGO.CA.US (8.6.10/8.6.4) id OAA13266; Fri, 18 Aug 1995 14:42:19 -0400 Date: Fri, 18 Aug 1995 14:42:19 -0400 From: "Mark L. Fausett" <mfausett@BBN.COM> Message-Id: <199508181842.OAA13266@FAUST.BBN.SAN-DIEGO.CA.US> To: list-mgr, mbone Subject: Re: mrouted and Solaris 2.4 just in case; 2.2 works; DO *NOT* specify a rate_limit. mf From list-mgr@ISI.EDU Fri Aug 18 05:08:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00998>; Fri, 18 Aug 1995 12:12:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00982>; Fri, 18 Aug 1995 12:12:06 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA00973>; Fri, 18 Aug 1995 12:12:05 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15651(5)>; Fri, 18 Aug 1995 12:09:12 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Fri, 18 Aug 1995 12:09:01 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: "Mark L. Fausett" <mfausett@bbn.com> Cc: mbone Subject: Re: mrouted and Solaris 2.4 In-Reply-To: Your message of "Fri, 18 Aug 95 11:42:19 PDT." <199508181842.OAA13266@FAUST.BBN.SAN-DIEGO.CA.US> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Aug 1995 12:08:59 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Aug18.120901pdt.177475@crevenia.parc.xerox.com> In message <199508181842.OAA13266@FAUST.BBN.SAN-DIEGO.CA.US> you write: >2.2 works; DO *NOT* specify a rate_limit. Since 2.2 doesn't support rate limits, that's a good idea. The 2.2 config file parser silently ignores lines with syntax errors (which "rate_limit" is). If you want rate limits, run 3.4 (ftp://playground.sun.com/pub/multicast/) Bill From list-mgr@ISI.EDU Fri Aug 18 07:43:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07861>; Fri, 18 Aug 1995 14:44:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07816>; Fri, 18 Aug 1995 14:43:01 -0700 Received: from elxr.jpl.nasa.gov (elxr-fddi.jpl.nasa.gov) by venera.isi.edu (5.65c/5.61+local-22) id <AA07806>; Fri, 18 Aug 1995 14:43:00 -0700 Received: from localhost.jpl.nasa.gov (localhost.jpl.nasa.gov [127.0.0.1]) by elxr.jpl.nasa.gov (8.6.10/8.6.6) with SMTP id OAA24837 for <mbone@isi.edu>; Fri, 18 Aug 1995 14:43:01 -0700 Message-Id: <199508182143.OAA24837@elxr.jpl.nasa.gov> To: mbone Subject: Mrouted bogons? Date: Fri, 18 Aug 1995 14:43:01 -0700 From: Dave Hayes <dave@elxr.jpl.nasa.gov> Aug 18 14:42:12 elxr mrouted[9267]: warning - 192.203.230.241 reports an invalid origin (171.68.0.0) and/or mask (fffe0000) Is this me, or is it others as well? How do I shut it up? ------ Dave Hayes -- Institutional NETworks - Section 394 -- JPL/NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh Do what you can, with what you have, where you are. From list-mgr@ISI.EDU Fri Aug 18 07:53:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08240>; Fri, 18 Aug 1995 14:54:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08226>; Fri, 18 Aug 1995 14:54:35 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA08219>; Fri, 18 Aug 1995 14:54:34 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id OAA26830; Fri, 18 Aug 1995 14:53:57 -0700 Date: Fri, 18 Aug 1995 14:53:57 -0700 From: Dino Farinacci <dino@cisco.com> Message-Id: <199508182153.OAA26830@stilton.cisco.com> To: dave@elxr.jpl.nasa.gov Cc: mbone In-Reply-To: Dave Hayes's message of Fri, 18 Aug 1995 14:43:01 -0700 <199508182143.OAA24837@elxr.jpl.nasa.gov> Subject: Mrouted bogons? >> Aug 18 14:42:12 elxr mrouted[9267]: warning - 192.203.230.241 reports an invalid origin (171.68.0.0) and/or mask (fffe0000) >> >> Is this me, or is it others as well? How do I shut it up? We injected a CIDR prefix into the MBONE. Apparently the older versions of mrouted don't like it. I will withdraw the route. Dino From list-mgr@ISI.EDU Fri Aug 18 08:14:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09160>; Fri, 18 Aug 1995 15:19:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08988>; Fri, 18 Aug 1995 15:14:28 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA08981>; Fri, 18 Aug 1995 15:14:27 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15723(1)>; Fri, 18 Aug 1995 15:14:18 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Fri, 18 Aug 1995 15:14:08 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Dave Hayes <dave@elxr.jpl.nasa.gov> Cc: mbone Subject: Re: Mrouted bogons? In-Reply-To: Your message of "Fri, 18 Aug 95 14:43:01 PDT." <199508182143.OAA24837@elxr.jpl.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Aug 1995 15:14:00 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Aug18.151408pdt.177475@crevenia.parc.xerox.com> In message <199508182143.OAA24837@elxr.jpl.nasa.gov> you write: >Aug 18 14:42:12 elxr mrouted[9267]: warning - 192.203.230.241 reports an inval > id origin (171.68.0.0) and/or mask (fffe0000) > >Is this me, or is it others as well? It's your version of mrouted. Versions 3.5 and up handle CIDR routes; older versions don't. > How do I shut it up? Upgrade to 3.6 . Bill From list-mgr@ISI.EDU Mon Aug 21 04:47:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08563>; Mon, 21 Aug 1995 05:56:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08536>; Mon, 21 Aug 1995 05:54:40 -0700 Received: from pppl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA08528>; Mon, 21 Aug 1995 05:54:31 -0700 Received: from RAX (rax.pppl.gov [192.55.106.12]) by pppl.gov (8.6.12/8.6.10) with SMTP id IAA23080 for <MBONE@isi.edu>; Mon, 21 Aug 1995 08:54:30 -0400 From: schechtm@rax.pppl.gov Date: Mon, 21 Aug 1995 08:47:41 -0400 Message-Id: <95082108474146@rax.pppl.gov> To: MBONE Subject: mmcc multicast question X-Vms-To: MBONE@ISI.EDU X-Vms-Cc: SCHECHTM Hi, I've been trying to get mmcc working between several sites. It works perfectly point to point but will not connect with more than one other participant. The documentation indicates that multiparty conferencing is implemented although one of our colleagues thinks that it isn't possible. Any mmcc'ers out there? Thanks, Nathan Schechtman email: nschechtman@pppl.gov Princeton Plasma Physics Lab phone: 609-243-3465 PO Box 451 fax: 609-243-3086 Princeton, NJ 08543-0451 From list-mgr@ISI.EDU Tue Aug 22 08:32:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10329>; Mon, 21 Aug 1995 07:33:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10303>; Mon, 21 Aug 1995 07:32:39 -0700 Received: from sh.iij-mc.co.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA10296>; Mon, 21 Aug 1995 07:32:36 -0700 Received: from mcgw.iij-mc.co.jp (root@mcgw.iij-mc.co.jp [192.168.10.2]) by sh.iij-mc.co.jp (8.6.12+2.4W/3.3W9-SH) with ESMTP id XAA08472 for <mbone@isi.edu>; Mon, 21 Aug 1995 23:32:34 +0900 Received: from teapot.iij-mc.co.jp (teapot.iij-mc.co.jp [192.168.10.16]) by mcgw.iij-mc.co.jp (8.6.12+2.5Wb7/3.4W) with ESMTP id XAA19615; Mon, 21 Aug 1995 23:32:33 +0900 Received: from teapot (localhost [127.0.0.1]) by teapot.iij-mc.co.jp (8.6.12+2.4W/3.3W9-07/31/95) with ESMTP id XAA25426; Mon, 21 Aug 1995 23:33:21 +0900 Message-Id: <199508211433.XAA25426@teapot.iij-mc.co.jp> To: mbone Cc: mc-mbone@iij-mc.co.jp Subject: Fireworks session from Japan X-Mailer: Mew beta version 0.98 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 21 Aug 1995 23:32:05 +0900 From: YAMAMOTO Bunji <bunji@teapot.iij-mc.co.jp> We are planning to set a session as follows 1. Contents: Fireworks session from Nihon Sun Yoga office, Setagaya, Tokyo. 2. session Name: Setagaya Fireworks 3. Media: vat, nv or vic 4. Bandwidth: 128kbps 5. Begins at: 1995/08/26 1000UTC (=1900JST) 6. Ends at: 1995/08/26 1200UTC (=2100JST) 7. Initial TTL: 170 8. Contact To: Mbone Team, IIJ Media Communications Inc. 9. Mail Address: mc-mbone@iij-mc.co.jp -- YAMAMOTO Bunji <bunji@iij-mc.co.jp> IIJ Media Communications Inc. From list-mgr@ISI.EDU Mon Aug 21 05:48:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25905>; Mon, 21 Aug 1995 12:49:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25884>; Mon, 21 Aug 1995 12:48:38 -0700 Received: from vlsi.cs.caltech.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA25875>; Mon, 21 Aug 1995 12:48:35 -0700 Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1) id AA29035; Mon, 21 Aug 95 12:48:30 PDT Date: Mon, 21 Aug 95 12:48:30 PDT From: schooler@cs.caltech.edu (Eve Schooler) Message-Id: <9508211948.AA29035@vlsi.cs.caltech.edu> To: schechtm@rax.pppl.gov Subject: Re: mmcc multicast question Cc: schooler@cs.caltech.edu, homayoun, mbone Hi Nathan, >It works perfectly point to point but will not connect with more than one >other participant. The documentation indicates that multiparty >conferencing is implemented although one of our colleagues thinks >that it isn't possible. > >Any mmcc'ers out there? I originally worked on the mmcc code when at ISI, and have been helping others work toward a new release soon (we hope). It is supposed to support multiparty conferencing, so I wonder if you could describe your configuration more completely. On what platform(s) are you running the program? Are the machines on which you run the program multicast-capable, i.e., are they running multicast kernels. The tool tries to assign a multicast address for the underlying vat or nv or wb programs, but if your machine doesn't support multicast addressing then that wouldn't work properly. Also, is the ttl choice large enough for the media to reach the group of users? How far along does the tool get when it tries to establish a session? Does the invitation request make it to the different invitees? Do the underlying media tools get spawned? Could you describe any of the errors that the program prints out when trying to orchestrate a multi-way session? Eve p.s. - you can "call" me at schooler@fides.cs.caltech.edu. From list-mgr@ISI.EDU Mon Aug 21 14:31:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03372>; Mon, 21 Aug 1995 15:35:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03223>; Mon, 21 Aug 1995 15:34:37 -0700 Received: from pony-express.ims.advantis.com by venera.isi.edu (5.65c/5.61+local-22) id <AA03215>; Mon, 21 Aug 1995 15:34:34 -0700 Received: by pony-express.ims.advantis.com (5.67b/4.03) id AA16337; Mon, 21 Aug 1995 18:30:53 -0400 Received: from pangloss.ims.advantis.com(164.120.180.21) by pony-express.ims.advantis.com via smap (V1.3) id sma006095; Mon Aug 21 18:30:52 1995 Received: by pangloss.ims.advantis.com (AIX 3.2/UCB 5.64/4.03) id AA60495; Mon, 21 Aug 1995 18:34:30 -0400 Date: Mon, 21 Aug 1995 18:31:20 -0400 (EDT) From: Andrew Germaine <andrewg@ims.advantis.com> Subject: setting up a session To: mbone Message-Id: <Pine.3.85.9508211820.A44283-0100000-0100000@pangloss.ims.advantis.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is there anything special I need to do to establish a session of audio and video for others to share besides limiting my transmission to 150kbs? We'd like to share an event with others for about 2 weeks. Is this too long a duration? This event will also be ported to CU-SeeMe. I can't say what it is yet, but it will be fun :) Andrew J. Germaine Advantis Intermediate Technical Staff 1311 Mamaroneck Ave. OpenNet Network Support Center White Plains, NY 10605 Internetworking & Multimedia Services 1-914-684-4433 From list-mgr@ISI.EDU Tue Aug 22 13:43:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18444>; Tue, 22 Aug 1995 13:41:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18425>; Tue, 22 Aug 1995 13:40:40 -0700 Received: from mail.waite.com ([204.182.60.2]) by venera.isi.edu (5.65c/5.61+local-22) id <AA18412>; Tue, 22 Aug 1995 13:40:34 -0700 Received: from [204.182.60.135] by mail.waite.com with SMTP (MailShare 1.0b8); Tue, 22 Aug 1995 13:43:14 +0000 X-Sender: jmiller@mail.waite.com Message-Id: <v02110100ac5f68d34521@[204.182.60.135]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: jmiller@waite.com (Joanne Miller) Subject: subscribe mbone mailing list Date: Tue, 22 Aug 1995 13:43:14 +0000 subscribe From list-mgr@ISI.EDU Tue Aug 22 13:03:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19500>; Tue, 22 Aug 1995 14:06:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19474>; Tue, 22 Aug 1995 14:06:17 -0700 Received: from NPT.NUWC.NAVY.MIL by venera.isi.edu (5.65c/5.61+local-22) id <AA19466>; Tue, 22 Aug 1995 14:06:10 -0700 Received: from iris-23 ("port 1341"@IRIS-23.NPT.NUWC.NAVY.MIL) by Npt.NUWC.Navy.Mil (PMDF V5.0-4 #12906) id <01HUDQLIH3W291VXDM@Npt.NUWC.Navy.Mil>; Tue, 22 Aug 1995 17:08:54 -0400 (EDT) Received: by iris-23 (920330.SGI/920502.SGI) for @npt.nuwc.navy.mil:nearnet-eng@nic.near.net id AA05988; Tue, 22 Aug 1995 17:03:27 -0400 Date: Tue, 22 Aug 1995 17:03:27 -0400 From: burcak@iris-23.npt.nuwc.navy.mil (Michael Burcak) Subject: MBONE Tunnel feed request. To: mbone, mbone-request, nearnet-eng@nic.near.net Message-Id: <9508222103.AA05988@iris-23.Npt.NUWC.Navy.Mil> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="Boundary (ID S92oKvah5c8Xk+3Moe3sRw)" --Boundary (ID S92oKvah5c8Xk+3Moe3sRw) Content-type: TEXT/PLAIN I am requesting access to the MBONE and I need a tunnel feed. My organization is the Naval Undersea Warfare Center (NUWC) Division Newport Newport, Rhode Island 02841 Michael Burcak Code2212 (401) 841 3284 (phone) (401) 841 4749 (fax) We are trying to get "online" for Wednesday, August 23, 1995 by 1:00 pm EDT. The mrouter server will be designated as indigo-4.npt.nuwc.navy.mil (129.190.22.134) Any help in "hooking in" is greatly appreciated. Thank you. Mike Burcak burcak@ada.npt.nuwc.navy.mil --Boundary (ID S92oKvah5c8Xk+3Moe3sRw)-- From list-mgr@ISI.EDU Tue Aug 22 09:06:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25416>; Tue, 22 Aug 1995 16:08:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25384>; Tue, 22 Aug 1995 16:07:37 -0700 Received: from elroy.jpl.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA25375>; Tue, 22 Aug 1995 16:07:35 -0700 Received: from isolar.tujunga.ca.us by elroy.jpl.nasa.gov (4.1/SMI-4.1+DXR) id AA02962; Tue, 22 Aug 95 16:07:34 PDT Received: by isolar.Tujunga.CA.US (4.1/SATAN-6.6.6) id AA06746; Tue, 22 Aug 95 16:06:41 PDT Date: Tue, 22 Aug 95 16:06:41 PDT From: earle@isolar.Tujunga.CA.US (Greg Earle) Message-Id: <9508222306.AA06746@isolar.Tujunga.CA.US> To: mbone Subject: Ethernet switches blocking session announcements? Cc: earle@isolar.Tujunga.CA.US I've run into a peculiar problem here. I have an mrouter (elroy.JPL.NASA.GOV; mrouted 3.5) that spits Multicast onto an Ethernet subnet (128.149.24.xxx). On that subnet, I have another mrouter (also running mrouted 3.5) which straddles both this 128.149.24.xxx subnet as well as having a Crescendo (now Cisco) SBus CDDI card, which is plugged into a Crescendo Workgroup concentrator and thus onto a mainly FDDI/CDDI ring. We have some Cisco (nee Crescendo) Catalyst Ethernet switches that are on this combined CDDI/FDDI ring. Thus, we have some hosts which are Ethernet-only that are hooked into this CDDI/FDDI ring (128.149.177.xxx). What I've discovered is that a host which is FDDI-only (we have one such host, with an SBus FDDI card) on this 128.149.177.xxx subnet can see session announcements and join Multicast groups just fine, so everything between it and the mrouter on the dual-homed host straddling the nets works just fine. I've also tested other hosts that are dual-homed like the mrouter, and those work as well. I even ifconfig'd their Ethernet interfaces down to make sure they were getting session announcements via the CDDI side, and they still work. But hosts that are Ethernet-only and attached through these Catalyst switches don't get session announcements, and when they try to join sessions (e.g., because of existing sd_cache entries), nothing happens. Yet if I run "sd" on, e.g., the FDDI-only host that works, then the session announcements get to these Ethernet switch-connected hosts, and any session traffic that gets put onto the FDDI/CDDI subnet from the "working" host is seen by the Ethernet switch-connected hosts, so they can receive the session sorta by proxy. If I then quit out of "vat" and "sd" on the working host, however, pretty soon when the mrouter gets told the working host has dropped out and sends the prune up the line, and the non-working host audio drops out and all the other session participants names slowly disappear. In addition, when the session is up, other working sessions don't see the non-working host as a participant. So obviously the mrouter is not seeing anything from the non-working host multicast-wise. No IGMP reports, no nothing. Has anyone seen this type of behavior before? Is it common for Ethernet switches to allow Multicast traffic in, but not forward it out? Was the code name for these switches "Roach Motel"? :-) (We tried manually adding a CAM table entry in the Cisco switch to forward packets with a destination MAC address of 1:0:5e:2:7f:ff to the FDDI side, but this still didn't help. The non-working hosts on the Catalyst switches are SPARCstation-20/50's running Solaris 2.3.) - Greg From list-mgr@ISI.EDU Tue Aug 22 10:33:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29790>; Tue, 22 Aug 1995 17:34:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29775>; Tue, 22 Aug 1995 17:33:32 -0700 Received: from nuku.nosc.mil by venera.isi.edu (5.65c/5.61+local-22) id <AA29768>; Tue, 22 Aug 1995 17:33:29 -0700 Received: from neko by nuku.nosc.mil (NX5.67e/NX3.0M) id AA00459; Tue, 22 Aug 95 17:33:22 -0700 Received: by neko.nosc.mil (NX5.67e/NX3.0S) id AA05463; Tue, 22 Aug 95 17:33:21 -0700 Message-Id: <9508230033.AA05463@neko.nosc.mil> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Ron Broersma <ron@neko.nosc.mil> Date: Tue, 22 Aug 95 17:33:19 -0700 To: burcak@iris-23.npt.nuwc.navy.mil (Michael Burcak) Subject: Re: MBONE Tunnel feed request. Cc: mbone, mbone-request, nearnet-eng@nic.near.net, phil@arl.mil Reply-To: ron@nuku.nosc.mil References: <9508222103.AA05988@iris-23.Npt.NUWC.Navy.Mil> Since I-DREN is one of your service providers, I would suggest you get a feed via one of the DREN nodes. The ARL node would be the best choice. I'll copy Phil on this message to see if they can set you up. If you don't hear from them in time, I can feed you from here via DREN. --Ron Begin forwarded message: Date: Tue, 22 Aug 1995 17:03:27 -0400 From: burcak@iris-23.npt.nuwc.navy.mil (Michael Burcak) Subject: MBONE Tunnel feed request. To: mbone@ISI.EDU, mbone-request@ISI.EDU, nearnet-eng@nic.near.net I am requesting access to the MBONE and I need a tunnel feed. My organization is the Naval Undersea Warfare Center (NUWC) Division Newport Newport, Rhode Island 02841 Michael Burcak Code2212 (401) 841 3284 (phone) (401) 841 4749 (fax) We are trying to get "online" for Wednesday, August 23, 1995 by 1:00 pm EDT. The mrouter server will be designated as indigo-4.npt.nuwc.navy.mil (129.190.22.134) Any help in "hooking in" is greatly appreciated. Thank you. Mike Burcak burcak@ada.npt.nuwc.navy.mil From list-mgr@ISI.EDU Tue Aug 22 11:43:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02688>; Tue, 22 Aug 1995 19:12:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02667>; Tue, 22 Aug 1995 19:10:59 -0700 Received: from elroy.jpl.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA02660>; Tue, 22 Aug 1995 19:10:58 -0700 Received: from isolar.tujunga.ca.us by elroy.jpl.nasa.gov (4.1/SMI-4.1+DXR) id AA09618; Tue, 22 Aug 95 19:10:46 PDT Received: by isolar.Tujunga.CA.US (4.1/SATAN-6.6.6) id AA08808; Tue, 22 Aug 95 18:43:57 PDT Date: Tue, 22 Aug 95 18:43:57 PDT From: earle@isolar.Tujunga.CA.US (Greg Earle) Message-Id: <9508230143.AA08808@isolar.Tujunga.CA.US> To: mbone Subject: Re: Ethernet switches blocking session announcements? Cc: dplist@phoenix.ACN.Purdue.EDU, earle@isolar.Tujunga.CA.US I had said: > I've run into a peculiar problem here. I have an mrouter (elroy.JPL.NASA.GOV; > mrouted 3.5) that spits Multicast onto an Ethernet subnet (128.149.24.xxx). > On that subnet, I have another mrouter (also running mrouted 3.5) which > straddles both this 128.149.24.xxx subnet as well as having a Crescendo (now > Cisco) SBus CDDI card, which is plugged into a Crescendo Workgroup > concentrator and thus onto a mainly FDDI/CDDI ring. [Description of problem elided.] > But hosts that are Ethernet-only and attached through these Catalyst switches > don't get session announcements, and when they try to join sessions (e.g., > because of existing sd_cache entries), nothing happens. Well, I figured out what it is, and it turned out to be bizarre. The other Cisco Catalyst Ethernet switch-connected hosts that I thought didn't work actually *do* work. It turned out that "mrouted" was dead (dunno why) on the mrouter that straddles the Ethernet and CDDI/FDDI nets. But in the current round of tests, obviously I made sure it was working. :-) In this round (which caused me to write), I was testing from my officemate's machine. When that didn't work, I assumed by mathematical induction that if N=1 doesn't work, then N=2, 3, 4, ... don't work either. Ooops. Turned out that only my officemate's SPARCstation-20 didn't work! Now here's where things get weird. The machine in question is configured with the Dialup PPP (DP) 3.1.2 release. (Yes, I know that's a couple of releases behind.) In /etc/rc2.d/S72inetsvc, it sets the default Multicast route to point to itself: # # Add a static route for multicast packets out our default interface. # The default interface is the interface that corrsponds to the node name. # echo "Setting default interface for multicast: \c" /usr/sbin/route add "224.0.0.0" "`uname -n`" 0 Later on, DP is set up in /etc/rc2.d/S99dpconfig. Now, I don't have the vaguest idea how this happened, but somehow the route to 224.0.0.0 - which "netstat -r" flags as being through the "le0" Ethernet interface - magically gets re-vectored out through the "dp0" PPP interface! I swear I am not making this up. (-: I'd run "sd" and "netstat -rn", and it would most emphatically tell me that the route to 224.0.0.0 was via "le0", not "dp0". Yet I started to notice that the modem kept trying to dial out ... and sure enough, in the DP log: 08/22 15:59:06 246 dpd: request received: ip/128.149.177.10:igmp -> \ ip/224.2.127.255:igmp If I tried to remove the route via route delete net 224.0.0.0 128.149.177.10 I'd get something like delete net 224.0.0.0: gateway 128.149.177.10: No such file or directory Yet "netstat -r" would still show it there! Finally I killed off the running "dpd" daemon, ran "/etc/dpctl -k" and then "/etc/dpctl -u" to disable DP, and at that point I was able to remove the 224.0.0.0 route. Once this was done, the MBONE tools started working again. I don't know if this is a Solaris 2.3 kernel problem (host was only running "in.routed -q"), a DP problem or what. All I know is that the Multicast route somehow got re-pointed out the wrong (PPP) interface somehow, and that is what caused things to not work. When DP 4.0 is finalized I will try and test this strange occurance again. Anyway, all better now. - Greg From list-mgr@ISI.EDU Wed Aug 23 18:11:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17314>; Wed, 23 Aug 1995 07:13:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17300>; Wed, 23 Aug 1995 07:12:29 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA17293>; Wed, 23 Aug 1995 07:12:23 -0700 Received: from it.kth.se (e93_mda@nostromo.electrum.kth.se [130.237.215.5]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id QAA07156 for <mbone@isi.edu>; Wed, 23 Aug 1995 16:11:59 +0200 Message-Id: <199508231411.QAA07156@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: mbone Subject: Mbone tunnels on fire!! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Aug 1995 16:11:58 +0200 From: Magnus <e93_mda@it.kth.se> Hi! Due to a transatlantic cable got overrun by a fishingboat we have got a somewhat changed map of the world. For instance is the 34 Mbit line from Nordu.net down. I called Mark Handley and we found the following things: There were 4 tunnels out of Europe: 1 from stockholm to mbone-east.ans.net - over broken 34Mbps link - mbone-east.ans.net appears to be down 1 from UK to mbone.sura.net - over ARPA link (link currently not working - don't know why yet) - both mrouteds up, but tunnel is down 1 from CERN - mbone-east.ans.net appears to be down - mbone.cern.net says tunnel is down 1 from France to mae-east.psi.net - mae-east.psi.net doesn't respond, but everyone else says it's up - route from mae-east to rest of US appears to be a bit odd: shrew.cs.ucl.ac.uk: mri wtn-mp1-mae-east-pe.sura.net 192.41.177.199 (wtn-mp1-mae-east-pe.sura.net) [version 1.0]: 2 mins 46 secs ... 192.41.177.199 -> 192.41.177.247 (mae-bone.psi.net) [1/1] shrew.cs.ucl.ac.uk: mr -s wtn-mp1-mae-east-pe.sura.net -d vet.ee.lbl.gov wtn-mp1-mae-east-pe.sura.net -> wtn-ms1.sura.net [1/1][1/1] wtn-ms1.sura.net -> iguana.nrl.navy.mil [1/64][2/65] iguana.nrl.navy.mil -> aai.arl.mil [2/48][4/65] aai.arl.mil -> mbone-dmz.nosc.mil [1/48][5/65] mbone-dmz.nosc.mil -> brahms.sdsc.edu [1/64][6/68] brahms.sdsc.edu -> mbone.nsi.nasa.gov [1/64][7/69] mbone.nsi.nasa.gov -> llnl-mr2.es.net [1/64][8/70] llnl-mr2.es.net -> lbl-mr1.es.net [1/8][9/70] lbl-mr1.es.net -> mr1.lbl.gov [1/48][10/70] mr1.lbl.gov -> vet.ee.lbl.gov [3/1][13/70] The normal production trafic from Nordu.net has gone back to the old 4Mbps line, but it is highly saturated. Those of you that have machines on these transatlantic tunnels, please ensure that they are up (if possible). Notify the list on your findings. We have problem accessing several machines with mrinfo and mtrace. Please ensure connectivity and if necessary consider a upgrade to a more recent version of mrouted (3.3 - 3.6 .... 3.6 with snmp preferably :-). When debugging a failure like this we need such tools. Magnus Danielson KTH/IT From list-mgr@ISI.EDU Wed Aug 23 05:11:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18635>; Wed, 23 Aug 1995 08:14:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18594>; Wed, 23 Aug 1995 08:13:04 -0700 Received: from fnal.fnal.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA18581>; Wed, 23 Aug 1995 08:13:01 -0700 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HUEQBVH2Q8001IS0@FNAL.FNAL.GOV>; Wed, 23 Aug 1995 10:11:55 -0500 (CDT) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA10829; Wed, 23 Aug 95 10:11:10 CDT Date: Wed, 23 Aug 1995 10:11:09 -0500 From: Matt Crawford <crawdad@FNAL.FNAL.GOV> Subject: Re: Ethernet switches blocking session announcements? In-Reply-To: Your message of Tue, 22 Aug 95 16:06:41 PDT. <9508222306.AA06746@isolar.Tujunga.CA.US> Sender: crawdad@munin.fnal.gov To: earle@isolar.Tujunga.CA.US (Greg Earle) Cc: mbone Message-Id: <9508231511.AA10829@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6, 8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r For many months now, I've been connected to the same brand of etherswitch you have. When I first activiated the IGMP smarts in the switch I found that it translated ethernet IGMP messages to the wrong FDDI format and the routers never saw my membership reports. Within a week or s, Cisco put that right with a new software load. Ask for release 3.18 or newer. (It's not clear this belonged on the mbone list. In fact, it's pretty clear it didn't.) _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From list-mgr@ISI.EDU Wed Aug 23 09:07:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22554>; Wed, 23 Aug 1995 10:11:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22426>; Wed, 23 Aug 1995 10:09:56 -0700 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA22418>; Wed, 23 Aug 1995 10:09:55 -0700 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA19942; Wed, 23 Aug 1995 13:07:44 +0500 Message-Id: <9508231707.AA19942@msf.psi.net.> To: Magnus <e93_mda@it.kth.se> Cc: mbone Subject: Re: Mbone tunnels on fire!! In-Reply-To: Your message of "Wed, 23 Aug 1995 16:11:58 +0200." <199508231411.QAA07156@piraya.electrum.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <19940.809197663.1@msf.psi.net> Date: Wed, 23 Aug 1995 13:07:43 -0400 From: "Mark S. Fedor" <fedor@msf.psi.net> Content-Length: 1146 > > 1 from France to mae-east.psi.net > - mae-east.psi.net doesn't respond, but everyone else says it's up > - route from mae-east to rest of US appears to be a bit odd: > mae-bone.psi.net only has routes for the hosts it tunnels with. It is up. Here is the mrinfo: 192.41.177.247 (mae-bone.psi.net) [version 3.6]: 192.41.177.247 -> 192.41.177.197 (wtn-ms1.sura.net) [1/64] 192.41.177.247 -> 192.41.177.199 (wtn-mp1.sura.net) [1/64] 192.41.177.247 -> 192.41.177.115 (mae-east.digex.net) [1/64] 192.41.177.247 -> 38.145.250.3 (rambone.psi.net) [1/10/tunnel] 192.41.177.247 -> 149.127.6.110 (skunkworks.psi.com) [1/10/tunnel] 192.41.177.247 -> 192.36.148.206 (stockholm.mbone.ebone.net) [1/64/tunnel/down] 192.41.177.247 -> 128.241.0.91 (VINEGAR.SESQUI.NET) [1/64/tunnel] 192.41.177.247 -> 192.70.92.133 (fmroute1-1.exp.edf.fr) [1/64/tunnel] 192.41.177.247 -> 137.39.43.34 (MBONE1.UU.NET) [1/64/tunnel] 192.41.177.247 -> 194.132.178.10 (194.132.178.10) [1/64/tunnel/down] At times, I've had to disable the physint because of sub-optimal performance when the native multicast speakers on mae-east are in the game. Mark From list-mgr@ISI.EDU Wed Aug 23 03:39:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24250>; Wed, 23 Aug 1995 10:43:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24226>; Wed, 23 Aug 1995 10:42:58 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA24215>; Wed, 23 Aug 1995 10:42:56 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14575(3)>; Wed, 23 Aug 1995 10:40:01 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Wed, 23 Aug 1995 10:39:48 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Magnus <e93_mda@it.kth.se> Cc: mbone Subject: Re: Mbone tunnels on fire!! In-Reply-To: Your message of "Wed, 23 Aug 95 07:11:58 PDT." <199508231411.QAA07156@piraya.electrum.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Aug 1995 10:39:38 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Aug23.103948pdt.177475@crevenia.parc.xerox.com> In message <199508231411.QAA07156@piraya.electrum.kth.se> you write: >1 from stockholm to mbone-east.ans.net > - over broken 34Mbps link > - mbone-east.ans.net appears to be down > >1 from CERN > - mbone-east.ans.net appears to be down > - mbone.cern.net says tunnel is down mbone-east.ans.net disappeared a few weeks ago. I haven't been able to get a straight answer out of ANS as to why yet. >1 from France to mae-east.psi.net > - mae-east.psi.net doesn't respond, but everyone else says it's up mae-east.psi.net has a much abbreviated routing table, for security reasons. > - route from mae-east to rest of US appears to be a bit odd: > >shrew.cs.ucl.ac.uk: mr -s wtn-mp1-mae-east-pe.sura.net -d vet.ee.lbl.gov >wtn-mp1-mae-east-pe.sura.net -> wtn-ms1.sura.net [1/1][1/1] >wtn-ms1.sura.net -> iguana.nrl.navy.mil [1/64][2/65] >iguana.nrl.navy.mil -> aai.arl.mil [2/48][4/65] >aai.arl.mil -> mbone-dmz.nosc.mil [1/48][5/65] >mbone-dmz.nosc.mil -> brahms.sdsc.edu [1/64][6/68] >brahms.sdsc.edu -> mbone.nsi.nasa.gov [1/64][7/69] >mbone.nsi.nasa.gov -> llnl-mr2.es.net [1/64][8/70] >llnl-mr2.es.net -> lbl-mr1.es.net [1/8][9/70] >lbl-mr1.es.net -> mr1.lbl.gov [1/48][10/70] >mr1.lbl.gov -> vet.ee.lbl.gov [3/1][13/70] This is just mr not knowing the full topology. Use mtrace. Mtrace from 128.3.112.48 to 128.16.64.19 via group 224.2.0.1 Querying full reverse path... 0 shrew.cs.ucl.ac.uk (128.16.64.19) -1 lea.cs.ucl.ac.uk (128.16.64.24) DVMRP thresh^ 1 -204423 ms -2 ? (194.104.0.17) DVMRP thresh^ 32 26 ms -3 lunde.runit.sintef.no (129.241.120.11) DVMRP thresh^ 6 290 ms -4 stockholm.mbone.ebone.net (192.36.148.206) DVMRP thresh^ 40 24765 ms -5 fmroute1-1.exp.edf.fr (192.70.92.133) DVMRP thresh^ 48 -178557 ms -6 mae-bone.psi.net (192.41.177.247) DVMRP thresh^ 64 -36094 ms -7 VINEGAR.SESQUI.NET (128.241.0.91) DVMRP thresh^ 64 475 ms -8 mbone.isi.edu (204.140.133.4) DVMRP thresh^ 64 491 ms -9 mb204.isi.edu (204.140.133.8) DVMRP thresh^ 32 -28828 ms -10 cub.isi.edu (128.9.160.153) DVMRP thresh^ 1 489 ms -11 la.dart.net (140.173.128.1) DVMRP thresh^ 1 503 ms -12 ames.dart.net (140.173.112.2) DVMRP thresh^ 1 520 ms -13 lbl.dart.net (140.173.96.1) DVMRP thresh^ 1 534 ms Next router no mtrace -14 * vet.ee.lbl.gov (192.12.173.1) didn't respond Round trip time 641 ms >Those of you that have machines on these transatlantic tunnels, please ensure >that they are up (if possible). Notify the list on your findings. I have been in touch with ANS about mbone-east.ans.net; I will certainly let the list know if I find out anything definite. Bill From list-mgr@ISI.EDU Wed Aug 23 04:40:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26495>; Wed, 23 Aug 1995 11:43:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26455>; Wed, 23 Aug 1995 11:42:10 -0700 Received: from mercury.Sun.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA26440>; Wed, 23 Aug 1995 11:42:05 -0700 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id LAA15652; Wed, 23 Aug 1995 11:41:44 -0700 Received: from jurassic.Eng.Sun.COM (jurassic-248.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13844; Wed, 23 Aug 1995 11:41:39 -0700 Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id LAA19931; Wed, 23 Aug 1995 11:41:20 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id LAA24377; Wed, 23 Aug 1995 11:40:52 -0700 Date: Wed, 23 Aug 1995 11:40:52 -0700 From: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Message-Id: <199508231840.LAA24377@bobo.Eng.Sun.COM> To: earle@isolar.Tujunga.CA.US Subject: Re: Ethernet switches blocking session announcements? Cc: mbone, dplist@phoenix.ACN.Purdue.EDU Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" > The machine in question is configured with the Dialup PPP (DP) 3.1.2 release. > (Yes, I know that's a couple of releases behind.) In /etc/rc2.d/S72inetsvc, > it sets the default Multicast route to point to itself: > > # > # Add a static route for multicast packets out our default interface. > # The default interface is the interface that corrsponds to the node name. > # > echo "Setting default interface for multicast: \c" > /usr/sbin/route add "224.0.0.0" "`uname -n`" 0 > > Later on, DP is set up in /etc/rc2.d/S99dpconfig. > > Now, I don't have the vaguest idea how this happened, but somehow the route to > 224.0.0.0 - which "netstat -r" flags as being through the "le0" Ethernet > interface - magically gets re-vectored out through the "dp0" PPP interface! It is an illusion caused by a bug in the way the information is provided to netstat. I'm assuming that the dp0 interface is unnumbered i.e. it has the same IP address as the le0 interface. In this case the kernel will tell netstat -r that the interface is the first interface that matches the same source address. However, this netstat -r confusion is not the cause of the MBONE tools not working. The MBONE tools fail due to similar confusion in IP between the unnumbered dp0 interface and le0. This causes transmitted multicast packets to be sent to the wrong interface and IP_ADD_MEMBERSHIP are also likely to apply to the wong interface. You can check 'netstat -g' after the mbone tools have been started. A workaround is to try to move the "dp0" interface after "le0" in the output of 'ifconfig -a'. This can be accomplished by either ensuring that dp0 if 'ifconfig plumb'ed after le0 or by redoing the plumbing after the interfaces are up. The former can be done by removing /etc/hostname.dp0 and adding a separate startup script for dp0 that is run during the boot. The latter can be done by: ifconfig dp0 unplumb ifconfig dp0 plumb ifconfig dp0 <address> netmask <netmask> up Erik Nordmark Internet Engineering, SunSoft > I swear I am not making this up. (-: I'd run "sd" and "netstat -rn", and it > would most emphatically tell me that the route to 224.0.0.0 was via "le0", not > "dp0". Yet I started to notice that the modem kept trying to dial out ... > and sure enough, in the DP log: > > 08/22 15:59:06 246 dpd: request received: ip/128.149.177.10:igmp -> \ > ip/224.2.127.255:igmp > > If I tried to remove the route via > > route delete net 224.0.0.0 128.149.177.10 > > I'd get something like > > delete net 224.0.0.0: gateway 128.149.177.10: No such file or directory > > Yet "netstat -r" would still show it there! > > Finally I killed off the running "dpd" daemon, ran "/etc/dpctl -k" and then > "/etc/dpctl -u" to disable DP, and at that point I was able to remove the > 224.0.0.0 route. Once this was done, the MBONE tools started working again. > > I don't know if this is a Solaris 2.3 kernel problem (host was only running > "in.routed -q"), a DP problem or what. All I know is that the Multicast route > somehow got re-pointed out the wrong (PPP) interface somehow, and that is what > caused things to not work. When DP 4.0 is finalized I will try and test this > strange occurance again. Anyway, all better now. > > - Greg > > From list-mgr@ISI.EDU Thu Aug 24 09:47:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24983>; Thu, 24 Aug 1995 16:48:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24956>; Thu, 24 Aug 1995 16:47:17 -0700 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA24949>; Thu, 24 Aug 1995 16:47:16 -0700 Received: from icsib67.ICSI.Berkeley.EDU (whetten@icsib67.ICSI.Berkeley.EDU [128.32.201.167]) by icsia.ICSI.Berkeley.EDU (8.6.12/HUB+V8$Revision: 1.23 $) with ESMTP id QAA08265; Thu, 24 Aug 1995 16:47:15 -0700 Received: (whetten@localhost) by icsib67.ICSI.Berkeley.EDU (8.6.12/1.8) id QAA01897; Thu, 24 Aug 1995 16:47:12 -0700 Date: Thu, 24 Aug 1995 16:47:11 -0700 (PDT) From: Brian Whetten <whetten@ICSI.Berkeley.EDU> To: Van Jacobson <van@ee.lbl.gov> Cc: mbone Subject: Re: multicast traffic In-Reply-To: <199508240050.RAA10960@rx7.ee.lbl.gov> Message-Id: <Pine.SUN.3.91.950824163733.1873A-100000@icsib67> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We would like to run a series of tests in the near future, examining the performance of reliable multicast traffic over the mbone. We are looking forwards to the day in the hopfully not too distant future where reliable information distribution can be supported through the mbone rather than through lots of TCP connections. To this extent, we would like to study the effects that your congestion control mechanisms have on traffic in the mbone. Do you have some suggestions as to how we can do this and minimize the negative effects on mbone traffic? We will attempt to perform these tests very early in the morning, when we see that there are few other sessions running here. We will attempt to limit the traffic to 128 Kbps, although we would like to experiment briefly with higher rates if we can find a time when this is not disruptive. Our traffic is flow-controlled using mechanisms similar to TCP. We also have rate controls, but these are for the effective throughput, not for the instantaneous bit rate. Thanks! Brian From list-mgr@ISI.EDU Thu Aug 24 21:30:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05197>; Thu, 24 Aug 1995 22:43:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04949>; Thu, 24 Aug 1995 22:31:20 -0700 Received: from davinci.gmu.edu ([206.197.101.10]) by venera.isi.edu (5.65c/5.61+local-22) id <AA04942>; Thu, 24 Aug 1995 22:31:17 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id BAA02035; Fri, 25 Aug 1995 01:30:47 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199508250530.BAA02035@davinci.gmu.edu> Subject: Re: multicast traffic To: whetten@ICSI.Berkeley.EDU (Brian Whetten) Date: Fri, 25 Aug 1995 01:30:46 -0400 (EDT) Cc: van@ee.lbl.gov, mbone In-Reply-To: <Pine.SUN.3.91.950824163733.1873A-100000@icsib67> from "Brian Whetten" at Aug 24, 95 04:47:11 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1348 One question. Very early in the morning for which part of the world? Michael > > > We would like to run a series of tests in the near future, examining > the performance of reliable multicast traffic over the mbone. We are > looking forwards to the day in the hopfully not too distant future where > reliable information distribution can be supported through the mbone > rather than through lots of TCP connections. To this extent, we > would like to study the effects that your congestion control mechanisms > have on traffic in the mbone. Do you have some suggestions as to how we > can do this and minimize the negative effects on mbone traffic? We > will attempt to perform these tests very early in the morning, when > we see that there are few other sessions running here. We will attempt > to limit the traffic to 128 Kbps, although we would like to experiment > briefly with higher rates if we can find a time when this is not disruptive. > > Our traffic is flow-controlled using mechanisms similar to TCP. We also > have rate controls, but these are for the effective throughput, not for > the instantaneous bit rate. > > Thanks! > Brian > -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Sat Aug 26 02:12:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09123>; Fri, 25 Aug 1995 01:17:03 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09088>; Fri, 25 Aug 1995 01:14:58 -0700 Received: from sh.wide.ad.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA09081>; Fri, 25 Aug 1995 01:14:55 -0700 Received: by sh.wide.ad.jp (8.6.11+2.5Wb2/6.0) id RAA04163; Fri, 25 Aug 1995 17:12:40 +0900 Message-Id: <199508250812.RAA04163@sh.wide.ad.jp> To: mbone Subject: MBONE broadcast of launching JCSAT-3 communication satellite Date: Fri, 25 Aug 95 17:12:40 +0900 From: Hiroyuki Kusumoto <kusumoto@sh.wide.ad.jp> We are planning to transmit the sessions 29th of August 1995. It will take place from 08:30-10:30(JST)/23:30-01:30(GMT) The sessions will be announced in sd with a ttl of 127. vat(pcm) and nv will be used. If there are any conflicts on that day or questions, please contact H.Kusumoto (kusumoto@wide.ad.jp) JCSAT-3 is the communication satellite of Japan Satellite Systems Inc. JCSAT-3 will cover India, China, Japan, Hawaii, Australia and many areas in Asia. Experimentally, We, WIDE project, are using several 2Mbps satellite channels for the Internet communication in JAPAN. We hope JCSAT-3 will provide inter-nations Internet communication. -- H.K From list-mgr@ISI.EDU Fri Aug 25 06:51:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14923>; Fri, 25 Aug 1995 07:56:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14883>; Fri, 25 Aug 1995 07:53:41 -0700 Received: from prom.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA14875>; Fri, 25 Aug 1995 07:53:39 -0700 Received: (dschluss@localhost) by prom.engin.umich.edu (8.6.12/8.6.4) id KAA26723; Fri, 25 Aug 1995 10:53:37 -0400 Date: Fri, 25 Aug 1995 10:51:21 -0400 (EDT) From: "david a. schlussel" <dschluss@engin.umich.edu> Subject: Re: help with nv!! (fwd) To: mbone Message-Id: <Pine.3.87.9508251021.G26376-0100000@prom.engin.umich.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII could anyone with a sun video pix help her out? +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ---------- Forwarded message ---------- Date: Fri, 25 Aug 1995 10:59:29 -0300 From: Jaqueline Gomes Pedreira <jaquel@inf.puc-rio.br> To: dschluss@engin.umich.edu Cc: jaquel@engin.umich.edu Subject: Re: help with nv!! > From dschluss@engin.umich.edu Thu Aug 24 17:52:39 1995 > Date: Thu, 24 Aug 1995 16:51:58 -0400 (EDT) > From: "david a. schlussel" <dschluss@engin.umich.edu> > Subject: Re: help with nv!! > To: Jaqueline Gomes Pedreira <jaquel@inf.puc-rio.br> > Mime-Version: 1.0 > > wondering if you've made any progress on this... > > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > + David Schlussel + > + dschluss@umich.edu + > + MCIT-Special Projects + > + http://www.umich.edu/~dschluss/ + > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > > On Mon, 21 Aug 1995, Jaqueline Gomes Pedreira wrote: > > > Hi, > > > > We're studying Computer Enginnering at PUC - Rio de Janeiro - Brazil. > > > > We've been trying to run nv. We work with a Sparcstation 20 running Solaris withSunVideo 1.0 capture board and camera. > > > > When we start nv it does not recognize this video board because it keeps > > sending our screen image instead of the image captured by the camera when we choose the "start sending" button. > > > > Could you please help us? > > > > Thank you in advance :) > > > > Jaqueline Pedreira - jaquel@inf.puc-rio.br > > > > > > > > Hi David, In fact, I've made progress, because now i know what's the problem! You're right, the problem is with the grabber controlls. Only the option "X11 Screen Grab" is enable. Do you know what can i do for enable the option "Sun Video Pix" ? Thanks for the response :) Jaqueline Pedreira jaquel@inf.puc-rio.br From list-mgr@ISI.EDU Fri Aug 25 01:23:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15574>; Fri, 25 Aug 1995 08:24:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15562>; Fri, 25 Aug 1995 08:24:03 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA15555>; Fri, 25 Aug 1995 08:24:01 -0700 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14895(1)>; Fri, 25 Aug 1995 08:23:57 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16136>; Fri, 25 Aug 1995 08:23:47 -0700 To: "david a. schlussel" <dschluss@engin.umich.edu> Cc: mbone Subject: Re: help with nv!! (fwd) In-Reply-To: Your message of "Fri, 25 Aug 95 07:51:21 PDT." <Pine.3.87.9508251021.G26376-0100000@prom.engin.umich.edu> Date: Fri, 25 Aug 1995 08:23:35 PDT Sender: Ron Frederick <frederic@parc.xerox.com> From: Ron Frederick <frederic@parc.xerox.com> Message-Id: <95Aug25.082347pdt.16136@ecco.parc.xerox.com> >>> We've been trying to run nv. We work with a Sparcstation 20 running Solaris >>> with SunVideo 1.0 capture board and camera. >>> >>> When we start nv it does not recognize this video board because it keeps >>> sending our screen image instead of the image captured by the camera when >>> we choose the "start sending" button. > > You're right, the problem is with the grabber controlls. Only the option > "X11 Screen Grab" is enable. Do you know what can i do for enable the > option "Sun Video Pix" ? > The SunVideo card is _not_ the same as the Sun VideoPix card. It sounds to me like you are trying to use a SunOS 4.x version of nv, which doesn't know about the SunVideo card. You need to get the SunOS 5.x version, as the SunVideo only works on SunOS 5.3 (Solaris 2.3) or later. I recently built a new version of the SunOS 5.x nv, to fix some problems people were having on Solaris 2.4. I haven't had a chance to move it to the standard directory yet, but you can pick it up from: ftp://ftp.parc.xerox.com/transient/frederick/nv-3.3beta-sunos5 -- Ron Frederick frederick@parc.xerox.com From list-mgr@ISI.EDU Fri Aug 25 08:50:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16177>; Fri, 25 Aug 1995 08:52:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16147>; Fri, 25 Aug 1995 08:50:50 -0700 Received: from astor.urv.es by venera.isi.edu (5.65c/5.61+local-22) id <AA16127>; Fri, 25 Aug 1995 08:50:26 -0700 Message-Id: <199508251550.AA16127@venera.isi.edu> Received: by astor.urv.es (1.37.109.4/16.2) id AA19037; Fri, 25 Aug 95 17:12:03 +0200 From: Luis Anaya <lat@astor.urv.es> Subject: Looking for mbone app fro AIX To: mbone Date: Fri, 25 Aug 95 17:12:02 METDST Mailer: Elm [revision: 70.85] Hi Mboner's: Could someone say me where can i find the binary programs (nv, wb, vat and so on) for a AIX 3.2.5 machine? Have Fun, Luis Anaya lat@si.urv.es From list-mgr@ISI.EDU Fri Aug 25 08:35:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19482>; Fri, 25 Aug 1995 10:40:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19381>; Fri, 25 Aug 1995 10:35:49 -0700 Received: from sundance.itd.nrl.navy.mil by venera.isi.edu (5.65c/5.61+local-22) id <AA19372>; Fri, 25 Aug 1995 10:35:42 -0700 Subject: MBONE apps for Macs with Open Transport To: mbone Date: Fri, 25 Aug 1995 13:35:56 -0500 (EST) From: Dan McDonald <danmcd@cs.nrl.navy.mil> X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 367 Message-Id: <9508251835.aa08794@cs.nrl.navy.mil> I'm having little success getting this question answered on comp.sys.mac.comm, so I figured I'd approach the problem from the MBONE side of things. Now that Open Transport (and its improved IP stack) is available for Macintosh, is anyone out there working on MBONE tools (sd, vat, etc.) for the Macintosh? Thanks, Dan McD. (wearing his "PowerMac 9500 owner" cap) From list-mgr@ISI.EDU Fri Aug 25 07:11:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28455>; Fri, 25 Aug 1995 14:12:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28425>; Fri, 25 Aug 1995 14:11:47 -0700 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA28418>; Fri, 25 Aug 1995 14:11:45 -0700 Received: from icsib67.ICSI.Berkeley.EDU (whetten@icsib67.ICSI.Berkeley.EDU [128.32.201.167]) by icsia.ICSI.Berkeley.EDU (8.6.12/HUB+V8$Revision: 1.23 $) with ESMTP id OAA29344; Fri, 25 Aug 1995 14:11:31 -0700 Received: (whetten@localhost) by icsib67.ICSI.Berkeley.EDU (8.6.12/1.8) id OAA05248; Fri, 25 Aug 1995 14:11:28 -0700 Date: Fri, 25 Aug 1995 14:11:27 -0700 (PDT) From: Brian Whetten <whetten@ICSI.Berkeley.EDU> To: Michael Benson <mbenson@davinci.gmu.edu> Cc: van@ee.lbl.gov, mbone Subject: Re: multicast traffic In-Reply-To: <199508250530.BAA02035@davinci.gmu.edu> Message-Id: <Pine.SUN.3.91.950825141051.5238A-100000@icsib67> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII For America. We will limit our traffic to the U.S., so the other countries should be minimally affected. Brian On Fri, 25 Aug 1995, Michael Benson wrote: > One question. Very early in the morning for which part of the world? > > Michael > > > > > > We would like to run a series of tests in the near future, examining > > the performance of reliable multicast traffic over the mbone. We are > > looking forwards to the day in the hopfully not too distant future where > > reliable information distribution can be supported through the mbone > > rather than through lots of TCP connections. To this extent, we > > would like to study the effects that your congestion control mechanisms > > have on traffic in the mbone. Do you have some suggestions as to how we > > can do this and minimize the negative effects on mbone traffic? We > > will attempt to perform these tests very early in the morning, when > > we see that there are few other sessions running here. We will attempt > > to limit the traffic to 128 Kbps, although we would like to experiment > > briefly with higher rates if we can find a time when this is not disruptive. > > > > Our traffic is flow-controlled using mechanisms similar to TCP. We also > > have rate controls, but these are for the effective throughput, not for > > the instantaneous bit rate. > > > > Thanks! > > Brian > > > > > -- > Michael Benson > Computer science graduate student at George Mason University > WWW: http://cne.gmu.edu/~mbenson > Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson > From list-mgr@ISI.EDU Sun Aug 27 07:34:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26036>; Sun, 27 Aug 1995 14:36:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26025>; Sun, 27 Aug 1995 14:35:46 -0700 Received: from cs.nps.navy.mil by venera.isi.edu (5.65c/5.61+local-22) id <AA26018>; Sun, 27 Aug 1995 14:35:44 -0700 Received: by cs.nps.navy.mil (4.1/SMI-4.1) id AA08093; Sun, 27 Aug 95 14:34:35 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9508272134.AA08093@cs.nps.navy.mil> Subject: Re: Content Development for Multicasts To: rswenson@igc.apc.org Date: Sun, 27 Aug 1995 14:34:24 -0700 (PDT) Cc: mbone (Multicast Backbone mail list), rem-conf@es.net (Remote Conferencing mail list), i3la_netdesign@mbari.org (I3LA Network Design Team) In-Reply-To: <199508272003.NAA10149@igc3.igc.apc.org> from "Ron Swenson" at Aug 22, 95 09:28:28 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 5405 You asked what efforts were underway for providing new content on the MBone. Our intention is to provide multicast capability to regional K-12 schools when working native multicast is supported and MBone tools have been ported to Macintosh and Windows. The schools we have connected are using 128 Kbps Frame Relay, but both lines and CSU/DSU hardware can scale to T1. Thus we expect a variety of educational content to eventually be ported to MBone. Technical considerations will include training and safeguards to prevent unintended global bandwidth disruptions. We hope to enable teachers and students to use these tools, but ordinarily just within our region (Monterey and Santa Cruz counties). Details on both our regional collaboration and school internetworking follow. Networked Ocean Science Research and Education, Monterey Bay California Don Brutzman, Ph.D. Code UW/Br, Naval Postgraduate School Monterey, California 93943 USA 408.656.2149 voice, 408.656.3679 fax brutzman@nps.navy.mil http://inet.nttam.com/HMP/PAPER/039/ INET 95 page with user comments form ftp://taurus.cs.nps.navy.mil/pub/i3la/i3laisoc.html Hypertext ftp://taurus.cs.nps.navy.mil/pub/i3la/i3laisoc.txt Text ftp://taurus.cs.nps.navy.mil/pub/i3la/i3laisoc.ps Postscript (4.5 M) ftp://taurus.cs.nps.navy.mil/pub/i3la/i3laisoc.au Audio abstract (752 K) Abstract. The Monterey BayNet regional network is connecting students, educators, researchers, institutions and individuals around a common theme of environmental and ocean science. A variety of exciting volunteer efforts are building networked information links that can effectively and compatibly operate at low and high speeds. Connectivity, content, access and applications are the four key areas of action. Throughout this large project we have learned that people issues are just as important as technical issues. Our efforts have developed a regional model which effectively supports education at all levels together with the conduct of active scientific research. This paper was presented at INET'95, the Internet Society's 1995 International Networking Conference in Honolulu, Hawaii, 27-30 June 1995. For more information, see: http://info.isoc.org/inet95.html ========== Internetworking: Planning and Implementing A Wide-Area Network (WAN) for K-12 Schools Randall J. Bigelow THESIS MASTER OF SCIENCE IN INFORMATION TECHNOLOGY MANAGEMENT NAVAL POSTGRADUATE SCHOOL September 1995 Available in hypertext, PostScript & text formats. http://www.stl.nps.navy.mil/~rjbigelo/thesis.html ABSTRACT. This thesis documents the planning, design and implementation of a regional wide-area network connecting K-12 schools, research institutions, libraries and institutions of higher education throughout the Monterey Bay area of California's central coast. The goal of the network is to enable students and educators to have access to the environmental information and resources available regionally via the Internet, at speeds which will encourage interaction and maintain interest. The wide-area network design process presents numerous human and technical challenges. These challenges are further amplified by the need to enable educators to design and implement school local area networks concurrent with the wide-area network solution. The processes used to resolve these myriad issues and the resulting solutions are of direct relevance to the K-12 community as well as network planners, administrators and funding partners. TABLE OF CONTENTS I. INTRODUCTION II. RELATED WORK III. PROBLEM STATEMENT IV. SOFTWARE APPLICATION SELECTION V. LOCAL AREA NETWORK (LAN) DESIGN VI. WIDE AREA NETWORK (WAN) DESIGN VII. IMPLEMENTATION RESULTS VIII. APPLICABILITY TO DEPARTMENT OF THE NAVY (DoN) SHORE COMMANDS IX. CONCLUSIONS APPENDIX A. MACINTOSH SOFTWARE DOWNLOAD SITES APPENDIX B. WINDOWS SOFTWARE DOWNLOAD SITES APPENDIX C. EIA/TIA-568B WIRING SCHEME IN A 10BASE-T PLUG APPENDIX D. EXAMPLE LAN DESIGNS APPENDIX E. MONTEREY BAYNET EQUIPMENT RECOMMENDATIONS APPENDIX F. REGISTERED JACK NUMBER 48 (RJ-48) PINOUT AND WIRING BETWEEN NIU AND CSU APPENDIX G. CHANNEL SERVICE UNIT/DIGITAL SERVICE UNIT (CSU/DSU) CONFIGURATION APPENDIX H. CISCO 2514 ROUTER CONFIGURATION APPENDIX I. MONTEREY BAYNET TOPOLOGY APPENDIX J. COMMITTED INFORMATION RATE (CIR) MATRIX APPENDIX K. OBTAINING AN IP NETWORK NUMBER APPENDIX L. MONTEREY BAYNET DOMAIN NAME SERVICE APPENDIX M. INSTRUCTIONS FOR THE US DOMAIN APPENDIX N. REGISTERING FOR AN AUTONOMOUS SYSTEM NUMBER APPENDIX O. MACTCP CONFIGURATION APPENDIX P. WINDOWS TRUMPET WINSOCK PACKET DRIVER CONFIGURATION APPENDIX Q. ACRONYMS LIST OF REFERENCES INITIAL DISTRIBUTION LIST Additional links: http://www.stl.nps.navy.mil/~rjbigelo/ all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA [Root 200] fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv_uvw.html From list-mgr@ISI.EDU Sun Aug 27 10:31:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29782>; Sun, 27 Aug 1995 17:35:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29724>; Sun, 27 Aug 1995 17:32:20 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA29717>; Sun, 27 Aug 1995 17:32:18 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with ESMTP id RAA05728; Sun, 27 Aug 1995 17:31:56 -0700 Message-Id: <199508280031.RAA05728@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: brutzman@cs.nps.navy.mil (Don Brutzman) Cc: rswenson@igc.apc.org, mbone (Multicast Backbone mail list), rem-conf@es.net (Remote Conferencing mail list), i3la_netdesign@mbari.org (I3LA Network Design Team) Subject: Re: Content Development for Multicasts In-Reply-To: Your message of "Sun, 27 Aug 1995 14:34:24 PDT." <9508272134.AA08093@cs.nps.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 27 Aug 1995 17:31:56 -0700 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> >>> Don Brutzman said: > You asked what efforts were underway for providing new content on the MBone. Why not give FreeBSD or Linux a chance ? One benefit that I can see right away is the pre-emptive multitask capability in FreeBSD and Linux. Amancio From list-mgr@ISI.EDU Sun Aug 27 17:50:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09677>; Mon, 28 Aug 1995 00:54:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09650>; Mon, 28 Aug 1995 00:53:26 -0700 Received: from netcom20.netcom.com by venera.isi.edu (5.65c/5.61+local-22) id <AA09643>; Mon, 28 Aug 1995 00:53:24 -0700 Received: by netcom20.netcom.com (8.6.12/Netcom) id AAA27240; Mon, 28 Aug 1995 00:50:59 -0700 From: sujo@netcom.com (Suresh K Jois) Message-Id: <199508280750.AAA27240@netcom20.netcom.com> Subject: Mbone app dev resources To: mbone, rem-conf@es.net Date: Mon, 28 Aug 1995 00:50:59 -0700 (PDT) Cc: sujo@netcom.com (Suresh K Jois) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1147 Hi, This is my first post to both mbone and rem-conf lists. Please excuse any transgressions. I'm planning on writing a set of mbone audio and video apps with special emphasis on multi-platform portability and close interface integration and some additional features over the existing ones. Given the fact that I'm completely MBONE unaware except for brief usage when I was at Sun and SGI (my current employer has no MBONE feed), what resources do I need to gather to do this, in terms of: - Network programming experience - Existing code base (is there any sort of library/API on top of which exising apps are built ?) - Ideal dev platform (Solaris/Windows NT - my preference/Linux ..) - Multicast capability addins for Windows NT/95 and Macintosh. I'm also looking for material on comparative analysis (from an engineering as well as commercial/business perspective) of MBONE vs. other technologies such as XING's proposed MPEG streamers, Cu-Seeme, RealAudio and Mulimedia IRC. Which of these will most likely be the future successful bearer of live multimedia content on the Internet. Much thanks for any input on this. - Suresh From list-mgr@ISI.EDU Tue Aug 29 02:50:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11095>; Mon, 28 Aug 1995 01:52:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11040>; Mon, 28 Aug 1995 01:51:18 -0700 Received: from sh.iij-mc.co.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA11033>; Mon, 28 Aug 1995 01:51:15 -0700 Received: from mcgw.iij-mc.co.jp (root@mcgw.iij-mc.co.jp [192.168.10.2]) by sh.iij-mc.co.jp (8.6.12+2.4W/3.3W9-SH) with ESMTP id RAA11339 for <mbone@isi.edu>; Mon, 28 Aug 1995 17:51:13 +0900 Received: from teapot.iij-mc.co.jp (teapot.iij-mc.co.jp [192.168.10.16]) by mcgw.iij-mc.co.jp (8.6.12+2.5Wb7/3.4W) with ESMTP id RAA14510; Mon, 28 Aug 1995 17:50:48 +0900 Received: from teapot (localhost [127.0.0.1]) by teapot.iij-mc.co.jp (8.6.12+2.4W/3.3W9-07/31/95) with ESMTP id RAA01492; Mon, 28 Aug 1995 17:52:06 +0900 Message-Id: <199508280852.RAA01492@teapot.iij-mc.co.jp> To: mbone Cc: mc-mbone@iij-mc.co.jp X-Mailer: Mew beta version 0.98 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Reply-To: mc-mbone@iij-mc.co.jp Subject: Tchaikovsky Competition Content-Type: Text/Plain; charset=us-ascii Date: Mon, 28 Aug 1995 17:50:50 +0900 From: YAMAMOTO Bunji <bunji@teapot.iij-mc.co.jp> We are planning to transmit below programs. See also http://www.iijnet.or.jp/CitySendai/tchaikovsky/. 1. Content: The final contest of International Tchaikovsky Competition for Youth Musicians 2. Session name: Tchaikovsky Competition from Sendai 3. Media: nv, vat 4. Bandwidth: 128kbps 5. Date: 1995/09/03 05:00-07:00 UTC (Cello Section contest) 04 09:30-11:30 UTC (Cello Section contest) 06 09:30-11:30 UTC (Violin Section contest) 07 09:30-11:30 UTC (Violin Section contest) 6. Initial TTL: 170 7. Contact to: IIJ Media Communications Inc., Mbone Team. 8. Mail address: mc-mbone@iij-mc.co.jp -- YAMAMOTO Bunji <bunji@iij-mc.co.jp> IIJ Media Communications Inc. From list-mgr@ISI.EDU Mon Aug 28 23:23:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29485>; Mon, 28 Aug 1995 12:28:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29439>; Mon, 28 Aug 1995 12:26:43 -0700 Received: from survis.surfnet.nl by venera.isi.edu (5.65c/5.61+local-22) id <AA29428>; Mon, 28 Aug 1995 12:26:39 -0700 Received: from ejpc4.kabbel.surfnet.nl by survis.surfnet.nl with SMTP (PP); Mon, 28 Aug 1995 21:26:32 +0200 Received: from ejpc4.kabbel.surfnet.nl by ejpc4.kabbel.surfnet.nl with smtp (Smail3.1.28.1 #8) id m0sn9m1-0002fqC; Mon, 28 Aug 95 21:23 MET DST To: mbone Subject: New list for Mbone matters in Europe From: Erik-Jan Bos <erik-jan.bos@surfnet.nl> Reply-To: Erik-Jan Bos <erik-jan.bos@surfnet.nl> Errors-To: Erik-Jan Bos <erik-jan.bos@surfnet.nl> X-Mailer: MH with Smail on Linux X-Organization: SURFnet bv, Utrecht, The Netherlands X-Phone-Number: +31 30 305305 X-Fax-Number: +31 30 305329 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <243.809637786.1@ejpc4.kabbel.surfnet.nl> Date: Mon, 28 Aug 1995 21:23:07 +0200 Message-Id: <244.809637787@ejpc4.kabbel.surfnet.nl> Sender: Erik-Jan.Bos@ejpc4.kabbel.surfnet.nl Mbone-ers, this is an announcement, by popular request, of a new e-mail distribution list regarding Mbone in Europe. The name of the list is "mbone-eu-op@ripe.net". With the creation of this new list, the "mbone-eu@sics.se" list will remain to exist. This list is run by Hans Eriksson of SICS. This list is directed towards general European Mbone questions and runs as the European fan-out list for the global list, aka mbone@isi.edu. Please find below the Charter for this list. In this charter there is detailed info on how to get on the list and how to get off. As soon as a number of people have subscribed to the list I will once again send the charter to the new list in order to start it off. Questions are welcome. --- Start of "Charter" Charter for the E-mail list "mbone-eu-op@ripe.net" ================================================== Author: Erik-Jan Bos <erik-jan.bos@surfnet.nl> Date: 27 August 1995 Version: 1.1 The Mbone-EU-Op list is created and maintained as a coordinating platform for Network Operators that run a multicast capable infrastructure, connected to the global Mbone. The intention of having and using the newly created "-op" list is that the mbone@sics.se became to noisy for doing real operations on the European part of the Mbone. The new list is intended for (but not limited to issues such as): * Managing tunnels between providers, wrt topology, metrics and thresholds. * Managing tunnels across the Atlantic Lake. And questions like: * I am Provider X and I want a tunnel to Mbone, where to connect? * I am Provier Y and I am already connected to Mbone but now I want a back-up tunnel, where to go and what metrics to use? * Is it correct that Provider Z is temporary disconnected from Mbone? Also, discussions on how the management should be done in the longer term: * Announcement on changes of the topology, such as: then tunnel between X and Y has/will go down, expected to be up at ... The tunnel between X and Y is removed then server X is down/going down ... expected to be up where switching to server ... Our machine X is running OS Borix 4711.42.17 and is a SS-37 machine... and so on... everything that might be of intresse * annoucments can be done for software updates etc. The full address of the list is "mbone-eu-op@ripe.net" and this list is maintained, courtesy of the RIPE NCC folks, on their Majordomo machine. Any requests for (un)subscription should be directed at "mbone-eu-op-request@ripe.net" or "majordomo@ripe.net". Never send such e-mail to the list itself! The list is archived. The list archives can be retreived from the URL: ftp://ftp.ripe.net/ripe/archives/mbone-eu-op/* --- End of "Charter" __ Erik-Jan. From list-mgr@ISI.EDU Tue Aug 29 14:41:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03714>; Mon, 28 Aug 1995 13:44:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03627>; Mon, 28 Aug 1995 13:43:12 -0700 Received: from glory.kaist.ac.kr by venera.isi.edu (5.65c/5.61+local-22) id <AA03608>; Mon, 28 Aug 1995 13:43:07 -0700 Received: (from joyoon@localhost) by glory.kaist.ac.kr (8.6.9H1/8.6.9) id FAA03956; Tue, 29 Aug 1995 05:41:42 +0900 Date: Tue, 29 Aug 1995 05:41:42 +0900 From: Joong-One Yoon <joyoon@glory.kaist.ac.kr> Message-Id: <199508282041.FAA03956@glory.kaist.ac.kr> To: mbone Subject: unsubscribe unsubscribe From list-mgr@ISI.EDU Mon Aug 28 10:48:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07861>; Mon, 28 Aug 1995 15:03:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07818>; Mon, 28 Aug 1995 15:02:08 -0700 Received: from mailhost1.primenet.com by venera.isi.edu (5.65c/5.61+local-22) id <AA07811>; Mon, 28 Aug 1995 15:02:02 -0700 Received: from mailhost.primenet.com (root@mailhost.primenet.com [198.68.32.50]) by mailhost1.primenet.com (8.6.12/8.6.12) with ESMTP id PAA04799 for <mbone@ISI.EDU>; Mon, 28 Aug 1995 15:03:05 GMT Received: from ip130.yum.primenet.com (ip130.yum.primenet.com [198.68.44.130]) by mailhost.primenet.com (8.6.12/8.6.12) with SMTP id PAA16233 for <mbone@ISI.EDU>; Mon, 28 Aug 1995 15:01:46 -0700 Message-Id: <199508282201.PAA16233@mailhost.primenet.com> X-Sender: alewis@mailhost.primenet.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 14:48:59 -0400 To: mbone From: alewis <alewis@primenet.com> Subject: unsubscribe From list-mgr@ISI.EDU Wed Aug 30 05:32:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03546>; Tue, 29 Aug 1995 04:31:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03526>; Tue, 29 Aug 1995 04:30:24 -0700 Received: from hikari.mech.titech.ac.jp ([131.112.248.31]) by venera.isi.edu (5.65c/5.61+local-22) id <AA03519>; Tue, 29 Aug 1995 04:30:20 -0700 Received: from shimo.mech.titech.ac.jp by hikari.mech.titech.ac.jp (8.6.10+2.4W/TM2.1-H1.0) id UAA28285; Tue, 29 Aug 1995 20:34:36 +0900 Date: Tue, 29 Aug 1995 20:32:26 +0900 Message-Id: <199508291132.UAA14509@shimo.mech.titech.ac.jp> Received: by shimo.mech.titech.ac.jp (8.6.10+2.4W/TM2.1-H2.1) id UAA14509; Tue, 29 Aug 1995 20:32:26 +0900 To: mbone Cc: lijin@mech.titech.ac.jp Subject: unsubscribe From: lijin@mech.titech.ac.jp (Li Jin) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailer: mnews [version 1.18PL3] 1994-08/01(Mon) unsubscribe From list-mgr@ISI.EDU Tue Aug 29 03:35:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14971>; Tue, 29 Aug 1995 10:40:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14958>; Tue, 29 Aug 1995 10:40:15 -0700 Received: from ormail.intel.com by venera.isi.edu (5.65c/5.61+local-22) id <AA14951>; Tue, 29 Aug 1995 10:40:12 -0700 Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0snUdv-000UflC; Tue, 29 Aug 95 10:40 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0snUdu-000twvC; Tue, 29 Aug 95 10:40 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Tue, 29 Aug 95 10:40:10 PDT Date: Tue, 29 Aug 95 10:35:00 PDT From: Mojtaba Mirashrafi <Mojtaba_Mirashrafi@ccm.jf.intel.com> Message-Id: <Tue, 29 Aug 95 10:40:01 PDT_2@ccm.hf.intel.com> To: mbone Subject: Request for a router to connect to. We would like to perform some Audio/video experiments on the MBONE. Which of the mrouted machines should we tunnel to? Who do we contact for scheduling some time for our multicasts? We are located in Portland, Oregon. Thanks very much, Mojy Mirashrafi 503-264-8690 Mojtaba_Mirashrafi@jf.ccm.intel.com From list-mgr@ISI.EDU Wed Aug 30 02:56:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26569>; Tue, 29 Aug 1995 14:55:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26551>; Tue, 29 Aug 1995 14:54:32 -0700 Received: from Protea.hitech.net.au ([198.142.57.2]) by venera.isi.edu (5.65c/5.61+local-22) id <AA26544>; Tue, 29 Aug 1995 14:54:28 -0700 Received: from [198.142.57.6] (Modem3.hitech.net.au [198.142.57.6]) by Protea.hitech.net.au (8.6.11/8.6.9) with SMTP id HAA12934 for <mbone@ISI.EDU>; Wed, 30 Aug 1995 07:52:12 +1000 Message-Id: <199508292152.HAA12934@Protea.hitech.net.au> To: "mbone@ISI.EDU" <mbone> Subject: unsubscribe Date: Wed, 30 Aug 95 07:56:02 -0500 From: Geoffrey Sparks <sparks@hitech.net.au> X-Mailer: E-Mail Connection v2.5.03 -- [ From: Geoffrey Sparks * EMC.Ver #2.5.02 ] -- unsubscribe From list-mgr@ISI.EDU Tue Aug 29 18:53:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08451>; Tue, 29 Aug 1995 19:54:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08407>; Tue, 29 Aug 1995 19:52:04 -0700 Received: from FAUST.BBN.SAN-DIEGO.CA.US ([199.56.164.6]) by venera.isi.edu (5.65c/5.61+local-22) id <AA08400>; Tue, 29 Aug 1995 19:52:01 -0700 Received: (mfausett@localhost) by FAUST.BBN.SAN-DIEGO.CA.US (8.6.10/8.6.4) id WAA17617 for mbone@isi.edu; Tue, 29 Aug 1995 22:53:48 -0400 Date: Tue, 29 Aug 1995 22:53:48 -0400 From: "Mark L. Fausett" <mfausett@BBN.COM> Message-Id: <199508300253.WAA17617@FAUST.BBN.SAN-DIEGO.CA.US> To: mbone Subject: HP VAT Audio sampling rate problems I've got a working VAT setup on an HP9000/755 under HP-UX 9.05. Under 9.03 however, the sampling rate seems mismatched -- eg incoming audio from a (for example) sun is played as a series of chirps, while audio sent from the HP plays as a low-pitched rumble on other machines. Is this a known problem; is there a known fix? Thanks, Mark Fausett mfausett@bbn.com From list-mgr@ISI.EDU Tue Aug 29 19:23:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09221>; Tue, 29 Aug 1995 20:24:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09202>; Tue, 29 Aug 1995 20:23:05 -0700 Received: from oit.gatech.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA09194>; Tue, 29 Aug 1995 20:23:04 -0700 Received: (from ccoprmm@localhost) by oit.gatech.edu (8.6.12/8.6.12) id XAA15389 for mbone@isi.edu; Tue, 29 Aug 1995 23:23:03 -0400 From: Michael.Mealling@oit.gatech.edu (Michael Mealling) Message-Id: <199508300323.XAA15389@oit.gatech.edu> Subject: Two SunVideo boards and vic: How? To: mbone Date: Tue, 29 Aug 1995 23:23:02 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 644 We are setting up a Sparc 20 with two SunVideo boards to act as a general purpose MBONE source for campus (satellite feeds and such). Has anyone had any experience in getting vic to look at specific devices as in /dev/rtvc1 instead of /dev/rtvc0? We also need to know if its possible to start and run vic without having a monitor since this machine will just sit in a rack and should not need a monitor. Thanks! -NN -- ------------------------------------------------------------------------------ Life is a game. Someone wins and someone loses. Get used to it. <BR> <HR><A HREF="http://www.gatech.edu/michael.html">Michael Mealling</A> From list-mgr@ISI.EDU Tue Aug 29 16:09:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13546>; Tue, 29 Aug 1995 23:11:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13533>; Tue, 29 Aug 1995 23:09:45 -0700 Received: from starfleet (starfleet.internex.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA13526>; Tue, 29 Aug 1995 23:09:44 -0700 Received: from farragut.InterNex.Net by starfleet (SMI-8.6.9/SMI-SVR4) id XAA12352; Tue, 29 Aug 1995 23:09:41 -0700 Received: by farragut.InterNex.Net (5.x/SMI-SVR4) id AA00464; Tue, 29 Aug 1995 23:09:34 -0700 From: "Marcos Della" <mdella@farragut.InterNex.Net> Message-Id: <9508292309.ZM462@farragut> Date: Tue, 29 Aug 1995 23:09:33 -0700 X-Mailer: Z-Mail (3.2.1 10apr95) To: mbone Subject: MBONE tunnel request Cc: bswenson@starfleet.InterNex.Net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sorry for the traffic...I'm not on this mailing list. I had a tunnel established for mbone traffic and another employee removed the machine before I realized that the tunnel was gone. Woops... Is there someone that is a short "hop" away from mae-west (we are directly peered there) that can create a tunnel for us? Specifically we are looking for a tunnel to 199.2.14.45 if possible. We are trying to set up a session for the "burning man" event and are hauling out a bunch of BRI connections to the desert for this event. Any help would be appreciated!!! Marcos (mdella@internex.net or bswenson@internex.net) -- ''' (o o) --------------------------oOO--(_)--OOo-------------------------- Marcos R. Della Email: mdella@InterNex.Net Director, Network Engineering InterNex Information Services Phone: 408/496-5466 http://www.internex.net/~mdella From list-mgr@ISI.EDU Tue Aug 29 16:10:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13828>; Tue, 29 Aug 1995 23:22:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13572>; Tue, 29 Aug 1995 23:12:10 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-22) id <AA13565>; Tue, 29 Aug 1995 23:12:09 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA20477; Tue, 29 Aug 95 23:10:25 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9508300610.AA20477@taurus.cs.nps.navy.mil> Subject: unplugged.html To: graphicsnet@siggraph.org (GraphicsNet mail list), coco@siggraph.org (Coco Conn), zane@isaac.exploratorium.edu (zane vella), pax@ankh.metrolink.com (Garry Paxinos), web.s95@flsig.org (SIGGRAPH OnLine), earle@isolar.tujunga.ca.us (Greg Earle) Date: Tue, 29 Aug 1995 23:10:24 -0700 (PDT) Cc: mbone (Multicast Backbone mail list), rem-conf@es.net (Remote Conferencing mail list), i3la_edu@mbari.org (I3LA Education Team), evans@skaface.arc.nasa.gov (Dan Evans), JoSanders@wposmtp.nps.navy.mil (John Sanders), CWetteland@mntry.nps.navy.mil (Clyde Wetteland), mpesce@netcom.com (Mark D. Pesce) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 16512 Here is a detailed recap of our recent SIGGRAPH multicast. Comments and further lessons learned are welcome. Some pretty nice images and a quicktime video are on the home page. [Sorry but schedule and a diskspace bottleneck have delayed adding further video clips and audio from VRML and other taped sessions.] X-Within-Url: http://www.stl.nps.navy.mil/~brutzman/unplugged.html "MBONE UNPLUGGED" - or - how we created a wireless mobile television studio and multicast SIGGRAPH 95 world-wide over the Internet. _________________________________________________________________ WHAT, WHEN and WHERE was SIGGRAPH? Cool! Catalytic! Connected! The annual conference of the Association for Computing Machinery (ACM) Special Interest Group on Graphics (SIGGRAPH) includes over 30,000 computer experts, explorers, and enthusiasts from all over the world. All focused on the adventurous edge of cyberspace, interactive digital techniques, new entertainment media, networked communities, and the science that creates tomorrow's technologies. August 6-11 1995, Los Angeles Convention Center, Los Angeles California USA. OUR OBJECTIVES * Create a mobile studio for a weeklong KSIG-TV. SIGGRAPH exhibitors were our programs. * Provide content and lab facilities for local educators to learn about the Internet. Here is a video clip from local television station KCBA. They interviewed Tracey Emswiler about our efforts. The 50-second clip is a 19.2 MB QuickTime video. Tracey Emswiler KCBA video _________________________________________________________________ Enter the Cart... Here is the "MBone Unplugged" cart Jon Bigelow put together: MBone Cart The cart was WAY COOL! It included the following gear: * Silicon Graphics Inc. (SGI) entry-level Indy workstation * AirLAN wireless bridges (2 Mbps bandwidth, spread spectrum, ~ 1 GHz frequency band, no FCC license required) * Uninterruptible Power Supply (UPS), good for about 15 minutes * Standard VHS VCR and television monitor * Two VHS videocameras with tape capability and single mobile tripod * Wireless microphones, lapel and hand-held * Switch box to select camera/audio source * Video projector to put live imagery on any nearby wall * LOTS of wires, cables and adapters, all labeled at each end * Two cellular telephones for coordination and mobility * Broomstick to lift wireless antenna above cart * Various NPS master's students and passersby to push the darn thing This is the workstation of the future. It has everything: computing, graphics, live 2-way audio/video, mobility and global scope. We all want one now! Undoubtedly someone can make a much more compact version. The usefulness of this approach is perhaps the most important lesson we've learned. _________________________________________________________________ NETWORK CONSIDERATIONS GraphicsNet GraphicsNet was SIGGRAPH 95's high-performance, state-of-the-art communications infrastructure. It included ATM, HIPPI and Ethernet networks. We are particularly grateful for the help and expertise of the GraphicsNet team. Multicast Backbone (MBone) Here are links to an article on the Multicast Backbone (MBone) and an local MBone home page pointing to other free software and information resources. The following are a few of the MBone issues we grappled with. More will be added. We announced our intention to multicast during the week of 6-11 August 95 to the remote conferencing list (rem-conf@es.net). and also to the MBone Session Agenda scheduling home page at http://www.cilea.it/MBone/agenda.html. There were no objections to our plans. We intentionally stressed the MBone as much as possible, remaining within the community guidelines regarding permissible use. Our motivation was that the most interesting problems and fixes on the MBone often occur when someone is "pushing the envelope" of current capabilities. Originally we expected to share global MBone bandwidth with the NASA Select channel. Since the space shuttle mission was cancelled, we were able to use 256 Kbps video bandwidth as opposed to 128 Kbps video (the ordinary default). It was very helpful not to have to share bandwidth. Some coordination on site was neccessary with the GraphicsOnline team, but few difficulties occurred. We were glad to see that the MBone held up well. There were occasional problems with users elsewhere inadvertantly sending high-bandwidth video, but these were quickly detected and corrected, either by Van Jacobson (University of California, Lawrence Berkeley Laboratory) or the offending users themselves. This is a long-standing training problem. It has been alleviated somewhat by making transmission a little harder fro for naive users to turn on. Nevertheless we think it is a people problem which needs a people solution (e.g. simple effective training). mrouted difficulties and recovery In addition to the cart, we brought an old Sun 3/110 workstation to serve as the multicast router. Unfortunately there is a tiny switch on the back which we inadvertantly moved from "NORMAL" to "DIAGNOSTIC." This meant it would not boot and was effectively inoperable. If we had a flashlight, we might have figured out what we were doing wrong. As it turned out, Sun Microsystems loaned us a Sparc 20 workstation as a replacement mrouter. Greg Earle of NASA JPL reconfigured the kernel and saved us. Dan Evans of NASA Ames provided the encapsulated multicast tunnel from Moffett Field. On several occasions our mrouter stopped sending multicast due to bugs in the vic video tool crashing on the Sun mrouter. At the same time the machine appeared to be operational based on normal routing and continuous ping checks. This condition was hard to diagnose given our minimal use of multicast diagnostic tools. Better tool usability is needed. We are also considering putting the multicast router and tunnel endpoint right on the mobile machine. As long as it has enough cycles to operate, complete system state is right there for the user to evaluate. Our distance from the mrouter made it difficult to determine if our mrouter or an mrouter upstream from the convention center was the cause of MBone connectivity losses. As it turned out, all of our difficulties were tracable to our GraphicsNet mrouter. The production environment at SIGGRAPH was too noisy and dynamic to permit monitoring e-mail. We were able to get effective out-of-band communications from remote viewers by modifying the name field in the video-audio tool (vat). We used the net video (nv) software to multicast video. Our motivation for using nv was to permit another workstation to act as a reflector to CU-SeeMe. Unfortunately our CU-SeeMe expert never showed, and we didn't have time to learn it ourselves in mid-conference. In general, vic in .H261 mode is superior. H261 (part of the MPEG standards suite) is an asymmetric encoding, meaning that more computational work is performed by sender while higher framerate and lower effective bandwidth is enjoyed by the receivers. Previous tests showed that our Indy was able to handle this load effectively. We used vat audio software. Standard settings were employed (encoding PCM2). Modifications included setting Lecture mode for longer playouts, "Mike mutes Net" to prevent offsite interuptions, and use of the user's Name field to list each event by name as they occurred. It is of course very important to make sure someone is keeping track of the videotape being recorded so that new ones are started as soon as they are needed. Tracey Emswiler was in charge of event scheduling and coordinating the transitions to the next venue. It was a big help having a single person keep everything on track. Wireless considerations The AirLAN bridges are very slick. Called "smart bridges," they operate by listening for IP numbers on either side. Once the bridges know that a host is on one side or the other, any packets appearing on the opposite side are automatically sent across the bridge. Thus each side looks like a singe local-area network (LAN) without manual route reconfigurations. We found them to be reliable in a mobile environment, and the frequency agility of a spread spectrum approach made the link very robust despite lots of "trash RF" in this very crowded exhibition hall environment. _________________________________________________________________ EDUCATOR TRAINING IN MONTEREY [IMAGE] Teacher training is an ongoing project for us. K-12 collaboration has been particularly productive in helping us learn which technologies work for people and which don't. Click on the map above to learn more about our regional projects. These are the home pages we created for Monterey Bay use during this event. * Flyer: http://www.stl.nps.navy.mil/~tlemswil/flyer.html * What's happening: http://www.stl.nps.navy.mil/~tlemswil/ * Schedule: http://www.stl.nps.navy.mil/~tlemswil/schedule.html * Top 14 List - For Researchers, Educators and Kids: http://www.stl.nps.navy.mil/~tlemswil/ResearchersTop_14.html * Top 10 List - For Water Discovery Institute Teachers: http://www.stl.nps.navy.mil/~tlemswil/WaterDiscoveryTop_10.html More about our efforts in networked K-12 education: * Networked Ocean Science Research and Education, Monterey Bay California, available at http://inet.nttam.com/HMP/PAPER/039/ * Learning About Monterey Bay (LAMBAY) http://lambay.cse.ucsc.edu/mb * Monterey Bay Regional Education Futures (MBReEF) Consortium http://www.ucsc.edu/mbay-region * Initiative for Information Infrastructure & Linkage Applications (I3LA) ftp://taurus.cs.nps.navy.mil/pub/i3la/i3la.html * Real-time Environmental Information Network & Analysis System (REINAS) http://csl.cse.ucsc.edu/reinas.html _________________________________________________________________ FUTURE WORK We are still thinking over lessons learned and future work. Many of these issues will likely become theses for masters students in the NPS Information Infrastructure Research Group (IIRG). Queries are welcome. * digitally archive recorded videotapes for MBone-compatible access on demand * record a full week of K-12 Internet sessions at INET 96, Montreal Canada * do more cool educational stuff for free * learn new answers and new questions * cost-benefit comparisons between building custom videoteleconferencing (VTC) classrooms and mobile networked VTC carts * do the same thing at much higher bandwidth over ATM * show that Macs and PCs can be used for this, once they get multicast support built into the operating system kernel * distribute the software tools and technical exertise to regional K-12 schools when the technology is ready _________________________________________________________________ PEOPLE The "Unplugged" (unhinged?) Team in LA: MBone Unplugged Team * Don Brutzman (UW/Br) (brutzman@nps.navy.mil) AUV / IIRG / NPSNET research groups * Tracey Emswiler (ITM) (tlemswil@nps.navy.mil) Hamming "Learning to Learn" Multicast (graduates September 95) * Jon Bigelow (ITM) (rjbigelo@nps.navy.mil) Monterey BayNet (graduates August 95) * Beth Bacon (bbacon@attmail.com) Writer and communications consultant * Dan Bacon (CS) (bacon@cs.nps.navy.mil) Adding a physically based submarine to NPSNET (graduates September 95) and also in LA (but not pictured) * John Sanders (JoSanders@wposmtp.nps.navy.mil) NPS Public Affairs Officer (PAO) * LT Clyde Wetteland USN (CWetteland@mntry.nps.navy.mil) NPS Assistant Public Affairs Officer (PAO) Back in Monterey helping the teachers and students and researchers: * Dennis Trepanier (ITM) (dmtrepan@nps.navy.mil) Regional K-12 network management (graduates September 95) * Matthew Koebbe (Dr. Longhair) (phaedrus@nps.navy.mil) NPS Visualization Lab * CDR Bob Ellis (bellis@cs.nps.navy.mil) Computer Science Curriculum Officer * Charles Peyton Taylor (ctaylor@nps.navy.mil) Root 262 Macintosh Lab Manager * Katie Muir (kmuir@mbayaq.org) Monterey Bay Aquarium (MBA) Water Discovery Institute * Ray McClain (kmuir@mbayaq.org) Moss Landing Marine Laboratory - Researchers' Invitational * Jeff Forte (CS/ITM)(jeforte@nps.navy.mil) ATM, dual degree CS/ITM (September 96) * Michael Tiddy (ITM) (metiddy@nps.navy.mil) (September 96) _________________________________________________________________ THANKS * ACM SIGGRAPH * Coco Conn and Zane Vella, Interactive Communities and Digital Circus * GraphicsNet team including chair Marke Clinger (Fore Systems), Peter Haddad (Hewlett-Packard), Jeannette Dravk and Craig Schell and Amy Wong (Fore Systems) and the rest of the gang * Garry Paxinos (MetroLink Inc.) and the SIGGRAPH OnLine team * Virtual Reality Modeling Language (VRML) group * Diane Sena, Steve Webster, Jeff Bryant and Katie Muir (Monterey Bay Aquarium - MBA) * Peter Brewer and Bruce Gritton (Monterey Bay Aquarium Research Institute - MBARI) * John Morales, Frank Cardoza, Harry Thomas (NPS Electronic Media Division) and Tracy Hammond (NPS Registrar) * Mike Zyda, Dave Pratt, Mike Macedonia and the NPSNET group * Dan Evans and Greg Earle (NASA Ames and JPL) * Van Jacobson and the MBone list participants * Theresa-Marie Rhyne (Lockheed Martin) and the "Future Technologies" panel * Ray McClain (MLML) and Bob Ellis (NPS) * Terry Williams, Milena Cochran, Stefan Hudson and Gary Porter (NPS Systems Technology Lab) * Mike McCann and Matthew Koebbe (NPS Visualization Lab) * Mike Newman (Newman and Associates) * Silicon Graphics Inc. (SGI) and Sun Microsystems * I3LA Monterey Bay Educators * Hotel Nikko, Beverly Hills * and everyone else who helped that we've inadvertantly forgotten. T-SHIRTS AND BUTTONS These are the most competitive measure of SIGGRAPH value. We got t-shirts, buttons and a few paper sacks stuffed with unmarked bills from the following folks: * SIGGRAPH 95, SIGGRAPH 96 and ACM * GraphicsNet * Silicon Graphics Inc. and the OpenInventor group * Sun Microsystems * Journal of Graphics Tools * Mark Pesce, author of the new book "VRML: Entering CyberSpace" from New Riders Press * Hard Rock Cafe * Ed Debevic's Good Eats (including my favorite, "I'd Rather Be Bowling") Who OWES us shirts (we have long memories): * Parallax Graphics _________________________________________________________________ Still to write about: MBone monitoring tools, lessons learned from Monterey side, ATM demo with Parallax, individual sessions we recorded to tape digitized and placed online, etc. _________________________________________________________________ This is a first draft, more will be added. AUTHORS: DON BRUTZMAN AND TRACEY EMSWILER "MBone Unplugged" http://www.stl.nps.navy.mil/~brutzman/unplugged.html -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA [Root 200] fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv_uvw.html From list-mgr@ISI.EDU Wed Aug 30 10:53:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02257>; Wed, 30 Aug 1995 11:54:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02201>; Wed, 30 Aug 1995 11:53:32 -0700 Received: from wizard.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA02192>; Wed, 30 Aug 1995 11:53:30 -0700 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA27823; Wed, 30 Aug 95 14:53:28 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9508301853.AA27823@wizard.gsfc.nasa.gov> Subject: 25165 entries in DVMRP routing tables To: mbone Date: Wed, 30 Aug 1995 14:53:27 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 204 I have 25165 entries in my DVMRP routing tables. I would suspect someone is importing the full unicast routing table once again. This is bringing my and other's mrouted machines to a crawl. -Bill From list-mgr@ISI.EDU Wed Aug 30 02:59:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12395>; Wed, 30 Aug 1995 16:00:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12375>; Wed, 30 Aug 1995 16:00:09 -0700 Received: from mailrelay.pixi.com (sirius.pixi.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA12368>; Wed, 30 Aug 1995 16:00:07 -0700 Received: from likelike.pixi.com.pixi.com by mailrelay.pixi.com (8.6.10/SMI-4.1) id NAA27717; Wed, 30 Aug 1995 13:01:39 -1000 Received: by likelike.pixi.com.pixi.com (4.1/SMI-4.1) id AA01748; Wed, 30 Aug 95 12:59:32 HST Date: Wed, 30 Aug 1995 12:59:30 -1000 (HST) From: "Antonio Querubin Jr." <tony@pixi.com> To: mbone Subject: tunnel request Message-Id: <Pine.S40.3.91.950830125252.1742A-100000@likelike.pixi.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm looking for a temporary backup tunnel. Our tunnel to TLG/Sprint has been down for a while now and our backup had to cease operation. Our tunnel endpoint here would be 204.182.46.1. We have some multicast activity scheduled for the latter half of September and would like some connectivity re-established well ahead of that. Antonio Querubin tony@pixi.com / ah6bw@hawaii.ampr.org From list-mgr@ISI.EDU Wed Aug 30 13:35:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13641>; Wed, 30 Aug 1995 16:36:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13497>; Wed, 30 Aug 1995 16:35:40 -0700 Received: from sgi12.phlab.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA13489>; Wed, 30 Aug 1995 16:35:38 -0700 Received: (from ccshag@localhost) by sgi12.phlab.missouri.edu (8.6.12/8.6.12) id SAA09077; Wed, 30 Aug 1995 18:35:28 -0500 Date: Wed, 30 Aug 1995 18:35:28 -0500 (CDT) From: "Paul 'Shag' Walmsley" <ccshag@cclabs.missouri.edu> X-Sender: ccshag@sgi12.phlab.missouri.edu To: "Antonio Querubin Jr." <tony@pixi.com> Cc: mbone Subject: Re: tunnel request In-Reply-To: <Pine.S40.3.91.950830125252.1742A-100000@likelike.pixi.com> Message-Id: <Pine.SGI.3.91.950830183502.9068A-100000@sgi12.phlab.missouri.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 30 Aug 1995, Antonio Querubin Jr. wrote: > I'm looking for a temporary backup tunnel. Our tunnel to TLG/Sprint > has been down for a while now and our backup had to cease operation. Our > tunnel endpoint here would be 204.182.46.1. We have some multicast > activity scheduled for the latter half of September and would like some > connectivity re-established well ahead of that. If your tunnel is managed by Sprintlink, try sending mail to mbone-admin@sprint.net telling him what you want. - Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu> "Praise and blame alike mean nothing." -- Virginia Woolf From list-mgr@ISI.EDU Wed Aug 30 08:03:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21161>; Wed, 30 Aug 1995 21:12:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21150>; Wed, 30 Aug 1995 21:11:57 -0700 Received: from netcomsv.netcom.com (uucp13.netcom.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA21143>; Wed, 30 Aug 1995 21:11:53 -0700 Received: from iki.synchromic.com by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id VAA01660; Wed, 30 Aug 1995 21:01:34 -0700 Received: by iki.synchromic.com (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id SAA16325; Wed, 30 Aug 1995 18:03:55 -1000 Date: Wed, 30 Aug 1995 18:03:55 -1000 From: kjh@iki.synchromic.com (Ken Harris) Message-Id: <199508310403.SAA16325@iki.synchromic.com> To: mbone Subject: M-Bone feed Is it possible get a M-Bone feed from you? We are in Maui and on the ANS network, but I don't think they have a feed. The IP address of my (Silicon Graphics) firewall is 199.190.28.34. I would run mrouted on this machine. --- Ken J. Harris. Email: kjh@synchromic.com This space available From list-mgr@ISI.EDU Thu Aug 31 07:42:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04157>; Thu, 31 Aug 1995 08:43:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04109>; Thu, 31 Aug 1995 08:42:29 -0700 Received: from mailer.jhuapl.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA04102>; Thu, 31 Aug 1995 08:42:27 -0700 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA22666; Thu, 31 Aug 1995 11:42:12 -0400 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA08824; Thu, 31 Aug 1995 11:42:11 -0400 Date: Thu, 31 Aug 1995 11:42:11 -0400 (EDT) From: Jim Bogard BIX <jimbo@aplcomm.jhuapl.edu> To: mbone <mbone> Subject: Cisco 10.3(3.1) bug... Huh? Message-Id: <Pine.SOL.3.91.950831114052.15340V-100000@aplcomm.jhuapl.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 371 Could someone please tell me about the bug I seem to remember hearing something about? Or point me to the list archives? I'm getting ready to turn on PIM and I don't want to trash everything.. Thanks. J-. ---- Jim Bogard JHU/APL BIX Group "This is my banjo. There are many Backbone Network Engineer like it, but this one is mine." From list-mgr@ISI.EDU Tue Sep 5 10:27:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03332>; Tue, 5 Sep 1995 17:27:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03277>; Tue, 5 Sep 1995 17:26:37 -0700 Received: from exodus.net (saturn.exodus.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA03269>; Tue, 5 Sep 1995 17:26:35 -0700 Received: by exodus.net (8.6.11/exodus2) id RAA13576; Tue, 5 Sep 1995 17:27:31 -0700 From: ser@exodus.net (Steve Rubin) Message-Id: <199509060027.RAA13576@saturn.exodus.net> Subject: Interesting bug in Symplex routers.. To: mbone Date: Tue, 5 Sep 1995 17:27:30 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 502 Thought you all might be interested... Whenever a Symplex router receives a multicast packet, it sends back a ICMP Bad Host to the source of the multicast packet. I was sending out THOUSANDS of these packets.. I've kicked the cheap router to the curb. This is not a the first bug we've found in this code. -- Steven Eric Rubin - Senior Network Administrator Exodus Communications, Inc. 948 Benecia Ave, Sunnyvale, CA 94086 Email: ser@exodus.net - Phone: (408) 522-8473 From list-mgr@ISI.EDU Wed Sep 6 12:38:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25671>; Wed, 6 Sep 1995 03:44:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25664>; Wed, 6 Sep 1995 03:43:54 -0700 Received: from mailhost.lut.ac.uk (bgate.lut.ac.uk) by venera.isi.edu (5.65c/5.61+local-22) id <AA25641>; Wed, 6 Sep 1995 03:39:51 -0700 Received: (jon@localhost) by weeble.lut.ac.uk (8.6.12/8.6.9) id LAA00224; Wed, 6 Sep 1995 11:38:26 +0100 Date: Wed, 6 Sep 1995 11:38:26 +0100 (BST) From: Jon Knight <J.P.Knight@lut.ac.uk> To: mbone Subject: SunOS 4.1.4 crash Message-Id: <Pine.SUN.3.91.950906113009.174A-100000@weeble.lut.ac.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Has anyone else experienced periodical machine hangs when you're receiving a lot of MBONE traffic to a Sun SS5 running SunOS 4.1.4 with the 3.5 multicast code? My machine isn't the mrouter but when using vat, vic and sd together a few minutes ago (watching the Libtech 95 session on SJIPS) the machine hung completely - I had to L1-A and reboot it from the command monitor. Looking in /var/adm/messages I notice that just before the hang this was recorded: Sep 6 11:19:46 weeble vmunix: DMA_SETUP failed in play! Sep 6 11:19:47 weeble last message repeated 3 times Sep 6 11:19:48 weeble vmunix: DMA_SETUP failed in record! Sep 6 11:26:56 weeble vmunix: DMA_SETUP failed in record! Sep 6 11:26:56 weeble vmunix: DMA_SETUP failed in record! I was _not_ sending anything at the time (either video or audio) and the total bandwidth coming into the machine looks to be about 600Kbps (judging from the vic and vat stats). I did notice that just before the hang that the vat playout times had stretched to > 4.5 seconds. Its done this once before but that was at night while I was doing a backup and so I assumed it was the DMA to the attached tape drive causing problems. However today I was just sitting watching Syngen try to set up his vat session when it happened. Any thoughts on what might be causing this? Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Researcher, Sysop and General Dogsbody, Department of Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. *** If French nuclear weapons aren't harmful, what's the point of them? *** From list-mgr@ISI.EDU Wed Sep 6 06:02:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28317>; Wed, 6 Sep 1995 07:03:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28297>; Wed, 6 Sep 1995 07:02:59 -0700 Received: from thdsun.epm.ornl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA28290>; Wed, 6 Sep 1995 07:02:56 -0700 Received: (from dunigan@localhost) by thdsun.epm.ornl.gov (8.6.10/8.6.10) id KAA23088 for mbone@isi.edu; Wed, 6 Sep 1995 10:02:53 -0400 Date: Wed, 6 Sep 1995 10:02:53 -0400 From: Tom Dunigan 576-2522 <dunigan@thdsun.epm.ornl.gov> Message-Id: <199509061402.KAA23088@thdsun.epm.ornl.gov> To: mbone Subject: seeking software to tunnel a "session" We're seeking software (or other solutions) to be able to tunnel a session (nv,vat, wb) from our Lab site to our neighboring University site. (The MBONE route between the two requires too big a TTL, yet we have a direct T1 to the site). solutions ? thanks tom From list-mgr@ISI.EDU Wed Sep 6 08:30:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02895>; Wed, 6 Sep 1995 09:32:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02835>; Wed, 6 Sep 1995 09:31:34 -0700 Received: from home.merit.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA02827>; Wed, 6 Sep 1995 09:31:32 -0700 Received: from localhost (ljb@localhost) by home.merit.edu (8.6.12/merit-2.0) with SMTP id MAA22409; Wed, 6 Sep 1995 12:30:41 -0400 Message-Id: <199509061630.MAA22409@home.merit.edu> To: Jon Knight <J.P.Knight@lut.ac.uk> Cc: mbone Subject: Re: SunOS 4.1.4 crash In-Reply-To: Your message of "Wed, 06 Sep 1995 11:38:26 BST." <Pine.SUN.3.91.950906113009.174A-100000@weeble.lut.ac.uk> Date: Wed, 06 Sep 1995 12:30:40 -0400 From: "Larry J. Blunk" <ljb@merit.edu> These messages come from the audio driver for the CS4231 chip. Do a strings on /sys/sun4m/OBJ/audio_4231.o. You need patch 102387-01. Patch 102161-04 is the equivalent patch for SunOS 4.1.3_U1. > Has anyone else experienced periodical machine hangs when you're receiving > a lot of MBONE traffic to a Sun SS5 running SunOS 4.1.4 with the 3.5 > multicast code? My machine isn't the mrouter but when using vat, vic and > sd together a few minutes ago (watching the Libtech 95 session on SJIPS) > the machine hung completely - I had to L1-A and reboot it from the > command monitor. Looking in /var/adm/messages I notice that just before > the hang this was recorded: > > Sep 6 11:19:46 weeble vmunix: DMA_SETUP failed in play! > Sep 6 11:19:47 weeble last message repeated 3 times > Sep 6 11:19:48 weeble vmunix: DMA_SETUP failed in record! > Sep 6 11:26:56 weeble vmunix: DMA_SETUP failed in record! > Sep 6 11:26:56 weeble vmunix: DMA_SETUP failed in record! > > I was _not_ sending anything at the time (either video or audio) and the > total bandwidth coming into the machine looks to be about 600Kbps > (judging from the vic and vat stats). I did notice that just before the > hang that the vat playout times had stretched to > 4.5 seconds. Its done > this once before but that was at night while I was doing a backup and so > I assumed it was the DMA to the attached tape drive causing problems. > However today I was just sitting watching Syngen try to set up his vat > session when it happened. Any thoughts on what might be causing this? > > Jon > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Jon Knight, Researcher, Sysop and General Dogsbody, Department of Computer > Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. > *** If French nuclear weapons aren't harmful, what's the point of them? *** > From list-mgr@ISI.EDU Wed Sep 6 18:34:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03006>; Wed, 6 Sep 1995 09:35:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02992>; Wed, 6 Sep 1995 09:34:53 -0700 Received: from mailhost.lut.ac.uk (bgate.lut.ac.uk) by venera.isi.edu (5.65c/5.61+local-22) id <AA02985>; Wed, 6 Sep 1995 09:34:51 -0700 Received: (jon@localhost) by weeble.lut.ac.uk (8.6.12/8.6.9) id RAA01641; Wed, 6 Sep 1995 17:34:21 +0100 Date: Wed, 6 Sep 1995 17:34:21 +0100 (BST) From: Jon Knight <J.P.Knight@lut.ac.uk> To: mbone Subject: Re: SunOS 4.1.4 crash Message-Id: <Pine.SUN.3.91.950906173254.174J-100000@weeble.lut.ac.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks to everyone who suggested Sun patch 102387-01; I thought I'd got all the necessary kernel patches installed on this machine but this one wasn't on my list. Cheers, Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Researcher, Sysop and General Dogsbody, Department of Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. *** If French nuclear weapons aren't harmful, what's the point of them? *** From list-mgr@ISI.EDU Wed Sep 6 03:20:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06013>; Wed, 6 Sep 1995 10:21:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05922>; Wed, 6 Sep 1995 10:21:21 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA05914>; Wed, 6 Sep 1995 10:21:20 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14963(5)>; Wed, 6 Sep 1995 10:20:57 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Wed, 6 Sep 1995 10:20:48 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Tom Dunigan 576-2522 <dunigan@thdsun.epm.ornl.gov> Cc: mbone Subject: Re: seeking software to tunnel a "session" In-Reply-To: Your message of "Wed, 06 Sep 95 07:02:53 PDT." <199509061402.KAA23088@thdsun.epm.ornl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 6 Sep 1995 10:20:32 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Sep6.102048pdt.177475@crevenia.parc.xerox.com> In message <199509061402.KAA23088@thdsun.epm.ornl.gov> you write: >(The MBONE route between the two requires too big a TTL, >yet we have a direct T1 to the site). > >solutions ? If you have a direct T1, then why not run a normal MBONE tunnel over it? You can keep the tunnel up for only the duration of the session, if you are worried about transit traffic. Bill From list-mgr@ISI.EDU Wed Sep 6 19:40:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07080>; Wed, 6 Sep 1995 10:42:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07047>; Wed, 6 Sep 1995 10:41:40 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA07032>; Wed, 6 Sep 1995 10:41:30 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id SAA24042; Wed, 6 Sep 1995 18:40:49 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id SAA20783; Wed, 6 Sep 1995 18:40:45 +0100 Date: Wed, 6 Sep 1995 18:40:43 +0100 (BST) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Bill Fenner <fenner@parc.xerox.com> Cc: Tom Dunigan 576-2522 <dunigan@thdsun.epm.ornl.gov>, mbone Subject: Re: seeking software to tunnel a "session" In-Reply-To: <95Sep6.102048pdt.177475@crevenia.parc.xerox.com> Message-Id: <Pine.SV4.3.91.950906183958.20575A@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 6 Sep 1995, Bill Fenner wrote: > In message <199509061402.KAA23088@thdsun.epm.ornl.gov> you write: > >(The MBONE route between the two requires too big a TTL, > >yet we have a direct T1 to the site). > > > >solutions ? > > If you have a direct T1, then why not run a normal MBONE tunnel over it? You > can keep the tunnel up for only the duration of the session, if you are > worried about transit traffic. Or if there are only two participants (one at either site) run the vat, wb and nv sessions point-to-point. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Wed Sep 6 19:49:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07376>; Wed, 6 Sep 1995 10:50:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07352>; Wed, 6 Sep 1995 10:49:58 -0700 Received: from mailhost.lut.ac.uk (bgate.lut.ac.uk) by venera.isi.edu (5.65c/5.61+local-22) id <AA07341>; Wed, 6 Sep 1995 10:49:54 -0700 Received: (jon@localhost) by weeble.lut.ac.uk (8.6.12/8.6.9) id SAA01924; Wed, 6 Sep 1995 18:49:20 +0100 Date: Wed, 6 Sep 1995 18:49:19 +0100 (BST) From: Jon Knight <J.P.Knight@lut.ac.uk> To: mbone Subject: map-mbone on SunOS 4.1.4 (was Re: SunOS 4.1.4 crashes) Message-Id: <Pine.SUN.3.91.950906184441.174P-100000@weeble.lut.ac.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII [Just so that I don't confuse people too much, this is a reply to a private email that Brian sent me. Unfortunately Brian's email address (bruptash@soft.gtech.com) seems to be broken for me so I hope he won't mind me sharing the reply to the list - it might be a problem for others as well. Sorry for wasting time and bandwidth if its not of interest]. On Wed, 6 Sep 1995, Brian A. Ruptash (bruptash@soft.gtech.com) wrote: > I was wondering whether my problems with SunOS 4.1.4 were just me... > > When I run map-mbone, I get a bus exception core dump after a few > seconds of activity, whereas under 4.1.3_U1, it worked just fine. I > don't see any kernel messages, but perhaps you could run "map-mbone" > and see if you get the core dump as well. Maybe the root cause is > somehow related. Well I just gave it a quick test run here at it works fine for me with no extra command line parameters. Are you using any extra parameters or anything? Just to check I _have_ got these matches installed on my machine: 100444-66 100452-71 100478-01 102264-02 102322-01 102394-01 102402-01 102409-01 102414-01 102416-01 102431-01 102433-01 102436-01 I haven't installed the suggested patch for the audio DMA failure yet so I can't say whether that will make any difference. Jon - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Researcher, Sysop and General Dogsbody, Department of Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. *** If French nuclear weapons aren't harmful, what's the point of them? *** From list-mgr@ISI.EDU Wed Sep 6 08:21:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20183>; Wed, 6 Sep 1995 15:22:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20169>; Wed, 6 Sep 1995 15:21:39 -0700 Received: from elxr.jpl.nasa.gov (elxr-fddi.jpl.nasa.gov) by venera.isi.edu (5.65c/5.61+local-22) id <AA20162>; Wed, 6 Sep 1995 15:21:37 -0700 Received: from localhost.jpl.nasa.gov (localhost.jpl.nasa.gov [127.0.0.1]) by elxr.jpl.nasa.gov (8.6.12/8.6.6) with SMTP id PAA05687 for <mbone@isi.edu>; Wed, 6 Sep 1995 15:21:59 -0700 Message-Id: <199509062221.PAA05687@elxr.jpl.nasa.gov> To: mbone Subject: ip_mrouter socket queue full Date: Wed, 06 Sep 1995 15:21:58 -0700 From: Dave Hayes <dave@elxr.jpl.nasa.gov> Upon seeing this syslog entry: Sep 4 00:39:22 elxr vmunix: ip_mforward: ip_mrouter socket queue full elxr> ps awux | egrep mroute root 532 1.2 1.4 4804 1248 ? S Aug 24329:41 ./mrouted Almost 5 megabytes? Really? What gives? ------ Dave Hayes -- Institutional NETworks - Section 394 -- JPL/NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh The best way to make your dreams come true is to wake up. From list-mgr@ISI.EDU Thu Sep 7 71:31:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20693>; Wed, 6 Sep 1995 15:33:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20665>; Wed, 6 Sep 1995 15:32:44 -0700 Received: from bee.uspnet.usp.br by venera.isi.edu (5.65c/5.61+local-22) id <AA20658>; Wed, 6 Sep 1995 15:32:36 -0700 Return-Path: uratsuka@lsi.usp.br Received: from mozart.lsi.usp.br (mozart.lsi.usp.br [143.107.3.237]) by bee.uspnet.usp.br (8.6.10/SPARC10-CCE2.0)id TAA28609 Date: Wed, 6 Sep 1995 15:31:43 +48000 From: Andre Uratsuka Manoel <uratsuka@lsi.usp.br> To: mbone <mbone> Subject: MBONE Tunnel to MCI Message-Id: <Pine.SGI.3.90.950906153043.9462A-100000@mozart.lsi.usp.br> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, All, Sorry to bother again. I'd like to know who to contact in order to get a tunnel set up with MCI. Regards, Andre From list-mgr@ISI.EDU Wed Sep 6 14:54:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21697>; Wed, 6 Sep 1995 15:55:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21686>; Wed, 6 Sep 1995 15:55:25 -0700 Received: from j51.com by venera.isi.edu (5.65c/5.61+local-22) id <AA21678>; Wed, 6 Sep 1995 15:55:23 -0700 Received: (from gwh@localhost) by j51.com (8.6.12/8.6.9) id WAA25769; Wed, 6 Sep 1995 22:54:21 GMT Message-Id: <199509062254.WAA25769@j51.com> From: gwh@spiders.com Date: Wed, 6 Sep 1995 18:54:21 -0400 In-Reply-To: Andre Uratsuka Manoel's message as of Aug 17, 11:31 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Andre Uratsuka Manoel <uratsuka@lsi.usp.br>, mbone <mbone> Subject: Re: MBONE Tunnel to MCI +--- | Sorry to bother again. I'd like to know who to contact in order | to get a tunnel set up with MCI. +--- If you get an answer to this, please forward it on to me. If not, let me know and I'll get the answer for you next week. Thanks! --Gene -- Gene W. Homicki gwh@spiders.com Objective Consulting, Inc. http://www.spiders.com/ Internet Presence Design voice: +1 914.353.3511 From list-mgr@ISI.EDU Thu Sep 7 08:46:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21050>; Thu, 7 Sep 1995 09:47:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21011>; Thu, 7 Sep 1995 09:46:51 -0700 Received: from mailer.psc.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA21004>; Thu, 7 Sep 1995 09:46:49 -0700 Received: from zippy.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA19606; Thu, 7 Sep 1995 12:46:37 -0400 Message-Id: <9509071646.AA19606@mailer.psc.edu> To: mbone Cc: mathis@psc.edu Subject: #### MBONE topology bugs ##### Date: Thu, 07 Sep 1995 12:46:24 -0400 From: "Matt Mathis" <mathis@zippy.psc.edu> I have found a clear example of "form follows organization" in the current MBone topology. One of the problems with the mbone is that it has become split into two large clouds: the MCI attached networks which are strongly meshed among themselves (in the tradition of the old NSFnet), and Sprintlink/ICM/Alternet/PSI/..., who take the responsibility to feed their customers directly. Each cloud is internally well connected, but the gulf between them is deep and tenuous. This is clearly a result of the social/political problems associated with trying to engineer tunnels between one national provider and a competing provider's customers.... The existing connectivity seems to be through dual connected customers of customers.... many hops way down in the provider's redistribution trees. To fix this I suggest the following tunnels: SURAnet to Alternet (ca FIX-EAst) (There is a non-functional tunnel that should be restored) NEARnet (or PSC) to Sprintlink/ICM (ca the NJ NAP) MichNet (or Argonne or Sesquinet or PSC) to ??? (ca the CHI NAP) NorthWestNet to BARRnet (Both on MCI) NASA (or BARRnet) to ??? (ca CA NAP) Note that I don't have detailed IP topology information, so I could easily have blown one of the above recommendations. The design algorithm was: for each key interconnect, select a topologically near, T3 connected MCI customer, and pair them with an NSP across the interconnect. If you are at one of the above mentioned sites (or fit the criterion in the algorithm) please consider volunteering a tunnel. A slightly longer range solution is for MCI to engineer and/or provide MBone feeds to their customers, and to strengthen the alignment between the topology of the MBone and the topology of the Internet... I will be monitoring/testing the NANOG and IPPM multicast sessions all day today and tomorrow. If you can see me and want to chat, just holler. If you can't see me, then it's broken and you are not going to see NANOG either. Thanks for your attention, --MM-- From list-mgr@ISI.EDU Thu Sep 7 03:25:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22516>; Thu, 7 Sep 1995 10:26:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22470>; Thu, 7 Sep 1995 10:26:03 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA22461>; Thu, 7 Sep 1995 10:26:01 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id KAA04616; Thu, 7 Sep 1995 10:25:54 -0700 Date: Thu, 7 Sep 1995 10:25:54 -0700 From: Dino Farinacci <dino@cisco.com> Message-Id: <199509071725.KAA04616@stilton.cisco.com> To: mathis@zippy.psc.edu Cc: mbone, mathis@psc.edu In-Reply-To: "Matt Mathis"'s message of Thu, 07 Sep 1995 12:46:24 -0400 <9509071646.AA19606@mailer.psc.edu> Subject: #### MBONE topology bugs ##### >> A slightly longer range solution is for MCI to engineer and/or provide MBone >> feeds to their customers, and to strengthen the alignment between the >> topology of the MBone and the topology of the Internet... How about putting in place more native multicasting rather than using tunnels? Dino From list-mgr@ISI.EDU Thu Sep 7 04:33:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26107>; Thu, 7 Sep 1995 11:35:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26086>; Thu, 7 Sep 1995 11:35:04 -0700 Received: from noc.netcom.net by venera.isi.edu (5.65c/5.61+local-22) id <AA26079>; Thu, 7 Sep 1995 11:35:02 -0700 Received: by noc.netcom.net (8.6.12/SMI-4.1) id LAA07390; Thu, 7 Sep 1995 11:33:27 -0700 Date: Thu, 7 Sep 1995 11:33:27 -0700 Message-Id: <199509071833.LAA07390@noc.netcom.net> From: mbone@netcom.com (MBONE administrator) To: mbone Subject: Re: #### MBONE topology bugs ##### Cc: > >I have found a clear example of "form follows organization" in the current >MBone topology. One of the problems with the mbone is that it has become >split into two large clouds: the MCI attached networks which are strongly >meshed among themselves (in the tradition of the old NSFnet), and >Sprintlink/ICM/Alternet/PSI/..., who take the responsibility to feed their >customers directly. Each cloud is internally well connected, but the gulf >between them is deep and tenuous. This is clearly a result of the >social/political problems associated with trying to engineer tunnels between >one national provider and a competing provider's customers.... > >The existing connectivity seems to be through dual connected customers of >customers.... many hops way down in the provider's redistribution trees. > >To fix this I suggest the following tunnels: > >SURAnet to Alternet (ca FIX-EAst) >(There is a non-functional tunnel that should be restored) > >NEARnet (or PSC) to Sprintlink/ICM (ca the NJ NAP) > >MichNet (or Argonne or Sesquinet or PSC) to ??? (ca the CHI NAP) > >NorthWestNet to BARRnet (Both on MCI) > >NASA (or BARRnet) to ??? (ca CA NAP) We (NETCOM) have very good West Coast connectivity, and would be willing to tunnel to several other good MBONE sites, over the CA NAP, CIX SMDS, or MAE-WEST. (CA NAP preferred). We have good connectivity in the East as well, but our mrouter coverage only extends as far east as Dallas currently. We are planning on setting up one or more in DC, but that won't be for some months. We are on the Chicago NAP, perhaps we could tunnel to MichNet across this. > >Note that I don't have detailed IP topology information, so I could easily >have blown one of the above recommendations. > >The design algorithm was: for each key interconnect, select a topologically >near, T3 connected MCI customer, and pair them with an NSP across the >interconnect. > >If you are at one of the above mentioned sites (or fit the criterion in the >algorithm) please consider volunteering a tunnel. > >A slightly longer range solution is for MCI to engineer and/or provide MBone >feeds to their customers, and to strengthen the alignment between the >topology of the MBone and the topology of the Internet... > >I will be monitoring/testing the NANOG and IPPM multicast sessions all day >today and tomorrow. If you can see me and want to chat, just holler. If you >can't see me, then it's broken and you are not going to see NANOG either. > > >Thanks for your attention, >--MM-- > +jeff -- Jeff Rizzo Sr. Network Administrator From list-mgr@ISI.EDU Thu Sep 7 11:05:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27409>; Thu, 7 Sep 1995 12:05:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27389>; Thu, 7 Sep 1995 12:05:29 -0700 Received: from POSTOFFICE2.MAIL.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA27382>; Thu, 7 Sep 1995 12:05:27 -0700 Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice2.mail.cornell.edu (8.6.9/8.6.9) with SMTP id PAA24295; Thu, 7 Sep 1995 15:05:21 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: <v02120003ac74f2ba3bf7@[132.236.199.117]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Sep 1995 15:05:43 -0400 To: Dino Farinacci <dino@cisco.com> From: Scott W Brim <swb1@cornell.edu> Subject: Re: #### MBONE topology bugs ##### Cc: mbone At 10:25 09/07/95, Dino Farinacci wrote: > How about putting in place more native multicasting rather than using > tunnels? > >Dino We would but we don't trust the cisco code yet. (hee hee) From list-mgr@ISI.EDU Thu Sep 7 05:27:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28631>; Thu, 7 Sep 1995 12:28:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28612>; Thu, 7 Sep 1995 12:27:44 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA28605>; Thu, 7 Sep 1995 12:27:42 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id MAA10293; Thu, 7 Sep 1995 12:27:35 -0700 Date: Thu, 7 Sep 1995 12:27:35 -0700 From: Dino Farinacci <dino@cisco.com> Message-Id: <199509071927.MAA10293@stilton.cisco.com> To: swb1@cornell.edu Cc: mbone In-Reply-To: Scott W Brim's message of Thu, 7 Sep 1995 15:05:43 -0400 <v02120003ac74f2ba3bf7@[132.236.199.117]> Subject: #### MBONE topology bugs ##### >> We would but we don't trust the cisco code yet. (hee hee) What little faith we have :-) Dino From list-mgr@ISI.EDU Thu Sep 7 11:37:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29138>; Thu, 7 Sep 1995 12:38:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29071>; Thu, 7 Sep 1995 12:37:53 -0700 Received: from fender.pica.army.mil by venera.isi.edu (5.65c/5.61+local-22) id <AA29064>; Thu, 7 Sep 1995 12:37:52 -0700 Date: Thu, 7 Sep 95 15:37:45 EDT From: "Dennis G. Rears" <drears@Pica.Army.Mil> To: mbone Cc: drears@Pica.Army.Mil, rfd@Pica.Army.Mil Subject: Request for MBONE Tunnel feed request Message-Id: <9509071537.aa17488@fender.Pica.Army.Mil> I am requesting access to the MBONE and I need a tunnel feed. My organization is: U.S. Army ARDEC ATTN: AMSTA-AR-IMN Picatinny Arsenal, NJ 07806 Dennis G. Rears (201) 724-2683 DSN 880-2683 4749 (fax) The mrouter server will be bpsouth.pica.army.mil; 129.139.68.19 We are on DREN and have T1 links to West Point, NY; Ft. Monmouth,NJ; Hanscom AFB; and ARL in Aberdeen, MD. dennis From list-mgr@ISI.EDU Thu Sep 7 04:39:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01878>; Thu, 7 Sep 1995 13:39:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01842>; Thu, 7 Sep 1995 13:39:10 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA01834>; Thu, 7 Sep 1995 13:39:08 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <18991(20)>; Thu, 7 Sep 1995 11:40:33 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Thu, 7 Sep 1995 11:39:30 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: "Matt Mathis" <mathis@zippy.psc.edu> Cc: mbone Subject: Re: #### MBONE topology bugs ##### In-Reply-To: Your message of "Thu, 07 Sep 95 09:46:24 PDT." <9509071646.AA19606@mailer.psc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 7 Sep 1995 11:39:16 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Sep7.113930pdt.177475@crevenia.parc.xerox.com> In message <9509071646.AA19606@mailer.psc.edu> you write: >To fix this I suggest the following tunnels: > >SURAnet to Alternet (ca FIX-EAst) >(There is a non-functional tunnel that should be restored) There's a tunnel from PSI (on MAE-East) to Alternet, and PSI and Sura peer on MAE-East. >NorthWestNet to BARRnet (Both on MCI) I asked NWNet and BARRNet some time ago if they would do this; BARRNet said that their MCI connection was already heavily loaded and that they weren't interested in putting another MBONE tunnel over it. We were going to try to work something out between NSI, NERO and NWNet but haven't yet. NANOG seems like an awfully good place to bring this up, don't you think? Bill From list-mgr@ISI.EDU Thu Sep 7 05:37:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01883>; Thu, 7 Sep 1995 13:39:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01858>; Thu, 7 Sep 1995 13:39:15 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA01850>; Thu, 7 Sep 1995 13:39:13 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16186(15)>; Thu, 7 Sep 1995 12:38:30 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Thu, 7 Sep 1995 12:38:14 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: mbone@netcom.com (MBONE administrator) Cc: mbone Subject: Re: #### MBONE topology bugs ##### In-Reply-To: Your message of "Thu, 07 Sep 95 11:33:27 PDT." <199509071833.LAA07390@noc.netcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 7 Sep 1995 12:37:59 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Sep7.123814pdt.177475@crevenia.parc.xerox.com> In message <199509071833.LAA07390@noc.netcom.net> you write: >We (NETCOM) have very good West Coast connectivity, and would be willing to >tunnel to several other good MBONE sites, over the CA NAP, CIX SMDS, or >MAE-WEST. (CA NAP preferred). The current path to Netcom goes via dc-mbone-1.sprintlink.net, which has *30* tunnels. I don't know what kind of machine dc-mbone-1.sprintlink.net is, and I don't know what kind of LAN it is attached to, but note that at the nominal MBONE bandwidth (500kbps) this is 15Mbps. Unfortunately, it is running mrouted 2.2, meaning that you can't even make any loss measurements through it; maybe it's a really fast machine on a really fast network and can handle all of these tunnels. However, without mtrace, I can't tell, meaning that I have to assume that it's bad. I wouldn't want to suggest creating a low-metric cross-country path that crosses dc-mbone-1.sprintlink.net, which seems to be what hooking up Netcom on the west coast would do. Bill From list-mgr@ISI.EDU Thu Sep 7 12:41:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01978>; Thu, 7 Sep 1995 13:42:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01944>; Thu, 7 Sep 1995 13:41:59 -0700 Received: from clone4.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA01934>; Thu, 7 Sep 1995 13:41:58 -0700 Received: from localhost (localhost.mci.net [127.0.0.1]) by clone4.reston.mci.net (8.6.12/8.6.6) with ESMTP id QAA22745; Thu, 7 Sep 1995 16:41:54 -0400 Message-Id: <199509072041.QAA22745@clone4.reston.mci.net> To: "Matt Mathis" <mathis@zippy.psc.edu> Cc: mbone, mathis@psc.edu Subject: Re: #### MBONE topology bugs ##### In-Reply-To: Your message of "Thu, 07 Sep 1995 12:46:24 EDT." <9509071646.AA19606@mailer.psc.edu> Date: Thu, 07 Sep 1995 16:41:53 -0400 From: "Jeff Young" <young@mci.net> I had hoped that we would have a complete and tested service before announcing to this group but given the nature of your message, announcing now seems like a good thing. We've noticed the same "form follows organization" in the current MBone topology and have been deploying an MCI Mbone with the hope of reorganizing some of the many tunnels that cross our backbone. At present we have a set of deployed mrouters running mrouted 3.6. Our infrastructure will be ready for early implementors by the end of this month. I plan to work out agreements with other providers (Sprintlink/ICM/Alternet/PSI/...) individually, but would certainly welcome the wisdom of this list in finding those links that make the most sense now. Jeff Young young@mci.net > To: mbone@ISI.EDU > Cc: mathis@psc.edu > Subject: #### MBONE topology bugs ##### > Date: Thu, 07 Sep 1995 12:46:24 -0400 > From: "Matt Mathis" <mathis@zippy.psc.edu> > > > I have found a clear example of "form follows organization" in the current > MBone topology. One of the problems with the mbone is that it has become > split into two large clouds: the MCI attached networks which are strongly > meshed among themselves (in the tradition of the old NSFnet), and > Sprintlink/ICM/Alternet/PSI/..., who take the responsibility to feed their > customers directly. Each cloud is internally well connected, but the gulf > between them is deep and tenuous. This is clearly a result of the > social/political problems associated with trying to engineer tunnels between > one national provider and a competing provider's customers.... > > The existing connectivity seems to be through dual connected customers of > customers.... many hops way down in the provider's redistribution trees. > > To fix this I suggest the following tunnels: > > SURAnet to Alternet (ca FIX-EAst) > (There is a non-functional tunnel that should be restored) > > NEARnet (or PSC) to Sprintlink/ICM (ca the NJ NAP) > > MichNet (or Argonne or Sesquinet or PSC) to ??? (ca the CHI NAP) > > NorthWestNet to BARRnet (Both on MCI) > > NASA (or BARRnet) to ??? (ca CA NAP) > > Note that I don't have detailed IP topology information, so I could easily > have blown one of the above recommendations. > > The design algorithm was: for each key interconnect, select a topologically > near, T3 connected MCI customer, and pair them with an NSP across the > interconnect. > > If you are at one of the above mentioned sites (or fit the criterion in the > algorithm) please consider volunteering a tunnel. > > A slightly longer range solution is for MCI to engineer and/or provide MBone > feeds to their customers, and to strengthen the alignment between the > topology of the MBone and the topology of the Internet... > > I will be monitoring/testing the NANOG and IPPM multicast sessions all day > today and tomorrow. If you can see me and want to chat, just holler. If you > can't see me, then it's broken and you are not going to see NANOG either. > > > Thanks for your attention, > --MM-- > From list-mgr@ISI.EDU Thu Sep 7 13:01:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02853>; Thu, 7 Sep 1995 14:02:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02837>; Thu, 7 Sep 1995 14:01:43 -0700 Received: from nic.hq.cic.net by venera.isi.edu (5.65c/5.61+local-22) id <AA02822>; Thu, 7 Sep 1995 14:01:39 -0700 Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id RAA26516; Thu, 7 Sep 1995 17:01:33 -0400 Date: Thu, 7 Sep 1995 17:01:32 -0400 (EDT) From: Dorian Rysling Kim <dorian@CIC.Net> X-Sender: dorian@nic.hq.cic.net To: MBONE administrator <mbone@netcom.com> Cc: mbone Subject: Re: #### MBONE topology bugs ##### In-Reply-To: <199509071833.LAA07390@noc.netcom.net> Message-Id: <Pine.OSF.3.91.950907170046.24142A-100000@nic.hq.cic.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > >A slightly longer range solution is for MCI to engineer and/or provide MBone > >feeds to their customers, and to strengthen the alignment between the > >topology of the MBone and the topology of the Internet... I believe MCI is doing just this at this point. -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From list-mgr@ISI.EDU Thu Sep 7 13:19:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03660>; Thu, 7 Sep 1995 14:19:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03644>; Thu, 7 Sep 1995 14:19:34 -0700 Received: from nic.hq.cic.net by venera.isi.edu (5.65c/5.61+local-22) id <AA03637>; Thu, 7 Sep 1995 14:19:33 -0700 Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id RAA26837; Thu, 7 Sep 1995 17:19:28 -0400 Date: Thu, 7 Sep 1995 17:19:27 -0400 (EDT) From: Dorian Rysling Kim <dorian@CIC.Net> X-Sender: dorian@nic.hq.cic.net To: Matt Mathis <mathis@zippy.psc.edu> Cc: mbone, mathis@psc.edu Subject: Re: #### MBONE topology bugs ##### In-Reply-To: <9509071646.AA19606@mailer.psc.edu> Message-Id: <Pine.OSF.3.91.950907171642.24142E-100000@nic.hq.cic.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 7 Sep 1995, Matt Mathis wrote: > MichNet (or Argonne or Sesquinet or PSC) to ??? (ca the CHI NAP) Currently, there's a tunnel between CICNet and MichNet, Argonne, UIUC, Merit, and Sesquinet. The tunnel to Argonne and Sesquinet are down right now, but they could be revived, I think. So I'm not sure what the above would accomplish in addition to the existing topology.. -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From list-mgr@ISI.EDU Thu Sep 7 13:33:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04270>; Thu, 7 Sep 1995 14:33:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04242>; Thu, 7 Sep 1995 14:33:12 -0700 Received: from mailer.psc.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA04235>; Thu, 7 Sep 1995 14:33:10 -0700 Received: from zippy.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA25258; Thu, 7 Sep 1995 17:33:02 -0400 Message-Id: <9509072133.AA25258@mailer.psc.edu> To: Dorian Rysling Kim <dorian@cic.net> Cc: Matt Mathis <mathis@zippy.psc.edu>, mbone, mathis@psc.edu Subject: Re: #### MBONE topology bugs ##### In-Reply-To: Your message of "Thu, 07 Sep 1995 17:19:27 EDT." <Pine.OSF.3.91.950907171642.24142E-100000@nic.hq.cic.net> Date: Thu, 07 Sep 1995 17:33:01 -0400 From: "Matt Mathis" <mathis@zippy.psc.edu> My point was that you are all MCI connected, (and well meshed), but as a group there appears to be no tunnels to the other top level providers: Sprintlink, Alternet, ANS, PSI, etc. --MM-- From list-mgr@ISI.EDU Thu Sep 7 14:16:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06416>; Thu, 7 Sep 1995 15:19:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06396>; Thu, 7 Sep 1995 15:19:33 -0700 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA06389>; Thu, 7 Sep 1995 15:19:30 -0700 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA07451; Thu, 7 Sep 1995 18:16:50 +0500 Message-Id: <9509072216.AA07451@msf.psi.net.> To: "Jeff Young" <young@mci.net> Cc: "Matt Mathis" <mathis@zippy.psc.edu>, mbone Subject: Re: #### MBONE topology bugs ##### In-Reply-To: Your message of "Thu, 07 Sep 1995 16:41:53 EDT." <199509072041.QAA22745@clone4.reston.mci.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <7449.810512208.1@msf.psi.net> Date: Thu, 07 Sep 1995 18:16:49 -0400 From: "Mark S. Fedor" <fedor@msf.psi.net> Content-Length: 3893 Mae-bone.psi.net has a tunnel to sesquinet which happens to be the sink/source for approx 80% of the routes on mae-bone when I last checked. The sesquinet tunnel was a relic from the nsfnet days and was mae-bone's link to the mbone "core". There is an ever increasing number of "native" multicast speakers on mae-east. Not sure how this plays out. During Matt's tests today, I was experiencing 30-40% packet loss on matt's video and audio streams at mae-bone.psi.net. Things were coming through the sesquinet tunnel. It would be nice to tear down the sesquinet tunnel and tunnel with MCI mbone infrastructure at mae-bone. Just let me know when and where. thanks, Mark ---------- > > I had hoped that we would have a complete and tested service before > announcing to this group but given the nature of your message, announcing > now seems like a good thing. > > We've noticed the same "form follows organization" in the current > MBone topology and have been deploying an MCI Mbone with the hope > of reorganizing some of the many tunnels that cross our backbone. > > At present we have a set of deployed mrouters running mrouted 3.6. > Our infrastructure will be ready for early implementors by the end > of this month. I plan to work out agreements with other providers > (Sprintlink/ICM/Alternet/PSI/...) individually, but would certainly > welcome the wisdom of this list in finding those links that make > the most sense now. > > Jeff Young > young@mci.net > > > > > To: mbone@ISI.EDU > > Cc: mathis@psc.edu > > Subject: #### MBONE topology bugs ##### > > Date: Thu, 07 Sep 1995 12:46:24 -0400 > > From: "Matt Mathis" <mathis@zippy.psc.edu> > > > > > > I have found a clear example of "form follows organization" in the current > > MBone topology. One of the problems with the mbone is that it has become > > split into two large clouds: the MCI attached networks which are strongly > > meshed among themselves (in the tradition of the old NSFnet), and > > Sprintlink/ICM/Alternet/PSI/..., who take the responsibility to feed their > > customers directly. Each cloud is internally well connected, but the gulf > > between them is deep and tenuous. This is clearly a result of the > > social/political problems associated with trying to engineer tunnels betwee n > > one national provider and a competing provider's customers.... > > > > The existing connectivity seems to be through dual connected customers of > > customers.... many hops way down in the provider's redistribution trees. > > > > To fix this I suggest the following tunnels: > > > > SURAnet to Alternet (ca FIX-EAst) > > (There is a non-functional tunnel that should be restored) > > > > NEARnet (or PSC) to Sprintlink/ICM (ca the NJ NAP) > > > > MichNet (or Argonne or Sesquinet or PSC) to ??? (ca the CHI NAP) > > > > NorthWestNet to BARRnet (Both on MCI) > > > > NASA (or BARRnet) to ??? (ca CA NAP) > > > > Note that I don't have detailed IP topology information, so I could easily > > have blown one of the above recommendations. > > > > The design algorithm was: for each key interconnect, select a topologically > > near, T3 connected MCI customer, and pair them with an NSP across the > > interconnect. > > > > If you are at one of the above mentioned sites (or fit the criterion in the > > algorithm) please consider volunteering a tunnel. > > > > A slightly longer range solution is for MCI to engineer and/or provide MBon e > > feeds to their customers, and to strengthen the alignment between the > > topology of the MBone and the topology of the Internet... > > > > I will be monitoring/testing the NANOG and IPPM multicast sessions all day > > today and tomorrow. If you can see me and want to chat, just holler. If y ou > > can't see me, then it's broken and you are not going to see NANOG either. > > > > > > Thanks for your attention, > > --MM-- > > > > > From list-mgr@ISI.EDU Fri Sep 8 02:36:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07248>; Thu, 7 Sep 1995 15:37:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07211>; Thu, 7 Sep 1995 15:37:09 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA07202>; Thu, 7 Sep 1995 15:37:07 -0700 Received: from it.kth.se (e93_mda@nostromo.electrum.kth.se [130.237.215.5]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id AAA24747; Fri, 8 Sep 1995 00:36:58 +0200 Message-Id: <199509072236.AAA24747@piraya.electrum.kth.se> To: "Matt Mathis" <mathis@zippy.psc.edu> Cc: mbone, mathis@psc.edu, e93_mda@it.kth.se Subject: Re: #### MBONE topology bugs ##### In-Reply-To: Your message of "Thu, 07 Sep 1995 12:46:24 EDT." <9509071646.AA19606@mailer.psc.edu> Date: Fri, 08 Sep 1995 00:36:54 +0200 From: Magnus <e93_mda@it.kth.se> Hi Mboners! When talking about topology bugs, I would like to point out a few from an European point of view. During the 33rd IETF transmission from Stockholm I had to make a few changes in how we fed the US (and those behind US). I got an interesting map showing what happen on the IP layer with the tunnel packets that comes from the 34Mbps line from Stockholm.... it would be routed through the old mae-east network, which is bad (acording to my source). So our primary target machine had to be changed. In any case is the redundancy quite low when passing the Atlantic, this was shown when the 34 where cut during a fishingtour.... During the IETF I changed both the IETF hotel feed and the stockholm.mbone.ebone .net feed to mae-bone.psi.net towards mbone-east.ans.net There was also a need to cut the mbone.sura.net link to laphrog.cs.ucl.ac.uk. There is also two other links to the US ... but they where not changed except for their metrics. Now, if someone could enligthen me somewhat more on the IP layer netstructure and also provide me with good ideas on changes... please come forward! Magnus From list-mgr@ISI.EDU Thu Sep 7 13:51:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11202>; Thu, 7 Sep 1995 16:57:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10920>; Thu, 7 Sep 1995 16:52:14 -0700 Received: from ACADEM.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA10908>; Thu, 7 Sep 1995 16:52:13 -0700 Received: (from sob@localhost) by academ.com (8.6.12/8.6.9) id SAA10691; Thu, 7 Sep 1995 18:51:44 -0500 Message-Id: <199509072351.SAA10691@academ.com> From: sob@academ.com (Stan Barber) Date: Thu, 7 Sep 1995 18:51:44 CDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Mark S. Fedor" <fedor@msf.psi.net>, "Jeff Young" <young@mci.net> Subject: Re: #### MBONE topology bugs ##### Cc: "Matt Mathis" <mathis@zippy.psc.edu>, mbone Do you suspect a load problem at the SESQUINET tunnel? Is it just too much or what? We are running the latest multicase stuff and mrouted as well as the lastest SunOS. I would appreciate any analysis anyone would care to share. SESQUINET does intend to connecto the MCI Mbone infrastructure once someone at MCI decides to tell me where. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From list-mgr@ISI.EDU Thu Sep 7 10:14:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11929>; Thu, 7 Sep 1995 17:15:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11908>; Thu, 7 Sep 1995 17:15:17 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA11901>; Thu, 7 Sep 1995 17:15:15 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15108(6)>; Thu, 7 Sep 1995 17:15:04 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Thu, 7 Sep 1995 17:15:00 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: "Mark S. Fedor" <fedor@msf.psi.net>, mbone-nsi@nsipo.nasa.gov Cc: mbone Subject: Re: #### MBONE topology bugs ##### In-Reply-To: Your message of "Thu, 07 Sep 95 15:16:49 PDT." <95Sep7.154210pdt.59576@klute.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 7 Sep 1995 17:14:58 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Sep7.171500pdt.177475@crevenia.parc.xerox.com> In message <95Sep7.154210pdt.59576@klute.parc.xerox.com> you write: >During Matt's tests today, I was experiencing 30-40% packet loss on >matt's video and audio streams at mae-bone.psi.net. Things were >coming through the sesquinet tunnel. It's kind of interesting that the path from Pittsburgh to D.C. goes via the West Coast, but I think that's an artifact of mbone-east.ans.net being down. In any case, mtrace tells a story about this; it looks like the link from mbone.nsi.nasa.gov to mbone.sdsc.edu is dropping a large number of packets. This is a trace of the NASA Shuttle Video from ARC to PSI. Waiting to accumulate statistics... Results after 190 seconds: Source Response Dest Packet Statistics For Only For Traffic 128.102.84.140 224.0.1.32 All Multicast Traffic From 128.102.84.140 | __/ rtt 302 ms Lost/Sent = Pct Rate To 224.2.142.95 v / hop -65 s --------------------- -------------------- 128.102.84.150 arcbone.arc.nasa.gov | ^ ttl 32 0/165 = 0% 16 pps 0/158 = 0% 15 pps v | hop 66 s 2/3565 = 0% 18 pps 2/2931 = 0% 15 pps 192.203.230.242 mbone2.nsi.nasa.gov | ^ ttl 33 -1/185 = 0% 18 pps -1/158 = 0% 15 pps v | hop -654 ms 0/3968 = 0% 20 pps 0/2929 = 0% 15 pps 192.203.230.241 mbone.nsi.nasa.gov | ^ ttl 64 52/321 = 16% 29 pps 16/159 = 10% 14 pps v | hop -2 s 1123/6649 = 17% 34 pps 283/2929 = 10% 15 pps 198.17.47.39 mbone.sdsc.edu | ^ ttl 65 17/261 = 7% 26 pps 6/143 = 4% 14 pps v | hop 3010 ms 172/5315 = 3% 28 pps 64/2646 = 2% 14 pps 128.241.0.91 VINEGAR.SESQUI.NET | ^ ttl 66 -5/265 = -1% 26 pps -1/137 = 0% 13 pps v | hop 43 s 0/5544 = 0% 29 pps 1/2582 = 0% 13 pps 192.41.177.247 mae-bone.psi.net | \__ ttl 67 723 72 pps 138 13 pps v \ hop -43 s 14121 74 pps 2581 13 pps 192.41.177.247 13.2.116.11 Receiver Query Source Note that SDSC<>SESQUI is also seeing some loss. Last time this happened, it was because NSI's unicast routers were overloaded. Is there a similar thing going on now? Bill From list-mgr@ISI.EDU Thu Sep 7 09:51:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12627>; Thu, 7 Sep 1995 17:35:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12615>; Thu, 7 Sep 1995 17:35:28 -0700 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA12606>; Thu, 7 Sep 1995 17:35:26 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA04789 (5.65c/IDA-1.4.4nsd for <mbone@isi.edu>); Thu, 7 Sep 1995 16:51:57 -0700 Received: by jaspar.NSD.3Com.COM id AA05827 (5.65c/IDA-1.4.4-910730 for mbone@isi.edu); Thu, 7 Sep 1995 16:51:56 -0700 From: "Cyndi M. Jung" <cmj@NSD.3Com.COM> Message-Id: <199509072351.AA05827@jaspar.NSD.3Com.COM> Subject: Re: #### MBONE topology bugs ##### To: mbone Date: Thu, 7 Sep 1995 16:51:55 -0700 (PDT) In-Reply-To: <v02120003ac74f2ba3bf7@[132.236.199.117]> from "Scott W Brim" at Sep 7, 95 03:05:43 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 580 > > At 10:25 09/07/95, Dino Farinacci wrote: > > How about putting in place more native multicasting rather than using > > tunnels? > > > >Dino > To which Scott Brim replied: > We would but we don't trust the cisco code yet. (hee hee) > > > You don't have to trust the cisco code - we are currently beta testing both DVMRP and MOSPF for 3Com routers. Our DVMRP is at the 3.5 level - and it prunes. I guess you'll have to distrust our code too ;-) Cyndi Jung PS Apologies for any commercial implications of this message - I tried to resist, really I did. From list-mgr@ISI.EDU Thu Sep 7 20:44:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20115>; Thu, 7 Sep 1995 21:50:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19977>; Thu, 7 Sep 1995 21:49:45 -0700 Received: from admii.arl.mil by venera.isi.edu (5.65c/5.61+local-22) id <AA19970>; Thu, 7 Sep 1995 21:49:43 -0700 Date: Fri, 8 Sep 95 0:44:56 EDT From: Phil Dykstra <phil@ARL.MIL> To: "Dennis G. Rears" <drears@pica.army.mil> Cc: mbone, rfd@pica.army.mil Subject: Re: Request for MBONE Tunnel feed request Message-Id: <9509080044.aa29292@ADMII.ARL.MIL> Dennis, DREN is providing MBONE service. I will get you set up on Friday with a feed from ARL. - Phil From list-mgr@ISI.EDU Thu Sep 7 21:27:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21062>; Thu, 7 Sep 1995 22:28:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AB21050>; Thu, 7 Sep 1995 22:27:47 -0700 Received: from turing.mathworks.com by venera.isi.edu (5.65c/5.61+local-22) id <AA21042>; Thu, 7 Sep 1995 22:27:45 -0700 Received: (pascoe@localhost) by turing.mathworks.com (8.6.11/8.6-dp) id BAA11662; Fri, 8 Sep 1995 01:27:44 -0400 Date: Fri, 8 Sep 1995 01:27:43 -0400 (EDT) From: Dave Pascoe <pascoe@mathworks.com> X-Sender: pascoe@turing To: mbone Subject: Multicast/Sol2.4/FDDI Message-Id: <Pine.SUN.3.91.950908012213.7737K-100000@turing> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We brought up a SPARCstation 10 (running Solaris 2.4) on FDDI (using Sun FDDI card, FDDI/S 3.0.1). Router on the subnet is a Cisco AGS+ running 10.2(7), running PIM (ip pim dense-mode) on several Ethernet interfaces, as well as the FDDI interface. Cisco has a tunnel to our MBone router. I'm not seeing anything at all from the outside world on the FDDI-attached workstation. On an identical but Ethernet-attached machine, everything is fine. Any ideas? Is this a known problem? Thanks in advance.... Dave Pascoe pascoe@mathworks.com From list-mgr@ISI.EDU Thu Sep 7 23:14:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22250>; Thu, 7 Sep 1995 23:14:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22238>; Thu, 7 Sep 1995 23:14:11 -0700 Received: from nidhog.vtyh.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA22230>; Thu, 7 Sep 1995 23:14:08 -0700 Received: from technis.vtyh.fi (technis.vtyh.fi [192.98.22.5]) by nidhog.vtyh.fi (8.6.12/8.6.12) with ESMTP id JAA14155; Fri, 8 Sep 1995 09:11:52 +0300 Received: from TECHNIS/MERQUEUE by technis.vtyh.fi (Mercury 1.21); 8 Sep 95 09:12:48 +0200 Received: from MERQUEUE by TECHNIS (Mercury 1.21); 8 Sep 95 09:12:45 +0200 From: "Markus Lamminm{ki" <MARKUS@TECHNIS.VTYH.FI> X-Real-Sender: ROOT Organization: Vasa tekniska yrkesh|gskola To: Dave Pascoe <pascoe@mathworks.com>, mbone Date: Fri, 8 Sep 1995 09:12:43 EET+0200 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Multicast/Sol2.4/FDDI Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <36EEDEA71D5@technis.vtyh.fi> >We brought up a SPARCstation 10 (running Solaris 2.4) on FDDI (using Sun > >I'm not seeing anything at all from the outside world on the >FDDI-attached workstation. On an identical but Ethernet-attached >machine, everything is fine. > >Any ideas? Is this a known problem? Have you applied the kernel patches that can be found from: ftp://playground.sun.com/pub/multicast/patches There is also multicast 3.3 available from about the same directory. --- Vasa Polytechnic Email: markus@technis.vtyh.fi PB 6, FIN-65201, FINLAND Fax: +358-61-3230 610 Please, someone, make X.400 go away! Work:+358-61-3230 661 GSM: +358-50-5531 261 They are out there From list-mgr@ISI.EDU Thu Sep 7 22:25:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22462>; Thu, 7 Sep 1995 23:26:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22455>; Thu, 7 Sep 1995 23:25:41 -0700 Received: from turing.mathworks.com by venera.isi.edu (5.65c/5.61+local-22) id <AA22448>; Thu, 7 Sep 1995 23:25:39 -0700 Received: (pascoe@localhost) by turing.mathworks.com (8.6.11/8.6-dp) id CAA13412; Fri, 8 Sep 1995 02:25:36 -0400 Date: Fri, 8 Sep 1995 02:25:35 -0400 (EDT) From: Dave Pascoe <pascoe@mathworks.com> X-Sender: pascoe@turing To: Markus Lamminm{ki <MARKUS@TECHNIS.VTYH.FI> Cc: mbone Subject: Re: Multicast/Sol2.4/FDDI In-Reply-To: <36EEDEA71D5@technis.vtyh.fi> Message-Id: <Pine.SUN.3.91.950908022238.13095A-100000@turing> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 8 Sep 1995, Markus Lamminm{ki wrote: > >We brought up a SPARCstation 10 (running Solaris 2.4) on FDDI (using Sun Actually, it's a SPARC 20. I forgot when I originally wrote my note. > Have you applied the kernel patches that can be found from: > > ftp://playground.sun.com/pub/multicast/patches Yes....(the 101969-06 was obsoleted by a later patch which was already installed and the 101970-06 patch doesn't apply since the package is not installed). > There is also multicast 3.3 available from about the same directory. Will take a look.....this isn't a problem on ethernet-connected machines, just the one FDDI-connected machine. Dave From list-mgr@ISI.EDU Fri Sep 8 13:59:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25008>; Fri, 8 Sep 1995 01:00:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24991>; Fri, 8 Sep 1995 00:58:50 -0700 Received: from blues.ml.tele.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA24982>; Fri, 8 Sep 1995 00:58:46 -0700 Received: (from mit@localhost) by blues.ml.tele.fi (8.6.12/8.6.12) id KAA17781; Fri, 8 Sep 1995 10:59:08 +0300 Date: Fri, 8 Sep 1995 10:59:08 +0300 From: Mikko Tsokkinen <mit@ml.tele.fi> Message-Id: <199509080759.KAA17781@blues.ml.tele.fi> To: Dave Pascoe <pascoe@mathworks.com> Cc: Markus Lamminm{ki <MARKUS@TECHNIS.VTYH.FI>, mbone Subject: Re: Multicast/Sol2.4/FDDI In-Reply-To: <Pine.SUN.3.91.950908022238.13095A-100000@turing> References: <36EEDEA71D5@technis.vtyh.fi> <Pine.SUN.3.91.950908022238.13095A-100000@turing> Dave Pascoe writes: > > Will take a look.....this isn't a problem on ethernet-connected machines, > just the one FDDI-connected machine. I have had lots of problems with Solaris workstations with default interface other than le0. These problems have been evident with several ATM and FDDI adapters. If you run mrouted on all machines with default interface other than le0, despite the fact that the traffic should reach the station anyway it usually works fine. Other solution is to change the default interface. Mikko I. Tsokkinen xxxxx Mit <Mikko.Tsokkinen@tele.fi> R & D Engineer Telecom Finland Ltd./Telegate/Medialaboratory From list-mgr@ISI.EDU Tue Sep 8 13:53:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26403>; Fri, 8 Sep 1995 01:52:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26396>; Fri, 8 Sep 1995 01:51:47 -0700 Received: from milpitas.adaptec.com by venera.isi.edu (5.65c/5.61+local-22) id <AA26389>; Fri, 8 Sep 1995 01:51:46 -0700 Received: from corpmail.adaptec.com ([162.62.105.19]) by milpitas.adaptec.com (4.1/SMI-4.1) id AA16308; Fri, 8 Sep 95 01:51:23 PDT Received: from by corpmail.adaptec.com (4.1/SMI-4.1) id AB25438; Fri, 8 Sep 95 01:37:08 PDT X-Nvlenv-01Date-Transferred: 8-Sep-1995 1:58:06 -0400; at Mentor.Adaptec X-Nvlenv-01Date-Posted: 08-Sep-1995 17:54:25 -0400; at AJL.Adaptec Date: 08 Sep 95 17:53:00 EDT From: TMatsumu@Asia.adaptec.com Subject: Re: Multicast/Sol2.4/FDDI Message-Id: <58955030016B1673@-SMF-> In-Reply-To: <199509080759.KAA17781@blues.ml.tele.fi> Reply-To: TMatsumu@Asia.adaptec.com References: <36EEDEA71D5@technis.vtyh.fi> To: pascoe@mathworks.com Adaptec's ATM Sbus cards work fine, with or without le0 enabled. To run ATM alone with an Adaptec ATM Sbus NIC, just rename hostname.le0 to hostname.bak, then cd to: cd /etc/opt/ADPTaatm/bin and run: aatmcnfg, then acipcnfg and you will be running IP over ATM (faster than FDDI, Ethernet 10/100/VG) with your device of acip0 having hostname and ip address as defined in /etc/hosts Ted ------------- Original Text From mit@ml.tele.fi (Mikko Tsokkinen), on 9/8/95 10:59 AM: Dave Pascoe writes: > > Will take a look.....this isn't a problem on ethernet-connected machines, > just the one FDDI-connected machine. I have had lots of problems with Solaris workstations with default interface other than le0. These problems have been evident with several ATM and FDDI adapters. If you run mrouted on all machines with default interface other than le0, despite the fact that the traffic should reach the station anyway it usually works fine. Other solution is to change the default interface. Mikko I. Tsokkinen xxxxx Mit <Mikko.Tsokkinen@tele.fi> R & D Engineer Telecom Finland Ltd./Telegate/Medialaboratory From list-mgr@ISI.EDU Fri Sep 8 05:16:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01805>; Fri, 8 Sep 1995 07:54:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29861>; Fri, 8 Sep 1995 06:17:35 -0700 Received: from stealth.sprintlink.net by venera.isi.edu (5.65c/5.61+local-22) id <AA29854>; Fri, 8 Sep 1995 06:17:33 -0700 Received: (from rmartin@localhost) by stealth.sprintlink.net (8.6.10/8.6.9) id JAA06188; Fri, 8 Sep 1995 09:16:02 -0400 Date: Fri, 8 Sep 1995 09:16:01 -0400 (EDT) From: Richard Martin <rmartin@sprint.net> To: Bill Fenner <fenner@parc.xerox.com> Cc: MBONE administrator <mbone@netcom.com>, mbone Subject: Re: #### MBONE topology bugs ##### In-Reply-To: <95Sep7.123814pdt.177475@crevenia.parc.xerox.com> Message-Id: <Pine.SUN.3.91.950908085052.15738f-100000@stealth.sprintlink.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Richard Martin Sprintlink Systems & Services On Thu, 7 Sep 1995, Bill Fenner wrote: > In message <199509071833.LAA07390@noc.netcom.net> you write: > >We (NETCOM) have very good West Coast connectivity, and would be willing to > >tunnel to several other good MBONE sites, over the CA NAP, CIX SMDS, or > >MAE-WEST. (CA NAP preferred). > > The current path to Netcom goes via dc-mbone-1.sprintlink.net, which has *30* > tunnels. I don't know what kind of machine dc-mbone-1.sprintlink.net is, and > I don't know what kind of LAN it is attached to, but note that at the nominal > MBONE bandwidth (500kbps) this is 15Mbps. dc-mbone-1 is overloaded, its on its own ethernet and only about 15-20 customers ever have their tunnels up, but it is not is good shape. > > Unfortunately, it is running mrouted 2.2, meaning that you can't even make any > loss measurements through it; maybe it's a really fast machine on a really > fast network and can handle all of these tunnels. However, without mtrace, I > can't tell, meaning that I have to assume that it's bad. > > I wouldn't want to suggest creating a low-metric cross-country path that > crosses dc-mbone-1.sprintlink.net, which seems to be what hooking up Netcom on > the west coast would do. > I have another machine in dc (dc-mbone-2) which I just brought up a couple of weeks ago which is running 3.6.....its on a congested ethernet than will be replaced by a FDDI ring in the next couple of months. While we support mbone traffic in a very limited way right now, we do plan on major improvements over the next 6 months. Right now, we have 4 machines providing tunnels. dc-mbone-1.sprintlink.net (DC) dc-mbone-2.sprintlink.net (DC) ns2.sprintlink.net (Stockton, CA) ns1.nysernet.net (Pennsauken, NJ) Our 3-6 month plan includes: Replacing dc-mbone-1 with a machine running 3.x code Putting 2 mbone boxes in Stockton, CA one replace ns2.sprintlink.net's mbone functions Putting 2 mbone boxes in Pennsauken, NJ, one will replace ns1.nysernet.net Putting 1 mbone box in Fort Worth, TX Putting 1 mbone box in Chicago That will give us 6 boxes scattered accross the country, all will be on FDDI rings and all will run 3.x code. I would really like to "do the right thing" with these machines, so I will be looking to this list for suggestions. We have tunnels to outside of Sprintlink to ANS, Netcom and UUNET (as well as a few other smaller places) but I'm willing to do whatever makes sense. :-) Rich Martin > Bill > > From list-mgr@ISI.EDU Mon Sep 11 16:02:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28475>; Mon, 11 Sep 1995 07:14:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28380>; Mon, 11 Sep 1995 07:09:59 -0700 Received: from pimac2.iet.unipi.it by venera.isi.edu (5.65c/5.61+local-22) id <AA28247>; Mon, 11 Sep 1995 07:05:22 -0700 Received: by pimac2.iet.unipi.it (5.57/Ultrix3.0-C) id AA09295; Mon, 11 Sep 95 16:04:56 +0200 Message-Id: <9509111404.AA09295@pimac2.iet.unipi.it> X-Sender: stefano@radar.iet.unipi.it Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Sep 1995 16:02:32 +0000 To: mbone From: giordano@pimac2.iet.unipi.it (Stefano Giordano) Subject: MBONE tools over HP Workstations X-Mailer: <PC Eudora Version 1.4> Dear MBONErs, I'd like to know if someone is using the MBONE tools over hi-end HP workstation such as 9000/735. In this case I would like to know which kind of VIDEO (acquisition) board is recommended. Usually we have news about mluticast routing performed by HP workstations or RECEIVING tools such as VIC, NV, IVS. We would like to know if the are tools which can SEND VOICE And VIDEO from an HP workstation. So far we have used INDY workstations for this task. Are there any MPEG or H.261 hardware coder for the HP workstations?? Thank you in advance for any help Stefano ---------------------------------------------------------------------- X ... X X e-mail giordano@iet.unipi.it (o o) Stefano Giordano X X TEL. +39 50 568539 ... v ... X X FAX +39 50 568522 .. .. University of Pisa X X ..... Department of X X TELECOMMUNICATIONS GROUP **^*^** Information Engineering X X Via Diotisalvi 2 X X TLC NETWORKS 56126 PISA X X http://www_tlc.iet.unipi.it ITALY X ---------------------------------------------------------------------- From list-mgr@ISI.EDU Mon Sep 11 06:22:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16831>; Mon, 11 Sep 1995 13:22:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16797>; Mon, 11 Sep 1995 13:20:58 -0700 Received: from mercury.Sun.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA16788>; Mon, 11 Sep 1995 13:20:56 -0700 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id NAA08202; Mon, 11 Sep 1995 13:20:49 -0700 Received: from jurassic.Eng.Sun.COM (jurassic-52.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04198; Mon, 11 Sep 1995 13:20:46 -0700 Received: from offshore.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id NAA28419; Mon, 11 Sep 1995 13:20:44 -0700 Received: by offshore.Eng.Sun.COM (5.x/SMI-SVR4) id AA16510; Mon, 11 Sep 1995 13:22:53 -0700 Date: Mon, 11 Sep 1995 13:22:53 -0700 From: Allyn.Romanow@Eng.Sun.COM (Allyn Romanow) Message-Id: <9509112022.AA16510@offshore.Eng.Sun.COM> To: mbone Subject: new mrouted3.3/3.4 for Solaris 2.4 X-Sun-Charset: US-ASCII In porting multicast 3.6, I found a bug in the mrouted distributed with multicast 3.3 for Solaris 2.4. This is likely to cause problems when talking to other versions of mrouted, so please make the change. In playground.sun.com:/pub/multicast there's a README_mrouted_only and a tarfile mrouted3.4.tar.Z. You just need to replace new versions of the compiled programs in /usr/multicast. (Of course the entire multicast 3.4 tarfile has been updated - so if you pick it up after this note, you don't need to do anything special.) From list-mgr@ISI.EDU Tue Sep 12 18:54:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24419>; Mon, 11 Sep 1995 16:00:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24105>; Mon, 11 Sep 1995 15:55:07 -0700 Received: from shark.mel.dit.CSIRO.AU by venera.isi.edu (5.65c/5.61+local-22) id <AA24093>; Mon, 11 Sep 1995 15:55:03 -0700 Received: from koel.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA15796 (5.65c/IDA-1.4.4/DIT-1.3); Tue, 12 Sep 1995 08:54:39 +1000 Message-Id: <199509112254.AA15796@shark.mel.dit.csiro.au> To: mobile-ip@tadpole.com, mbone, big-internet@munnari.oz.au Cc: postel Subject: Standardizing IPIP usage. Date: Tue, 12 Sep 1995 08:54:39 +1000 From: Bob Smart <smart@mel.dit.csiro.au> IP encapsulation is being used or proposed for: - experimental protocols, notably multicast and IPng experiments. - mobile IP. - improving the scalability of the Internet. - full packet encryption for ESP. [This uses the protocol code for IPIP but no IPIP packet need be created. However if there is a working IPIP subsystem then blindly copying the protocol field and sending the packet back to the IP subsystem will work.] Perhaps the time has come to think about how IPIP should be implemented in hosts and routers to a. Ensure that all these applications co-operate. b. Address the extra security problems associated with IPIP. Maybe there is already work on this. If so then let me know. If not then read on. One of the security risks is that users will use IPIP to sneak in protocols that Network Managers don't trust. At the moment we filter IPIP based on destination because we know that if it goes to a multicast tunnel then the tunnel will discard any non-multicast IPIP packets. More sophisticated filtering will be needed in the future if Network Managers are going to restrict IPIP to only some specific applications. At the end system there should to be a single point for incoming IPIP packets. [The alternative is a nit-style interface where, for example, the mobile and multicast systems both receive all the packets and discard the ones they don't want. This is much more error-prone: e.g. who sends "dest unreachable" for packets which are discarded by both?] Incoming packets need to be filtered before being decapsulated and dropped into the IP subsystem. Machines which are not meant to be routers should only accept packets meant for themselves. It is also quite likely that some machines should only forward certain types of packets: perhaps only multicast or perhaps only certain mobile destinations. Perhaps the kernels need to be enhanced so that IP forwarding is not just an on/off thing, or perhaps this check needs to be done in the IPIP filter. The filtering of incoming packets needs to look at the degree of authentication of the packet and of the encapsulated packet. For the encapsulated packet this will probably be the AH authentication. For the outer packet this could be the AH authentication or could just be that it comes from a local machine and the combination of router filtering and physical security gives you confidence in packets from that machine. At any rate the normal rule for filtering needs to be: accept packets for protocols which are harmless or which come from trusted hosts with appropriate authentication. There may not be any need for a unified system for outgoing encapsulated packets. Each subsystem that wants to do encapsulation can have its own code to do it, presumably in what seems to the IP system to be an interface. However having a unified output path for encapsulations would avoid some code duplication, for example in fragmentation. One of the options we should be able to specify is fragmentation behaviour. The "IP within IP" Internet Draft from the Mobile-IP group (ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-ip4inip4-00.txt) says the "don't fragment" bit should be copied from the inner packet. However it is highly desirable for the sender to do MTU discovery and then pre-fragment the inner packet so that the outer packet won't need to be fragmented. One can imagine situations where the destination in the outer packet is an anycast address (i.e. there are various routers which will accept that address as their own and decapsulate and forward the packet) in which case it is essential that the "don't fragment" bit be set on the outer packet because the fragments might otherwise arrive at different routers. --------------------------------------------------------------------------- Is all this is obvious? Or would it be useful to have some standards or at least an informational RFC about it? Bob Smart Robert.Smart@dit.csiro.au Network Services Group CSIRO Division of Information Technology phone: +61 3 9282 2625 723 Swanston St, Carlton VIC 3053, Australia fax: +61 3 9282 2600 P.S. Jon Postel is in the Cc list because he is listed in the Assigned Numbers RFC (1700) as the owner of the IPIP protocol number. From list-mgr@ISI.EDU Mon Sep 11 09:43:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25936>; Mon, 11 Sep 1995 16:42:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25927>; Mon, 11 Sep 1995 16:41:53 -0700 Received: from mercury.Sun.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA25920>; Mon, 11 Sep 1995 16:41:52 -0700 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id QAA01072; Mon, 11 Sep 1995 16:41:50 -0700 Received: from jurassic.Eng.Sun.COM (jurassic-52.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09734; Mon, 11 Sep 1995 16:41:44 -0700 Received: from offshore.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id QAA11023; Mon, 11 Sep 1995 16:41:40 -0700 Received: by offshore.Eng.Sun.COM (5.x/SMI-SVR4) id AA16921; Mon, 11 Sep 1995 16:43:49 -0700 Date: Mon, 11 Sep 1995 16:43:49 -0700 From: Allyn.Romanow@Eng.Sun.COM (Allyn Romanow) Message-Id: <9509112343.AA16921@offshore.Eng.Sun.COM> To: mbone Subject: mrouted 3.4 for Solaris2.4 X-Sun-Charset: US-ASCII If you've already picked up the new version today after I sent the last message, read on, otherwise, skip it. After putting out the last message, I got some more patches for mrouted 3.4, they are relevant for Intel machines. I've just updated the files on playground. sorry for the inconvenience if you've already grabbed them- From list-mgr@ISI.EDU Mon Sep 11 10:41:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29503>; Mon, 11 Sep 1995 17:44:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29137>; Mon, 11 Sep 1995 17:41:47 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA29130>; Mon, 11 Sep 1995 17:41:44 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id RAA23462; Mon, 11 Sep 1995 17:41:04 -0700 Date: Mon, 11 Sep 1995 17:41:04 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199509120041.RAA23462@greatdane.cisco.com> To: mobile-ip@Tadpole.COM Cc: mobile-ip@Tadpole.COM, mbone, big-internet@munnari.oz.au, postel In-Reply-To: <199509112254.AA15796@shark.mel.dit.csiro.au> (message from Bob Smart on Tue, 12 Sep 1995 08:54:39 +1000) Subject: Re: (mobile-ip) Standardizing IPIP usage. Perhaps the time has come to think about how IPIP should be implemented in hosts and routers Little late... We shipped it quite a while ago. ;-) a. Ensure that all these applications co-operate. b. Address the extra security problems associated with IPIP. Maybe there is already work on this. If so then let me know. If not then read on. One of the security risks is that users will use IPIP to sneak in protocols that Network Managers don't trust. At the moment we filter IPIP based on destination because we know that if it goes to a multicast tunnel then the tunnel will discard any non-multicast IPIP packets. More sophisticated filtering will be needed in the future if Network Managers are going to restrict IPIP to only some specific applications. One might do this by terminating the tunnel in a box and then filtering the output of the tunnel. Already shipped. ;-) At the end system there should to be a single point for incoming IPIP packets. [The alternative is a nit-style interface where, for example, the mobile and multicast systems both receive all the packets and discard the ones they don't want. This is much more error-prone: e.g. who sends "dest unreachable" for packets which are discarded by both?] Isn't this an implementation issue? One of the options we should be able to specify is fragmentation behaviour. The "IP within IP" Internet Draft from the Mobile-IP group (ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-ip4inip4-00.txt) says the "don't fragment" bit should be copied from the inner packet. However it is highly desirable for the sender to do MTU discovery and then pre-fragment the inner packet so that the outer packet won't need to be fragmented. I don't see these as being in conflict. If the host sets the DF bit, it's presumably doing MTU discovery. If it's a legacy host, then things still work. One can imagine situations where the destination in the outer packet is an anycast address (i.e. there are various routers which will accept that address as their own and decapsulate and forward the packet) in which case it is essential that the "don't fragment" bit be set on the outer packet because the fragments might otherwise arrive at different routers. While there's no true anycast in IPv4, yes that would be a problem. This seems sufficiently obscure that it could become text in the existing draft. Tony From list-mgr@ISI.EDU Tue Sep 12 20:03:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06364>; Mon, 11 Sep 1995 19:07:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06198>; Mon, 11 Sep 1995 19:04:34 -0700 Received: from camis.kaist.ac.kr by venera.isi.edu (5.65c/5.61+local-22) id <AA06191>; Mon, 11 Sep 1995 19:04:22 -0700 Received: (from jwjung@localhost) by camis.kaist.ac.kr (8.6.12H1/8.6.9) id LAA05053 for mbone@isi.edu; Tue, 12 Sep 1995 11:03:34 +0900 From: Jung Joowon <jwjung@camis.kaist.ac.kr> Message-Id: <199509120203.LAA05053@camis.kaist.ac.kr> Subject: [Q] MBONE through satellite To: mbone Date: Tue, 12 Sep 1995 11:03:33 +0900 (JST) X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 512 Does anyone tried MBONE connection through satellite channel? If someone decide to connect internet through satellite, how can he realize it with current technology, and what will be the major problems? Thanks in advance... -Jung Joowon -- Jung Joowon | E-mail: jwjung@camis.kaist.ac.kr Center for Adv. Management Info. System | Phone(Office): +82-42-869-8321~4 Korea Advanced Inst. of Sci. and Tech. | Fax : +82-42-869-8330 Taejon, Republic of Korea, 305-701 | http://camis.kaist.ac.kr/~jwjung/ From list-mgr@ISI.EDU Tue Sep 12 20:43:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07601>; Mon, 11 Sep 1995 19:48:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07406>; Mon, 11 Sep 1995 19:44:01 -0700 Received: from camis.kaist.ac.kr by venera.isi.edu (5.65c/5.61+local-22) id <AA07391>; Mon, 11 Sep 1995 19:43:34 -0700 Received: (from jwjung@localhost) by camis.kaist.ac.kr (8.6.12H1/8.6.9) id LAA05828; Tue, 12 Sep 1995 11:43:21 +0900 From: Jung Joowon <jwjung@camis.kaist.ac.kr> Message-Id: <199509120243.LAA05828@camis.kaist.ac.kr> Subject: Re: [Q] MBONE through satellite To: whchoi@cosmos.kaist.ac.kr (Woohyung Choi) Date: Tue, 12 Sep 1995 11:43:21 +0900 (JST) Cc: mbone In-Reply-To: <199509122008.LAA16285@violet.kaist.ac.kr> from "Woohyung Choi" at Sep 12, 95 11:08:16 am X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 804 > > delay! sat. channel has a lot longer delay than the cable. > > -whchoi > OK... delay concerns... Then, my next question is... Would the delay be tolerable if someone were to open an MBONE conference through satellite? How much would be the delay in physical measure (like mili-seconds or seconds)? (Provided that the satellite is NOT an inter-continental. I imagine (consider?) the satellite that connects Korea, middle of Japan and south east of Mainland China) Thank you for your future response! :) -Jung Joowon -- Jung Joowon | E-mail: jwjung@camis.kaist.ac.kr Center for Adv. Management Info. System | Phone(Office): +82-42-869-8321~4 Korea Advanced Inst. of Sci. and Tech. | Fax : +82-42-869-8330 Taejon, Republic of Korea, 305-701 | http://baram.kaist.ac.kr/~jwjung/ From list-mgr@ISI.EDU Mon Sep 11 20:12:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09961>; Mon, 11 Sep 1995 21:13:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09937>; Mon, 11 Sep 1995 21:12:17 -0700 Received: from iag.net (seminole.iag.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA09930>; Mon, 11 Sep 1995 21:12:16 -0700 Received: by iag.net (Smail3.1.29.1 #9) id m0ssMhi-000077C; Tue, 12 Sep 95 00:12 EDT Date: Tue, 12 Sep 1995 00:12:14 -0400 (EDT) From: Constantine Krekos <krekos@seminole.iag.net> To: mbone Subject: unsubscribe Message-Id: <Pine.SV4.3.91.950912001141.26851D-100000@seminole.iag.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From list-mgr@ISI.EDU Mon Sep 11 21:44:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12577>; Mon, 11 Sep 1995 22:51:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12567>; Mon, 11 Sep 1995 22:50:58 -0700 Received: from loki.oar.net by venera.isi.edu (5.65c/5.61+local-22) id <AA12560>; Mon, 11 Sep 1995 22:50:54 -0700 Received: for welch@oar.net by loki.oar.net (8.6.10/931123.1402) id BAA23286; Tue, 12 Sep 1995 01:44:35 -0400 From: Arun Welch <welch@oar.net> Message-Id: <199509120544.BAA23286@loki.oar.net> Subject: Re: [Q] MBONE through satellite To: jwjung@camis.kaist.ac.kr (Jung Joowon) Date: Tue, 12 Sep 1995 01:44:34 -0400 (EDT) Cc: whchoi@cosmos.kaist.ac.kr, mbone In-Reply-To: <199509120243.LAA05828@camis.kaist.ac.kr> from "Jung Joowon" at Sep 12, 95 11:43:21 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1050 > > delay! sat. channel has a lot longer delay than the cable. > > > > OK... delay concerns... > Then, my next question is... > > Would the delay be tolerable if someone were to open an MBONE > conference through satellite? How much would be the delay in > physical measure (like mili-seconds or seconds)? (Provided that > the satellite is NOT an inter-continental. > Satellites are situated at a point that continental concerns don't enter into it, it's the up-and-down that matters. For a geosynchronous satellite the delay time will be around 540ms, depending on the speed of the switching matrix in the bird. Over the ACTS I'm getting: OSCA% ping 192.157.4.33 PING 192.157.4.33: 56 data bytes 64 bytes from 192.157.4.33: icmp_seq=0. time=539. ms 64 bytes from 192.157.4.33: icmp_seq=1. time=538. ms 64 bytes from 192.157.4.33: icmp_seq=2. time=540. ms ...arun --------------------------------------------------------------------------- Arun Welch 2455 Northstar Rd Network Engineer Columbus, OH 43221 OARnet welch@oar.net From list-mgr@ISI.EDU Mon Sep 11 17:13:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18215>; Tue, 12 Sep 1995 02:19:15 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA18205>; Tue, 12 Sep 1995 02:19:07 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA10558>; Tue, 12 Sep 1995 02:18:45 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.18996-0@bells.cs.ucl.ac.uk>; Mon, 11 Sep 1995 16:14:06 +0100 From: Mark Handley <M.Handley@cs.ucl.ac.uk> Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: mbone-na Cc: M.Handley@cs.ucl.ac.uk, e93_mda@it.kth.se Subject: Mbone-na list Date: Mon, 11 Sep 95 16:13:56 +0100 Message-Id: <4344.810832436@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk We seem to be seeing a great deal of messages recently about local config problems and tunnel requests in the US. Could I make the suggestion that the mbone-na@isi.edu list is used for these mbone North America issues in the same way the mbone-eu is used for European mbone issues. The full mbone list is not intended for these local issues. Mark From list-mgr@ISI.EDU Tue Sep 12 00:58:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20894>; Tue, 12 Sep 1995 04:05:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20746>; Tue, 12 Sep 1995 04:02:10 -0700 Received: from css583.gordon.army.mil by venera.isi.edu (5.65c/5.61+local-22) id <AA20735>; Tue, 12 Sep 1995 04:02:04 -0700 Received: from wkst025.css.gordon.army.mil by host.css583.gordon.army.mil id aa05321; 12 Sep 95 6:53 EDT Date: Tue, 12 Sep 95 05:58:39 EST Message-Id: <9509120558.AA11880@WKST025.CSS.GORDON.ARMY.MIL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: ken simmons <simmonsn@css583.gordon.army.mil> Reply-To: L <simmonsn@css583.gordon.army.mil> X-Sender: <simmonsn@WKST025.CSS.GORDON.ARMY.MIL> To: mbone Subject: unsubscribe X-Mailer: <WS_Send v95.08.30> unsubscribe simmonsn@css583.css.gordon.army.mil From list-mgr@ISI.EDU Tue Sep 12 15:55:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21549>; Tue, 12 Sep 1995 04:56:39 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA21542>; Tue, 12 Sep 1995 04:56:35 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id NAA27931; Tue, 12 Sep 1995 13:55:30 +0200 Message-Id: <199509121155.NAA27931@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: Mark Handley <M.Handley@cs.ucl.ac.uk> Cc: mbone-na Subject: Re: Mbone-na list In-Reply-To: Your message of "Mon, 11 Sep 1995 16:13:56 BST." <4344.810832436@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Sep 1995 13:55:37 +0200 From: Magnus <e93_mda@it.kth.se> > > We seem to be seeing a great deal of messages recently about local > config problems and tunnel requests in the US. Could I make the > suggestion that the mbone-na@isi.edu list is used for these mbone > North America issues in the same way the mbone-eu is used for European > mbone issues. The full mbone list is not intended for these local > issues. > > Mark > Mark, and all Mbone NA people, I think it is time that we separate these operational issues from the Mbone list. Here in Europe we have created an list especially for those issues, and I would like to see the same thing happening in the NA. Since the mbone-na@isi.edu is a fan-out list of mbone@isi.edu will I not recive any mail within that boundary, even if they would be of my concern. This makes the mbone-na@isi.edu list inappropriate for these discussions. Could someone create this mbone-na-op list so we could have an operational list for the NA? I think it is needed. To anyone replying... CC me... I doesn't get the mbone-na@isi.edu mails!!! Magnus From list-mgr@ISI.EDU Tue Sep 12 07:59:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29874>; Tue, 12 Sep 1995 09:03:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29482>; Tue, 12 Sep 1995 08:59:12 -0700 Received: from cne.gmu.edu ([199.26.254.1]) by venera.isi.edu (5.65c/5.61+local-22) id <AA29475>; Tue, 12 Sep 1995 08:59:11 -0700 Received: by cne.gmu.edu (4.1/SMI-4.1) id AA13245; Tue, 12 Sep 95 11:59:03 EDT Date: Tue, 12 Sep 95 11:59:03 EDT From: mpullen@cne.gmu.edu (Mark Pullen) Message-Id: <9509121559.AA13245@cne.gmu.edu> To: mbone Subject: Planned MBONE sessions 27/28 September Cc: mpullen@cne.gmu.edu, mbenson@cne.gmu.edu, llavu@osf1.gmu.edu We are planning the following MBONE session: 1. Contents: Computer Aided Education and Training Initiative/Collaborative Applications for Project- Based Learning Resources (CAETI/CAPER), group meeting at George Mason University. 2. Session name: CAPER 3. Media: vat, nv, wb 4. Bandwidth: 128kbps 5. Begins at: 1995/09/27 1300UTC (=0900EDT) 6. Ends at: 1995/09/28 1600UTC (=1200EDT) 7. Initial TTL: 50 8. Contact: L Lavu, George Mason University C3 Center 9. Email address: llavu@osf1.gmu.edu Mark Pullen <mpullen@gmu.edu> GMU C3I Center From list-mgr@ISI.EDU Tue Sep 12 03:50:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05643>; Tue, 12 Sep 1995 10:54:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05369>; Tue, 12 Sep 1995 10:51:03 -0700 Received: from precept.com (hydra.precept.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA05361>; Tue, 12 Sep 1995 10:51:00 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA12584; Tue, 12 Sep 1995 10:50:59 -0700 Date: Tue, 12 Sep 1995 10:50:59 -0700 (PDT) From: Stephen Casner <casner@precept.com> To: mbone Subject: Re: Mbone-na list In-Reply-To: <199509121155.NAA27931@piraya.electrum.kth.se> Message-Id: <Pine.SOL.3.91.950912104837.19637B-100000@little-bear.precept.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm widening this reply to the full MBone list... Mark Handley <M.Handley@cs.ucl.ac.uk> wrote: > We seem to be seeing a great deal of messages recently about local > config problems and tunnel requests in the US. Could I make the > suggestion that the mbone-na@isi.edu list is used for these mbone > North America issues in the same way the mbone-eu is used for European > mbone issues. The full mbone list is not intended for these local > issues. Mark is right that the mbone-na list is not used in preference to the full mbone list as much as it should be. In particular, requests for tunnel connections between sites and providers in the US need not go to Europe. In fact, the situation has changed some since the early days of the MBone. Most new connection are not between two end sites that agree to set up a tunnel, but between a site and their (unicast) network service provider. So, the best first course is for a site to contact their provider directly. There are some configuration issues which, while located in the US, impact much of the MBone because they involve connection points for international tunnels. Those should rightly continue to go to the full list. Magnus <e93_mda@it.kth.se> wrote: > Mark, and all Mbone NA people, I think it is time that we separate > these operational issues from the Mbone list. Here in Europe we have > created an list especially for those issues, and I would like to see > the same thing happening in the NA. Since the mbone-na@isi.edu is a > fan-out list of mbone@isi.edu will I not recive any mail within that > boundary, even if they would be of my concern. This makes the > mbone-na@isi.edu list inappropriate for these discussions. > > Could someone create this mbone-na-op list so we could have an > operational list for the NA? I think it is needed. Actually, I would not want an mbone-na-op list to be created. I am somewhat disturbed by the creation of the mbone-eu-op list. I can understand the motivation, but the problem is that the description Erik-Jan gave for the new list is exactly what the mbone list and its sublists are intended for! The problem with any mailing list is keeping the focus and avoiding noise. I have attempted to encourage that by sending messages like this one from time to time, but also by putting the following statement in the canned message returned by mbone-request@isi.edu: The mbone list is primarily intended for people who operate multicast router nodes on the MBONE, the Multicast Backbone. It is used to announce new releases of multicast kernel and mrouted software, to discuss problems observed with that software, and to coordinate changes in the topology of the MBONE. If are an end user of application programs on the MBONE but you don't operate a multicast router node, the rem-conf list may be more appropriate for you (send a message to rem-conf-request@es.net to join.) Schedules for events on the MBONE and new releases of application programs are announced there in addition to general discussion of remote conferencing issues. We did not attempt to define some admission test beyond this suggestion because that seems impractical, not to mention authoritarian. The list is a hierarchy of exploders each managed separately. Since the mbone-eu-op list is managed automatically by majordomo, there won't be any admission test there, either. That list will grow noise, too, and now there is the additional complication that a person in Europe preparing to send a message needs to decide whether mbone-eu or mbone-eu-op is the right one. Maybe the only solution is to create new lists periodically and let old ones die, but that creates an awful lot of confusion and administrative burden. -- Steve From list-mgr@ISI.EDU Tue Sep 12 10:35:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08015>; Tue, 12 Sep 1995 11:41:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07848>; Tue, 12 Sep 1995 11:40:28 -0700 Received: from maelstrom.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA07837>; Tue, 12 Sep 1995 11:40:22 -0700 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.6.10/8.6.6) id OAA01408 for mbone@isi.edu; Tue, 12 Sep 1995 14:35:50 -0400 Message-Id: <199509121835.OAA01408@maelstrom.cc.mcgill.ca> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Yves Lepage <yves@CC.McGill.CA> Date: Tue, 12 Sep 95 14:35:48 -0400 To: mbone Subject: Mrouted 3.4 problem Reply-To: yves@cc.mcgill.ca Hello, Here are a few warning/error messages I get when my mrouted 3.4 is running on my FreeBSD 2.0.5 machine: Sep 9 05:24:39 tempest mrouted[18776]: warning - prune message received incorrectly I assume this one is because not all mrouted to which I talk are >=3.0 Am I right? or is there a version of mrouted that will give me such results? Sep 9 06:47:28 tempest mrouted[18776]: warning - sendto to 192.26.210.1 on 132.206.35.8: No buffer space available Sep 9 06:47:28 tempest mrouted[18776]: warning - sendto to 132.206.1.5 on 132.206.35.8: No buffer space available Is there a way to increase buffer space? My machine has 48MB and a 1GB disk on which 500MB are free. Sep 3 03:55:05 tempest mrouted[148]: warning - received packet shorter (37 bytes) than hdr+data length (20+16) I assume this one is harmless, since it is just a warning.... Sep 2 10:35:00 tempest mrouted[20484]: mrouted version 3.4 Sep 2 10:35:00 tempest mrouted[20484]: can't enable DVMRP routing in kernel: Address already in use Here, my mrouted had just mysteriously crashed (during a test between a friend at UNB (canada) and some people in the States (Bill Fenner was one of them)), my restart script that runs every minute restarted it so mrouted was down for no longer than one minute. I assume the timeout value for a port address with FreeBSD is more than one minute, I'll try making my script sleep for 2 minutes before restarting mrouted. If there are FreeBSD experts here, will that solve the problem? (thanks god I don't run my mrouted on a solaris machine). Aug 30 15:43:23 tempest mrouted[24056]: warning - setsockopt DVMRP_DEL_MFC: No such process This ones rings no bell.... any idea? My last question is: has 3.6 (or at least 3.5) been ported to FreeBSD? Thanks for the help. Yves Lepage yves@cc.mcgill.ca From list-mgr@ISI.EDU Tue Sep 12 05:37:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10761>; Tue, 12 Sep 1995 12:43:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10639>; Tue, 12 Sep 1995 12:38:06 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA10630>; Tue, 12 Sep 1995 12:38:04 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15962(1)>; Tue, 12 Sep 1995 12:37:49 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Tue, 12 Sep 1995 12:37:45 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: yves@cc.mcgill.ca Cc: mbone Subject: Re: Mrouted 3.4 problem In-Reply-To: Your message of "Tue, 12 Sep 95 11:35:48 PDT." <199509121835.OAA01408@maelstrom.cc.mcgill.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Sep 1995 12:37:36 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Sep12.123745pdt.177475@crevenia.parc.xerox.com> In message <199509121835.OAA01408@maelstrom.cc.mcgill.ca> you write: >Sep 9 05:24:39 tempest mrouted[18776]: warning - prune message received incor > rectly This means that mrouted got a prune for a source and group that it didn't have an active forwarding entry. This is a bad error message, it should log the source and group (3.6 does). >Sep 9 06:47:28 tempest mrouted[18776]: warning - sendto to 192.26.210.1 on >132.206.35.8: No buffer space available >Sep 9 06:47:28 tempest mrouted[18776]: warning - sendto to 132.206.1.5 on >132.206.35.8: No buffer space available mrouted uses the default buffer size for its sends. Perhaps it should increase that buffer size as well. >Sep 3 03:55:05 tempest mrouted[148]: warning - received packet shorter (37 >bytes) than hdr+data length (20+16) > >I assume this one is harmless, since it is just a warning.... Harmless but unexplainable... >Sep 2 10:35:00 tempest mrouted[20484]: mrouted version 3.4 >Sep 2 10:35:00 tempest mrouted[20484]: can't enable DVMRP routing in kernel: >Address already in use > >my restart script that runs every minute restarted it so mrouted was down for >no longer than one minute. If mrouted gets killed, it spends a little bit of time telling its neighbors that it is going down. The sequence "kill `cat /var/run/mrouted.pid`; mrouted" will probably elicit this message, since the new mrouted will try to start before the old one is finished exiting. There is no timeout at all for the multicast router (which is what this Address already in use message refers to); it is directly linked to whether or not mrouted is running. >Aug 30 15:43:23 tempest mrouted[24056]: warning - setsockopt DVMRP_DEL_MFC: >No such process > >This ones rings no bell.... any idea? This is a kernel<>user space synchronization problem; probably a 3.4 bug. >My last question is: has 3.6 (or at least 3.5) been ported to FreeBSD? 3.6 has been in -current for some time; it has been imported into -stable as well. Bill From list-mgr@ISI.EDU Wed Sep 13 01:00:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14250>; Tue, 12 Sep 1995 14:01:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14166>; Tue, 12 Sep 1995 14:00:48 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA14158>; Tue, 12 Sep 1995 14:00:43 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id XAA04268; Tue, 12 Sep 1995 23:00:00 +0200 Message-Id: <199509122100.XAA04268@piraya.electrum.kth.se> To: Stephen Casner <casner@precept.com> Cc: mbone, e93_mda@it.kth.se Subject: Re: Mbone-na list In-Reply-To: Your message of "Tue, 12 Sep 1995 10:50:59 PDT." <Pine.SOL.3.91.950912104837.19637B-100000@little-bear.precept.com> Date: Tue, 12 Sep 1995 23:00:12 +0200 From: Magnus <e93_mda@it.kth.se> Hi again! I agree that the mbone@isi.edu list should be used for that kind of operational issues, however, I also see the need of having a list for these more general questions. I think that the mbone list is a good medium for it, since it is after all used for that purpose most of the time. I disagree that the new lists would become noisy, since having a charter that everyone gets when signing up as well as having people wining about mails which does not comply with that charter will help avoiding to much noise. I think we need a separate list for the noise, so either we clean up the big list (mbone@isi.edu and it's fan-out lists), or we create new lists and keep them clean. Take a pick.... but personaly I prefer the later, since then we are in a better shape to cope with both global and local issues, and still allow people to get that info he feels he needs. We also needs the noisy channel but I think we would have a hard time learning people about the house rules that we just applied to the list... In any case you must not forget those people who needs the full insigth in several geographic domains. The current mbone list do not provide such a coverage unless the sender broadcast to the list, which bothers some people since they do not like the overhead, the proposed multicast scheme would allow for lower overhead for those connected but still allow for complete coverage. Magnus From list-mgr@ISI.EDU Tue Sep 12 09:03:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21360>; Tue, 12 Sep 1995 16:23:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21297>; Tue, 12 Sep 1995 16:21:45 -0700 Received: from phantom.cortland.com (www.ilsi.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA21289>; Tue, 12 Sep 1995 16:21:41 -0700 Message-Id: <199509122321.AA21289@venera.isi.edu> Received: from (rasa11.cortland.com) by phantom.cortland.com; Tue, 12 Sep 1995 16:12:08 -0700 Date: Tue, 12 Sep 95 16:03:12 -0700 From: ILSI <gene@ilsi.com> Organization: Internet List Services Inc. X-Mailer: Mozilla 1.1N (Windows; I; 16bit) Mime-Version: 1.0 To: mbone Subject: Take a look... Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, I found your homepage, really enjoyed it, and would like to use it in my database. Time permitting, please look at my homepage and let me know if you would like to be added to my resource. I have created this database to assist people who have, or want, homepages on the internet, or for people who want an off-line reference to the World Wide Web. If possible, would you place a link from your site to my homepage, or if you want to be included in this reference, please visit me at http://www.ilsi.com/ilsi5.html Thank you, Gene Internet List Services, Incorporated From list-mgr@ISI.EDU Tue Sep 12 11:09:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26972>; Tue, 12 Sep 1995 18:28:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26960>; Tue, 12 Sep 1995 18:27:44 -0700 Received: from phantom.cortland.com (www.ilsi.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA26953>; Tue, 12 Sep 1995 18:27:42 -0700 Message-Id: <199509130127.AA26953@venera.isi.edu> Received: from (rasa11.cortland.com) by phantom.cortland.com; Tue, 12 Sep 1995 18:18:09 -0700 Date: Tue, 12 Sep 95 18:09:13 -0700 From: ILSI <gene@ilsi.com> Organization: Internet List Services Inc. X-Mailer: Mozilla 1.1N (Windows; I; 16bit) Mime-Version: 1.0 To: mbone Subject: Take a look... Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, I found your homepage, really enjoyed it, and would like to use it in my database. Time permitting, please look at my homepage and let me know if you would like to be added to my resource. I have created this database to assist people who have, or want, homepages on the internet, or for people who want an off-line reference to the World Wide Web. If possible, would you place a link from your site to my homepage, or if you want to be included in this reference, please visit me at http://www.ilsi.com/ilsi5.html Thank you, Gene Internet List Services, Incorporated From list-mgr@ISI.EDU Wed Sep 13 14:02:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11044>; Wed, 13 Sep 1995 05:03:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11019>; Wed, 13 Sep 1995 05:02:46 -0700 Received: from gizmo.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA11010>; Wed, 13 Sep 1995 05:02:39 -0700 Received: from localhost (martin@localhost) by gizmo.lut.ac.uk (8.7.Beta.14/8.6.9) with SMTP id NAA00436; Wed, 13 Sep 1995 13:02:19 +0100 (BST) Message-Id: <199509131202.NAA00436@gizmo.lut.ac.uk> X-Mailer: exmh version 1.6.2 7/18/95 To: ILSI <gene@ilsi.com> Cc: mbone Subject: Re: Take a look... X-Uri: <URL:http://www.mrrl.lut.ac.uk/~martin> In-Reply-To: Your message of "Tue, 12 Sep 1995 18:09:13 PDT." <199509130127.AA26953@venera.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Sep 1995 13:02:18 +0100 From: Martin Hamilton <martin@mrrl.lut.ac.uk> ILSI writes: | I found your homepage, really enjoyed it, and would like to use | it in my database. Time permitting, please look at my homepage and let | me know if you would like to be added to my resource. I have created this | database to assist people who have, or want, homepages on the internet, | or for people who want an off-line reference to the World Wide Web. If | possible, would you place a link from your site to my homepage, or if | you want to be included in this reference, please visit me at | http://www.ilsi.com/ilsi5.html "Welcome to Internet List Services Inc. You are user number 0000000 to access our new homepage." :-))) Martin From list-mgr@ISI.EDU Thu Sep 14 09:53:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13389>; Thu, 14 Sep 1995 10:54:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13252>; Thu, 14 Sep 1995 10:53:42 -0700 Received: from aotearoa (aotearoa.sura.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA13245>; Thu, 14 Sep 1995 10:53:41 -0700 Received: from LOCALHOST.sura.net by aotearoa with SMTP (8.6.12/($Id: sendmail.cf,v 1.17 1991/02/11 14:07:23 jmalcolm Exp $)) id NAA04314; Thu, 14 Sep 1995 13:53:36 -0400 Message-Id: <199509141753.NAA04314@aotearoa> To: mbone Subject: Is this a known problem? Date: Thu, 14 Sep 1995 13:53:35 -0400 From: Erik Sherk <sherk@sura.net> Hi, We have a 3.4 machine that crashed with this: BAD TRAP pid 118, `mrouted': Data fault kernel read fault at addr=0x8, pme=0x0 Sync Error Reg 80<INVALID> pc=0xf80187b8, sp=0xf8124e80, psr=0x8007c2, context=0x3 g1-g7: 8007e3, 8000000, 398ea, f3, f8292000, f814ec00, f814f000 Begin traceback... sp = f8124e80 Called from f8035470, fp=f8124ee0, args=ff659500 da ff650300 1 ff65bf00 0 Called from f80352f4, fp=f8124f40, args=4000c6 f80186b8 0 ff659500 8001e4 f8210708 Called from f8005f80, fp=f8124fa0, args=f80eb2f0 4000c6 f8136068 1 f8292000 f8210508 Called from f8005a54, fp=f8291c28, args=f8292000 f8291fb4 f8291fe0 f8292000 f8292000 f8291fb4 End traceback... panic: Data fault syncing file systems... done 00000 low-memory static kernel pages 00817 additional static and sysmap kernel pages 00000 dynamic kernel data pages 00048 additional user structure pages 00000 segmap kernel pages 00000 segvn kernel pages 00239 current user process pages 00025 user stack pages 01129 total pages (1129 chunks) dumping to vp fce03f14, offset 120544 1129 total pages, dump succeeded Is this a known problem? I am working on getting it up to 3.6 Erik From list-mgr@ISI.EDU Thu Sep 14 12:50:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12684>; Thu, 14 Sep 1995 19:50:26 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA12676>; Thu, 14 Sep 1995 19:50:24 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id TAA21642; Thu, 14 Sep 1995 19:50:52 -0700 Message-Id: <199509150250.TAA21642@rx7.ee.lbl.gov> To: mbone-na Subject: mmajer@sgi4.cs.uiuc.edu sending 400kb/s to mbone Date: Thu, 14 Sep 95 19:50:51 PDT From: Van Jacobson <van@ee.lbl.gov> User mmajer@sgi4.cs.uiuc.edu has been stepping through all the active mbone sessions and sending 400-500kb/s of video to them. A few minutes ago they were trashing the BayLISA session. Now they are trashing the NASA Shuttle session. Mail on this machine appears to be broken (attempts to email them just get an "unknown mailer error 2" reply back) so there doesn't seem to be anyway to ask them to stop. Could someone near UIUC please ask this antisocial individual to stop. Thanks. - Van From list-mgr@ISI.EDU Thu Sep 14 19:44:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14356>; Thu, 14 Sep 1995 20:44:55 -0700 Received: from nic.hq.cic.net by venera.isi.edu (5.65c/5.61+local-22) id <AA14349>; Thu, 14 Sep 1995 20:44:52 -0700 Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id XAA15096; Thu, 14 Sep 1995 23:44:49 -0400 Date: Thu, 14 Sep 1995 23:44:49 -0400 (EDT) From: Dorian Rysling Kim <dorian@CIC.Net> X-Sender: dorian@nic.hq.cic.net To: Van Jacobson <van@ee.lbl.gov> Cc: mbone-na, Umich NOC <noc@noc.ns.itd.umich.edu> Subject: Re: mmajer@sgi4.cs.uiuc.edu sending 400kb/s to mbone In-Reply-To: <199509150250.TAA21642@rx7.ee.lbl.gov> Message-Id: <Pine.OSF.3.91.950914234406.14729E-100000@nic.hq.cic.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Our NOC is going to notify UIUC NOC to see if we can take care of this problem. -dorian On Thu, 14 Sep 1995, Van Jacobson wrote: > User mmajer@sgi4.cs.uiuc.edu has been stepping through all the > active mbone sessions and sending 400-500kb/s of video to them. > A few minutes ago they were trashing the BayLISA session. Now > they are trashing the NASA Shuttle session. Mail on this machine > appears to be broken (attempts to email them just get an "unknown > mailer error 2" reply back) so there doesn't seem to be anyway > to ask them to stop. Could someone near UIUC please ask this > antisocial individual to stop. Thanks. > > - Van > ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From list-mgr@ISI.EDU Thu Sep 14 20:09:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15085>; Thu, 14 Sep 1995 21:09:47 -0700 Received: from nic.hq.cic.net by venera.isi.edu (5.65c/5.61+local-22) id <AA15078>; Thu, 14 Sep 1995 21:09:46 -0700 Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id AAA15423; Fri, 15 Sep 1995 00:09:39 -0400 Date: Fri, 15 Sep 1995 00:09:38 -0400 (EDT) From: Dorian Rysling Kim <dorian@CIC.Net> X-Sender: dorian@nic.hq.cic.net To: Van Jacobson <van@ee.lbl.gov> Cc: mbone-na Subject: Re: mmajer@sgi4.cs.uiuc.edu sending 400kb/s to mbone (fwd) Message-Id: <Pine.OSF.3.91.950915000839.14729I-100000@nic.hq.cic.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII FYI. -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian ---------- Forwarded message ---------- Date: Fri, 15 Sep 1995 00:05:41 -0400 (EDT) Subject: Re: mmajer@sgi4.cs.uiuc.edu sending 400kb/s to mbone (fwd) I called the UIUC NOC. The operator on duty paged a Teresa Scherg over in the comp sci department. She'll see to it immediately amd phone or email us when she's done. We'll keep on the UIUC NOC and Teresa for updates. Tony Castelletto ==================================================================== noc@noc.ns.itd.umich.edu Network Operations Center UM Information Technology Division From list-mgr@ISI.EDU Thu Sep 14 18:49:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16236>; Thu, 14 Sep 1995 21:49:24 -0700 Received: from tampico.cso.uiuc.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA16229>; Thu, 14 Sep 1995 21:49:22 -0700 Received: from [192.17.16.21] (archer.isdn.uiuc.edu [192.17.16.21]) by tampico.cso.uiuc.edu (8.6.12/8.6.11) with SMTP id XAA15130; Thu, 14 Sep 1995 23:49:12 -0500 X-Sender: kline@tampico.cso.uiuc.edu Message-Id: <v03002f04ac7eb629a34f@[192.17.16.21]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Sep 1995 23:49:14 -0500 To: Dorian Rysling Kim <dorian@CIC.Net> From: Charley Kline <kline@uiuc.edu> Subject: Re: mmajer@sgi4.cs.uiuc.edu sending 400kb/s to mbone Cc: Van Jacobson <van@ee.lbl.gov>, mbone-na, Umich NOC <noc@noc.ns.itd.umich.edu> At 11:44p 9/14/95, Dorian Rysling Kim wrote: >Our NOC is going to notify UIUC NOC to see if we can take care of this >problem. Thanks, I think they've got it tracked down in our CS department. /cvk From list-mgr@ISI.EDU Thu Sep 14 18:53:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16316>; Thu, 14 Sep 1995 21:53:47 -0700 Received: from realtime.cc.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA16309>; Thu, 14 Sep 1995 21:53:46 -0700 Received: (from ccshag@localhost) by realtime.cc.missouri.edu (8.6.12/8.6.12) id XAA19838; Thu, 14 Sep 1995 23:53:38 -0500 Date: Thu, 14 Sep 1995 23:53:37 -0500 (CDT) From: "Paul 'Shag' Walmsley" <ccshag@cclabs.missouri.edu> X-Sender: ccshag@realtime.cc.missouri.edu To: Van Jacobson <van@ee.lbl.gov> Cc: mbone-na Subject: Re: mmajer@sgi4.cs.uiuc.edu sending 400kb/s to mbone In-Reply-To: <199509150250.TAA21642@rx7.ee.lbl.gov> Message-Id: <Pine.SGI.3.91.950914235120.19767A-100000@realtime.cc.missouri.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 14 Sep 1995, Van Jacobson wrote: > User mmajer@sgi4.cs.uiuc.edu has been stepping through all the > active mbone sessions and sending 400-500kb/s of video to them. > A few minutes ago they were trashing the BayLISA session. Now > they are trashing the NASA Shuttle session. Mail on this machine > appears to be broken (attempts to email them just get an "unknown > mailer error 2" reply back) so there doesn't seem to be anyway > to ask them to stop. Could someone near UIUC please ask this > antisocial individual to stop. Thanks. I managed to open up a talk session to this user and was able to inform them of the heinous crime he had committed at about the same time as NASA called the lab :-) -- that _HAS_ to make an impression on someone. Turns out that it was a "new user to the MBONE" story. Perhaps the first time that the "transmit" button vic, vat, nv, or whatever is clicked, it could pop up a warning info box? Hmmm .... - Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu> "Praise and blame alike mean nothing." -- Virginia Woolf From list-mgr@ISI.EDU Sun Sep 17 05:26:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25978>; Sat, 16 Sep 1995 16:27:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25968>; Sat, 16 Sep 1995 16:26:48 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA25961>; Sat, 16 Sep 1995 16:26:45 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id CAA25708; Sun, 17 Sep 1995 02:26:04 +0300 Date: Sun, 17 Sep 1995 02:26:04 +0300 Message-Id: <199509162326.CAA25708@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: mbone Subject: mbone from NASA to Europe The Shuttle flows from NASA to most of Europe via two very old mrouteds: 18.180.0.2 (RASTRO.MIT.EDU) [version 2.2] and 192.35.82.97 (MBONE.CIT.CORNELL.EDU) [version 2.0] and I suspect these to be major contributors to the loss I'm observing. Is there any way these could either be upgraded or shut off? Pete From list-mgr@ISI.EDU Sun Sep 17 06:36:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00536>; Sat, 16 Sep 1995 19:38:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00521>; Sat, 16 Sep 1995 19:37:10 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA00514>; Sat, 16 Sep 1995 19:37:05 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id EAA26785; Sun, 17 Sep 1995 04:36:12 +0200 Message-Id: <199509170236.EAA26785@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: Petri Helenius <pete@sms.fi> Cc: mbone Subject: Re: mbone from NASA to Europe In-Reply-To: Your message of "Sun, 17 Sep 1995 02:26:04 +0300." <199509162326.CAA25708@silver.sms.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 17 Sep 1995 04:36:52 +0200 From: Magnus <e93_mda@it.kth.se> > > The Shuttle flows from NASA to most of Europe via two very old mrouteds: > 18.180.0.2 (RASTRO.MIT.EDU) [version 2.2] > and > 192.35.82.97 (MBONE.CIT.CORNELL.EDU) [version 2.0] > > and I suspect these to be major contributors to the loss I'm observing. > > > Is there any way these could either be upgraded or shut off? > > Pete > Since you are located in Finland you should get your US trafic through the stockholm.mbone.ebone.net machine. This machine has a tunnel to a machine in the US called mae-bone.psi.net, both the machine you are pointing out (rastro.mit.edu and mbone.cit.cornell.edu) has there trafic towards you going through this machine. It has previously been brougth to my attention that the network that this machine is sitting on is lossy, which has been verified to have some truth when debuging with mtrace. Therefore would those lost packages be lost when reaching your machine. This is how it acts from my machine: ping -f mae-bone.psi.net PING mae-bone.psi.net (192.41.177.247): 56 data bytes ............................................................................... ............................................................................... ............................................................................... ............................................................................... ............................................................................... ............................................................................... ............................................................................... ............................................................................... ............................................................................... ............................................................................... ............................................................................... ............................................................................... ................... --- mae-bone.psi.net ping statistics --- 967 packets transmitted, 0 packets received, 100% packet loss A small test towards on of the machines you pointed out: ping -f rastro.mit.edu PING rastro.mit.edu (18.180.0.2): 56 data bytes ............................................................................... ............................................................................... ............................................................................... ............................................................................... ............................................................................... ............................................................................... ...... --- rastro.mit.edu ping statistics --- 15445 packets transmitted, 14797 packets received, 4% packet loss I have seen similar behaiviours on a few other machines that is sitting on the same network.So, I susspect that we should not traverse that part of faulty net. I have said this before and will continue to point this out. There is other machines that we could be tunneling to, one of them (mbone-east.ans.net) has been down for some time (Bob, bring it up with SunOS 4.1.x and mrouted 3.6). I think that from the point of European feeds there should be (at least) two machines in each end of this transatlantic feed (the 34Mbps) which would act as main and backup machines. These machines should have good networks aswell as good tunnels to local infrastructure. I will also make a plea to everyone running older versions of mrouted (2.x) to uppgrade to a more recent one, later versions of mrouted helps when debugging connections. Magnus Mbone Manegment Center @ KTH/IT From list-mgr@ISI.EDU Sun Sep 17 06:49:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00832>; Sat, 16 Sep 1995 19:50:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00818>; Sat, 16 Sep 1995 19:49:18 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA00810>; Sat, 16 Sep 1995 19:49:13 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id EAA26836 for <mbone@isi.edu>; Sun, 17 Sep 1995 04:48:32 +0200 Message-Id: <199509170248.EAA26836@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: mbone Subject: Yet annother note about the mae-bone.psi.net machine Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 17 Sep 1995 04:49:12 +0200 From: Magnus <e93_mda@it.kth.se> The tunnel towardw that machine doe work by the way.... this is a fresh mtrace: Source Response Dest Packet Statistics For Only For Traffic 192.41.177.247 224.0.1.32 All Multicast Traffic From 192.41.177.247 | __/ rtt 957 ms Lost/Sent = Pct Rate To 224.2.0.1 v / hop 230 s --------------------- -------------------- 192.41.177.247 mae-bone.psi.net | ^ ttl 64 v | hop -60 s 29/631 = 5% 70 pps 0/0 = --% 0 pps 192.36.148.206 stockholm.mbone.ebone.net so the machine is there.... probably got some handhacked routingtables... does not aid in debugging does it? Still, something needs to be done. PS. Some of you migth start to understand my interest in the mbone-na stuff :-) DS. Magnus From list-mgr@ISI.EDU Wed Sep 16 17:45:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06853>; Sun, 17 Sep 1995 00:46:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06846>; Sun, 17 Sep 1995 00:45:54 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA06839>; Sun, 17 Sep 1995 00:45:53 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15757(1)>; Sun, 17 Sep 1995 00:45:50 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Sun, 17 Sep 1995 00:45:34 -0700 To: Petri Helenius <pete@sms.fi> Cc: mbone Subject: Re: mbone from NASA to Europe In-Reply-To: Your message of "Sat, 16 Sep 95 16:26:04 PDT." <199509162326.CAA25708@silver.sms.fi> Date: Sun, 17 Sep 1995 00:45:21 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Sep17.004534pdt.177475@crevenia.parc.xerox.com> In message <199509162326.CAA25708@silver.sms.fi> you write: > > The Shuttle flows from NASA to most of Europe via two very old mrouteds: > 18.180.0.2 (RASTRO.MIT.EDU) [version 2.2] >and > 192.35.82.97 (MBONE.CIT.CORNELL.EDU) [version 2.0] No, it doesn't. (I picked nic.edu.fi guessing that it might be close to you; I don't know what your mrouted's name is so I didn't trace directly from it.) % mtrace -M -l -t 127 scorpio.arc.nasa.gov nic.edu.fi 224.2.142.95 Mtrace from 128.102.84.140 to 193.64.151.65 via group 224.2.142.95 Querying full reverse path... 0 nic.edu.fi (193.64.151.65) -1 nic.edu.fi (193.64.151.65) DVMRP thresh^ 1 42 ms -2 directory.funet.fi (128.214.1.252) DVMRP thresh^ 16 210396 ms -3 stockholm.mbone.ebone.net (192.36.148.206) DVMRP thresh^ 40 13123 ms -4 mae-bone.psi.net (192.41.177.247) DVMRP thresh^ 64 -47828 ms -5 VINEGAR.SESQUI.NET (128.241.0.91) DVMRP thresh^ 64 786 ms -6 mbone.sdsc.edu (198.17.47.39) DVMRP thresh^ 64 7316 ms -7 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 64 46 ms -8 mbone2.nsi.nasa.gov (192.203.230.242) DVMRP thresh^ 1 396 ms -9 arcbone.arc.nasa.gov (128.102.84.150) DVMRP thresh^ 32 77303 ms -10 scorpio.arc.nasa.gov (128.102.84.140) Round trip time 881 ms >and I suspect these to be major contributors to the loss I'm observing. mtrace shows low loss to Europe on the NASA video session: Source Response Dest Packet Statistics For Only For Traffic 128.102.84.140 224.0.1.32 All Multicast Traffic From 128.102.84.140 | __/ rtt 1001 ms Lost/Sent = Pct Rate To 224.2.142.95 v / hop -76 s --------------------- -------------------- 128.102.84.150 arcbone.arc.nasa.gov | ^ ttl 32 0/93 = 0% 8 pps 0/91 = 0% 8 pps v | hop 76 s 0/3875 = 0% 29 pps 0/1089 = 0% 8 pps 192.203.230.242 mbone2.nsi.nasa.gov | ^ ttl 33 -1/109 = 0% 9 pps 0/91 = 0% 8 pps v | hop 391 ms 0/4093 = 0% 31 pps 0/1089 = 0% 8 pps 192.203.230.241 mbone.nsi.nasa.gov | ^ ttl 64 14/241 = 6% 21 pps 1/91 = 1% 8 pps v | hop -7 s 332/5700 = 6% 43 pps 36/1089 = 3% 8 pps 198.17.47.39 mbone.sdsc.edu | ^ ttl 65 1/218 = 0% 19 pps 0/90 = 0% 8 pps v | hop 6570 ms 74/5282 = 1% 40 pps 18/1053 = 2% 8 pps 128.241.0.91 VINEGAR.SESQUI.NET | ^ ttl 66 0/219 = 0% 19 pps 0/90 = 0% 8 pps v | hop 48 s 0/5223 = 0% 39 pps 0/1035 = 0% 7 pps 192.41.177.247 mae-bone.psi.net | ^ ttl 67 6/262 = 2% 26 pps 3/90 = 3% 9 pps v | hop -60 s -8/5721 = 0% 43 pps 3/1035 = 0% 7 pps 192.36.148.206 stockholm.mbone.ebone.net Are you sure you shouldn't be looking closer to home for your loss? (We are trying to deal with the loss between mbone.nsi and mbone.sdsc; it appears to simply be a poor unicast path.) Bill From list-mgr@ISI.EDU Sun Sep 17 15:16:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08556>; Sun, 17 Sep 1995 02:17:03 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08545>; Sun, 17 Sep 1995 02:16:25 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA08538>; Sun, 17 Sep 1995 02:16:22 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id MAA26289; Sun, 17 Sep 1995 12:16:15 +0300 Date: Sun, 17 Sep 1995 12:16:15 +0300 Message-Id: <199509170916.MAA26289@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Bill Fenner <fenner@parc.xerox.com> Cc: mbone Subject: Re: mbone from NASA to Europe In-Reply-To: <95Sep17.004534pdt.177475@crevenia.parc.xerox.com> References: <199509162326.CAA25708@silver.sms.fi> <95Sep17.004534pdt.177475@crevenia.parc.xerox.com> Bill Fenner writes: > > The Shuttle flows from NASA to most of Europe via two very old mrouteds: > > 18.180.0.2 (RASTRO.MIT.EDU) [version 2.2] > >and > > 192.35.82.97 (MBONE.CIT.CORNELL.EDU) [version 2.0] > > No, it doesn't. (I picked nic.edu.fi guessing that it might be close to you; > I don't know what your mrouted's name is so I didn't trace directly from it.) > > Are you sure you shouldn't be looking closer to home for your loss? > I'm seeing loss less than 10% now, so it's a lot better now and I think it might have been at the time you did the trace. > (We are trying to deal with the loss between mbone.nsi and mbone.sdsc; it > appears to simply be a poor unicast path.) > Thanks. Pete From list-mgr@ISI.EDU Sun Sep 17 08:14:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12004>; Sun, 17 Sep 1995 08:16:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11948>; Sun, 17 Sep 1995 08:15:08 -0700 Received: from Bulldog.Stupi.SE (Relay.Stupi.SE) by venera.isi.edu (5.65c/5.61+local-22) id <AA11941>; Sun, 17 Sep 1995 08:14:38 -0700 Received: from junk.stupi.se(192.108.198.200) by Bulldog.Stupi.SE id sma020081; Sun Sep 17 17:14:20 1995 Date: Sun, 17 Sep 95 17:22:49 MET DST From: Peter Lothberg <roll@Stupi.SE> To: Magnus <e93_mda@it.kth.se> Cc: Petri Helenius <pete@sms.fi>, mbone Subject: Re: mbone from NASA to Europe In-Reply-To: Your message of Sun, 17 Sep 1995 04:36:52 +0200 Message-Id: <CMM.0.90.0.811351369.roll@Junk.Stupi.SE> > > > > The Shuttle flows from NASA to most of Europe via two very old mrouteds: > > 18.180.0.2 (RASTRO.MIT.EDU) [version 2.2] > > and > > 192.35.82.97 (MBONE.CIT.CORNELL.EDU) [version 2.0] > > > > and I suspect these to be major contributors to the loss I'm observing. > > > > > > Is there any way these could either be upgraded or shut off? > > > > Pete > > > > Since you are located in Finland you should get your US trafic through the > stockholm.mbone.ebone.net machine. This machine has a tunnel to a machine in > the US called mae-bone.psi.net, both the machine you are pointing out > (rastro.mit.edu and mbone.cit.cornell.edu) has there trafic towards you going > through this machine. > > It has previously been brougth to my attention that the network that this > machine is sitting on is lossy, which has been verified to have some truth when > debuging with mtrace. Therefore would those lost packages be lost when reaching > your machine. > This is how it acts from my machine: > ping -f mae-bone.psi.net > PING mae-bone.psi.net (192.41.177.247): 56 data bytes > ............................................................................... > ............................................................................... > ............................................................................... > ............................................................................... > ............................................................................... > ............................................................................... > ............................................................................... > ............................................................................... > ............................................................................... > ............................................................................... > ............................................................................... > ............................................................................... > ................... > --- mae-bone.psi.net ping statistics --- > 967 packets transmitted, 0 packets received, 100% packet loss > > A small test towards on of the machines you pointed out: > ping -f rastro.mit.edu > PING rastro.mit.edu (18.180.0.2): 56 data bytes > ............................................................................... > ............................................................................... > ............................................................................... > ............................................................................... > ............................................................................... > ............................................................................... > ...... > --- rastro.mit.edu ping statistics --- > 15445 packets transmitted, 14797 packets received, 4% packet loss > > I have seen similar behaiviours on a few other machines that is sitting on the > same network.So, I susspect that we should not traverse that part of faulty > net. > > I have said this before and will continue to point this out. There is other > machines that we could be tunneling to, one of them (mbone-east.ans.net) has > been down for some time (Bob, bring it up with SunOS 4.1.x and mrouted 3.6). > > I think that from the point of European feeds there should be (at least) two > machines in each end of this transatlantic feed (the 34Mbps) which would act > as main and backup machines. These machines should have good networks aswell > as good tunnels to local infrastructure. > > I will also make a plea to everyone running older versions of mrouted (2.x) > to uppgrade to a more recent one, later versions of mrouted helps when > debugging > connections. > > > Magnus > Mbone Manegment Center @ KTH/IT > > If some Mbone WIZes wanna change something, here are some input. The circiut between Stockholm and the US goes to the NY-NAP in Pennsauken, so it would be optimal to take a Mbone feed from something located close to the NAP. (Maybe Mbone inside Sprintlink?) MAE-East is less than optimal, especially as there is no direct peering between ICM and PSI.. --Peter  From list-mgr@ISI.EDU Sun Sep 17 02:26:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13662>; Sun, 17 Sep 1995 09:27:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13651>; Sun, 17 Sep 1995 09:27:07 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA13642>; Sun, 17 Sep 1995 09:27:06 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14765(6)>; Sun, 17 Sep 1995 09:26:58 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Sun, 17 Sep 1995 09:26:51 -0700 To: Magnus <e93_mda@it.kth.se> Cc: mbone Subject: Re: mbone from NASA to Europe In-Reply-To: Your message of "Sat, 16 Sep 95 19:36:52 PDT." <199509170236.EAA26785@piraya.electrum.kth.se> Date: Sun, 17 Sep 1995 09:26:49 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Sep17.092651pdt.177475@crevenia.parc.xerox.com> In message <199509170236.EAA26785@piraya.electrum.kth.se> you write: >It has previously been brougth to my attention that the network that >[mae-bone] is sitting on is lossy... > >ping -f mae-bone.psi.net >PING mae-bone.psi.net (192.41.177.247): 56 data bytes >--- mae-bone.psi.net ping statistics --- >967 packets transmitted, 0 packets received, 100% packet loss Well, I don't have floodping, but: PING mae-bone.psi.net: 56 data bytes ----mae-bone.psi.net PING Statistics---- 61 packets transmitted, 61 packets received, 0% packet loss It's clear that the alleged loss is not consistent. You got 100% loss because, for security reasons, that machine has a very constrained routing table. Given where it is located, it makes sense to use all the security measures possible. Bill From list-mgr@ISI.EDU Sun Sep 17 15:44:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22878>; Sun, 17 Sep 1995 16:49:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22865>; Sun, 17 Sep 1995 16:48:35 -0700 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA22858>; Sun, 17 Sep 1995 16:48:34 -0700 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA01540; Sun, 17 Sep 1995 19:44:56 +0500 Message-Id: <9509172344.AA01540@msf.psi.net.> To: Peter Lothberg <roll@stupi.se> Cc: Magnus <e93_mda@it.kth.se>, Petri Helenius <pete@sms.fi>, mbone Subject: Re: mbone from NASA to Europe In-Reply-To: Your message of "Sun, 17 Sep 1995 17:22:49 +0700." <CMM.0.90.0.811351369.roll@Junk.Stupi.SE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <1538.811381495.1@msf.psi.net> Date: Sun, 17 Sep 1995 19:44:55 -0400 From: "Mark S. Fedor" <fedor@msf.psi.net> Content-Length: 608 > > MAE-East is less than optimal, especially as there is no direct > peering between ICM and PSI.. > Doesn't matter. mae-bone.psi.net is directly on mae-east using static routing. It has severely limited routing table entries. It has a 192.41.177.x address. mae-bone.psi.net is not inside of PSINet. However, if ICM is not directly on mae-east, that is a problem. When someone asks for a tunnel to mae-bone. I always ask them where the tunnel should be pointed to for the next hop router on mae-east. Just tell me where you want your tunnels unicast routed and it shall be done. mf > --Peter From list-mgr@ISI.EDU Mon Sep 18 00:22:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02979>; Mon, 18 Sep 1995 00:24:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02924>; Mon, 18 Sep 1995 00:23:06 -0700 Received: from Bulldog.Stupi.SE (Relay.Stupi.SE) by venera.isi.edu (5.65c/5.61+local-22) id <AA02916>; Mon, 18 Sep 1995 00:22:59 -0700 Received: from junk.stupi.se(192.108.198.200) by Bulldog.Stupi.SE id sma020960; Mon Sep 18 09:22:36 1995 Date: Mon, 18 Sep 95 9:32:49 MET DST From: Peter Lothberg <roll@Stupi.SE> To: "Mark S. Fedor" <fedor@msf.psi.net> Cc: Magnus <e93_mda@it.kth.se>, Petri Helenius <pete@sms.fi>, mbone Subject: Re: mbone from NASA to Europe In-Reply-To: Your message of Sun, 17 Sep 1995 19:44:55 -0400 Message-Id: <CMM.0.90.0.811409569.roll@Junk.Stupi.SE> > > > > MAE-East is less than optimal, especially as there is no direct > > peering between ICM and PSI.. > > > > Doesn't matter. mae-bone.psi.net is directly on mae-east using static > routing. It has severely limited routing table entries. It has a > 192.41.177.x address. > > mae-bone.psi.net is not inside of PSINet. > > However, if ICM is not directly on mae-east, that is a problem. > > When someone asks for a tunnel to mae-bone. I always ask them where the > tunnel should be pointed to for the next hop router on mae-east. > > Just tell me where you want your tunnels unicast routed and it shall be done. > > mf > > > --Peter > I want PSI to connect in Pennsauken for traffic to Europe. From list-mgr@ISI.EDU Sat Sep 19 08:34:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02780>; Tue, 19 Sep 1995 02:31:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02758>; Tue, 19 Sep 1995 02:29:44 -0700 Received: from alink-gw.apple.com by venera.isi.edu (5.65c/5.61+local-22) id <AA02749>; Tue, 19 Sep 1995 02:29:39 -0700 Received: by alink-gw.apple.com (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA22669; Tue, 19 Sep 95 02:29:38 -0700 for MBONE@ISI.EDU Date: 19 Sep 95 08:34 GMT From: HEAPSYS@AppleLink.Apple.COM (HeapSys, Paris,FR,IDV) Subject: AV/Conf interoperability To: MBONE Message-Id: <811502978.0836091@AppleLink.Apple.COM> From : Frank Barthe Hello world (of net-conferencing !) 1 - I beg your pardon for such a private use of the MBONE list 2 - my work place is FRANCE TELECOM / CITCOM, in charge of "distance activities" projects. Tel : 33 1 44 23 68 74 3 - Contributions could be addressed to my own mailbox just not to load the mbone exchanges. eM : HEAPSYS@APPLELINK.APPLE.COM C Subject : how to make videoconferencing software (Ex:IVS) interoperate with hardware video codecs (Ex:Bitfield) It seems that such a dev. has been done in the MICE project ? C Addendum : I'm working on an audio-conferencing hardware nodal with o echo cancellation o ISDN interface for H320 users with stand-alone codecs (picturetel, ....) o IP interface for net users with workstations (Mac, PC, Sun, ....) o PSTN interface for public users with telephone sets Is this of any interest for you ?? From list-mgr@ISI.EDU Tue Sep 19 15:06:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04713>; Tue, 19 Sep 1995 05:11:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04701>; Tue, 19 Sep 1995 05:11:20 -0700 Received: from rc4.vub.ac.be (mailhost.vub.ac.be) by venera.isi.edu (5.65c/5.61+local-22) id <AA04674>; Tue, 19 Sep 1995 05:09:41 -0700 Received: from rc1.vub.ac.be (rc1 [134.184.15.1]) by rc4.vub.ac.be (8.6.10/3.4.2.ap (rc4)) id OAA27877; Tue, 19 Sep 1995 14:12:09 +0200 Received: from ipb0.ulb.ac.be by rc1.vub.ac.be (5.x/VUB-SOLARIS.920228) id AA07680; Tue, 19 Sep 1995 14:11:37 +0200 Received: from ipbu1.ulb.ac.be by ipb0.ulb.ac.be (5.x/ULB.940202) id AA14518; Tue, 19 Sep 1995 14:12:38 +0100 Received: by ipbu1.ulb.ac.be (5.x/SMI-SVR4) id AA10133; Tue, 19 Sep 1995 14:06:31 +0100 From: sciocea@ipb0.ulb.ac.be (Sorin Ciocea) Message-Id: <9509191306.AA10133@ipbu1.ulb.ac.be> Subject: VIdeo Conference To: mbone Date: Tue, 19 Sep 1995 14:06:31 +0100 (WET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Hello, Can you tell me which is the easiest way (software) to install a video-audio conference tool, only for receiving? I have a Sparc 20 station running Solaris 2.4, with a 16 bits audio tool. Sorin Ciocea sciocea@ulb.ac.be Universite Libre Bruxelles Belgium From list-mgr@ISI.EDU Tue Sep 19 01:28:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09799>; Tue, 19 Sep 1995 08:30:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09760>; Tue, 19 Sep 1995 08:29:26 -0700 Received: from cs.nps.navy.mil by venera.isi.edu (5.65c/5.61+local-22) id <AA09753>; Tue, 19 Sep 1995 08:29:24 -0700 Received: by cs.nps.navy.mil (4.1/SMI-4.1) id AA22927; Tue, 19 Sep 95 08:28:10 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9509191528.AA22927@cs.nps.navy.mil> Subject: HP-UX 10 multicast problem IP_ADD_MEMBERSHIP To: mbone (Multicast Backbone mail list), haddad@hpl.hp.com (Peter Haddad) Date: Tue, 19 Sep 1995 08:28:09 -0700 (PDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 561 I am at a sponsors lab in Newport RI. They have an HP 9000/710 (TAC-4) running HP-UX B.10.00 A When invoking sd we get an IP_ADD_MEMBERSHIP error. Previous use on a TAC-4 did not provoke this error. Usual questions: has anyone seen this, and if so how to fix it? Thanks in advance for any help. all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA [Root 200] fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv_uvw.html From list-mgr@ISI.EDU Tue Sep 19 16:12:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05662>; Tue, 19 Sep 1995 17:15:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05561>; Tue, 19 Sep 1995 17:12:46 -0700 Received: from davinci.gmu.edu ([206.197.101.10]) by venera.isi.edu (5.65c/5.61+local-22) id <AA05551>; Tue, 19 Sep 1995 17:12:45 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id UAA05600; Tue, 19 Sep 1995 20:12:00 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199509200012.UAA05600@davinci.gmu.edu> Subject: A couple questions To: mbone Date: Tue, 19 Sep 1995 20:12:00 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 968 1) Any word on the mrouted port for Linux? 2) We have a Sunvideo card on a sparc 20. It refuses to let NV work. It is running Solaris 2.4. Any ideas? NV will send out cell-b encoding but gives a black screen with NV encoding. 3) Is there a mrouted port underway or completed for Windows (either 95 or NT). I need to be able to route a tunnel to a machine with Windows on it. 4) Is the code for sd,vat and wb ever going to be released? (I am asking this because we need a working port of vat for Linux and would also like this tools for Windows machines. 5) Is there any work underway for better compression methods (or plug in compression routines) to be put into VAT? 6) Is there any effort underway to increase the bandwidth of the mbone? Michael -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Wed Sep 20 16:25:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26795>; Wed, 20 Sep 1995 07:29:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26750>; Wed, 20 Sep 1995 07:28:36 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA26743>; Wed, 20 Sep 1995 07:28:33 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA15976>; Wed, 20 Sep 1995 07:28:17 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.16801-0@bells.cs.ucl.ac.uk>; Wed, 20 Sep 1995 15:25:10 +0100 From: Mark Handley <M.Handley@cs.ucl.ac.uk> Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: mbenson@davinci.gmu.edu (Michael Benson) Cc: mbone Subject: Re: A couple questions In-Reply-To: Your message of "Tue, 19 Sep 95 20:12:00 EDT." <199509200012.UAA05600@davinci.gmu.edu> Date: Wed, 20 Sep 95 15:25:07 +0100 Message-Id: <10892.811607107@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >2) We have a Sunvideo card on a sparc 20. It refuses to let NV work. > It is running Solaris 2.4. Any ideas? NV will send out cell-b > encoding but gives a black screen with NV encoding. Start encoding, switch to greyscale encoding and then back to colour - it'll do some re-initialisation that fixes the problem. Or use vic to do nv encoding. Or use vic to do H.261 encoding :-) >4) Is the code for sd,vat and wb ever going to be released? (I am asking > this because we need a working port of vat for Linux and would also like > this tools for Windows machines. I don't know about sd, but sdr (my version of sd) should be source available in a few months. I've been saying this for ages though.... >5) Is there any work underway for better compression methods (or plug in > compression routines) to be put into VAT? Give Van the compression module and ask nicely... There are also other experimental audio tools either available (nevot) or shortly to be available (UCL + INRIA work). Any particular compression schemes you'd like to see? >6) Is there any effort underway to increase the bandwidth of the mbone? This needs two things: 1. More bandwidth on various links, particularly international ones. We have an experimental 2Mbps ATM Mbone backbone around Europe, but still lots of the sites fed off it can't cope :-( 2. Widescale deployment of multicast routing in real routers. PIM has been "difficult" to deploy on the backbone - I believe this will change soon. Both are happening, but take time. Mark From list-mgr@ISI.EDU Wed Sep 20 19:47:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00643>; Wed, 20 Sep 1995 08:48:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00584>; Wed, 20 Sep 1995 08:48:00 -0700 Received: from mailgate.ericsson.se by venera.isi.edu (5.65c/5.61+local-22) id <AA00515>; Wed, 20 Sep 1995 08:47:40 -0700 Received: from eua.ericsson.se (eua.ericsson.se [134.138.132.16]) by mailgate.ericsson.se (8.6.11/1.0) with SMTP id RAA02418 for <mbone@ISI.EDU>; Wed, 20 Sep 1995 17:47:30 +0200 Received: from ms (ms.eua.ericsson.se) by eua.ericsson.se (4.1/EUA-2.1) id AA05768; Wed, 20 Sep 95 17:47:29 +0200 Received: from euas78c16.eua.ericsson.se by ms (4.1/MS-2.1) id AA17851; Wed, 20 Sep 95 17:47:28 +0200 From: Jakob.Ellerstedt@eua.ericsson.se (Jakob Ellerstedt) Received: by euas78c16.eua.ericsson.se (5.x/client-1.3) id AA20852; Wed, 20 Sep 1995 17:47:28 +0200 Date: Wed, 20 Sep 1995 17:47:28 +0200 Message-Id: <9509201547.AA20852@euas78c16.eua.ericsson.se> To: mbone Subject: vic2.6 - patch needed X-Sun-Charset: US-ASCII Anyone know what patch(es) that will remedy this: > vic: "activate s808661837 cellb 1": window name "table" already exists in par (I have the profile on a machine where vic2.6 works but it contains *lots* of patches not installed on my workstation.) I run Solaris 2.4 on a SS5. Take care! /Jakob euaell@eua.ericsson.se PS. I've been informed the problem will be gone in a future release of vic2.7. From list-mgr@ISI.EDU Wed Sep 20 02:05:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01953>; Wed, 20 Sep 1995 09:06:27 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01909>; Wed, 20 Sep 1995 09:05:57 -0700 Received: from euclid.jpl.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA01902>; Wed, 20 Sep 1995 09:05:55 -0700 Received: by euclid.Jpl.Nasa.Gov (8.6.10/SMI-4.1+DXRm2.5) id JAA13029; Wed, 20 Sep 1995 09:05:54 -0700 Subject: MBONE and scalability To: mbone X-Mailer: Poste 2.0 From: "Peter J. Scott" <pjs@euclid.Jpl.Nasa.Gov> Date: Wed, 20 Sep 95 09:05:53 -0700 Message-Id: <950920090553.12495@euclid> Encoding: 14 TEXT, 2 TEXT SIGNATURE Every time I use the MBONE I worry about scalability and what will happen once this gets out into the hands of net users who are not as conscientious and technically-minded as those currently using it. I think about how there are some now-obvious holes in USENET when used by the technologically unwashed :-) and how they could have been plugged if the news readers had been modified at an early stage to perform various kinds of sanity checking. Then the later generations of newsreaders would have inherited the checks. While the MBONE is still small and the software is well controlled, this might be a good time to consider how to build in sanity checks that will make it hard to trash the net... $0.02. Peter J. Scott, Member of Technical Staff | Peter.J.Scott@jpl.nasa.gov Jet Propulsion Laboratory, NASA/Caltech | EPIC Program Office From list-mgr@ISI.EDU Wed Sep 20 09:01:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04038>; Wed, 20 Sep 1995 10:01:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04000>; Wed, 20 Sep 1995 10:01:18 -0700 Received: from paris.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA03990>; Wed, 20 Sep 1995 10:01:15 -0700 Received: (from aprakash@localhost) by paris.eecs.umich.edu (8.6.12/8.6.12) id NAA02335 for mbone@isi.edu; Wed, 20 Sep 1995 13:01:19 -0400 Date: Wed, 20 Sep 1995 13:01:19 -0400 From: Atul Prakash <aprakash@eecs.umich.edu> Message-Id: <199509201701.NAA02335@paris.eecs.umich.edu> To: mbone Subject: Error message from Audio tool. I get the following message when I try to open an audio-based conference: AUDIO_FLUSH: Invalid argument Anyone know what the problem might be? I am running SunOS 4.1.3 with multicast extensions on Sparc 20. Thanks. -- Atul From list-mgr@ISI.EDU Wed Sep 20 10:43:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25296>; Wed, 20 Sep 1995 17:45:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25258>; Wed, 20 Sep 1995 17:43:40 -0700 Received: from Csli.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA25251>; Wed, 20 Sep 1995 17:43:38 -0700 Received: from Csli.Stanford.EDU (localhost.Stanford.EDU [127.0.0.1]) by Csli.Stanford.EDU (8.6.11/8.6.11) with ESMTP id RAA23581; Wed, 20 Sep 1995 17:43:11 -0700 Message-Id: <199509210043.RAA23581@Csli.Stanford.EDU> To: Mark Handley <M.Handley@cs.ucl.ac.uk> Cc: mbenson@davinci.gmu.edu (Michael Benson), mbone Subject: Re: A couple questions In-Reply-To: Your message of Wed, 20 Sep 1995 15:25:07 BST. <10892.811607107@cs.ucl.ac.uk> Date: Wed, 20 Sep 1995 17:43:10 -0700 From: Christian Wettergren <cwe@Csli.Stanford.EDU> | >5) Is there any work underway for better compression methods (or plug in | > compression routines) to be put into VAT? | | Give Van the compression module and ask nicely... What is the interface for the audio modules? I'd be most happy to get "richer" audio format, that samples at higher freq. (I'm no audio guy, but I'm under the probably wrong impression that higher sampling rate might increase the quality - if one has the bandwidth. Am I wrong there?) | There are also other experimental audio tools either available (nevot) | or shortly to be available (UCL + INRIA work). Any particular | compression schemes you'd like to see? I also wonder about RTPv2-based audio tools? Will UCL+INRIA's tool be RTP-based? I guess so? Is nevot RTP-based? And where is it, I haven't found it linked up from anywhere yet. I am also interested in anyone who has experience in trying to sync the audio and video of higher-bandwidth streams, around 1 Mbps. My current plan is to write a 'sync-monitor' that syncronized the media-streams coming in over the network, and then deliver the streams independantly through local delivery to the proper tools. (local == localhost for example.) And yet another question (turning into a FAQ-section almost), is where is the rtp_testbed source code? Many questions, indeed. Regards, Christian Wettergren KTH/Teleinformatics From list-mgr@ISI.EDU Thu Sep 21 19:49:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27885>; Wed, 20 Sep 1995 18:52:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27836>; Wed, 20 Sep 1995 18:52:13 -0700 Received: from nms.etri.re.kr ([129.254.9.4]) by venera.isi.edu (5.65c/5.61+local-22) id <AA27680>; Wed, 20 Sep 1995 18:51:16 -0700 Received: from hic.etri.re.kr by nms.etri.re.kr (4.1/NMS-0.1) id AA27750; Thu, 21 Sep 95 10:51:14 KDT Received: by hic.etri.re.kr (8.6.9H1/SMI-SVR4) id KAA16748; Thu, 21 Sep 1995 10:49:37 +0900 From: cjh@hic.etri.re.kr Message-Id: <199509210149.KAA16748@hic.etri.re.kr> Subject: transmit MBONE stream to cu-seeme? To: mbone Date: Thu, 21 Sep 1995 10:49:36 +0900 (KST) X-Mailer: ELM [version 2.4 PL21-h4(V)] Content-Type: text Content-Length: 530 Anyone know how MBONE stream(Video/Audio) transmit to cu-seem via reflector? I have Solaris 2.4, SunVideo board and reflector. I know that reflector can send nv stream to cu-seeme(Windows version)? But it does not work, I can't see anything. help me. -- -------------------------------------------------------------------------------- Choi JoonHyuk Service Architectur Section E-Mail:cjh@hic.etri.re.kr Phone :042-860-6770 http://hic.etri.re.kr -------------------------------------------------------------------------------- From list-mgr@ISI.EDU Thu Sep 21 23:14:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04226>; Wed, 20 Sep 1995 22:28:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04073>; Wed, 20 Sep 1995 22:20:20 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA04064>; Wed, 20 Sep 1995 22:20:13 -0700 Received: from camis.kaist.ac.kr by quark.isi.edu (5.65c/5.61+local-20) id <AA23919>; Wed, 20 Sep 1995 22:19:31 -0700 Received: (from jwjung@localhost) by camis.kaist.ac.kr (8.6.12H1/8.6.9) id OAA25104; Thu, 21 Sep 1995 14:14:15 +0900 From: Jung Joowon <jwjung@camis.kaist.ac.kr> Message-Id: <199509210514.OAA25104@camis.kaist.ac.kr> Subject: Re: transmit MBONE stream to cu-seeme? To: cjh@hic.etri.re.kr Date: Thu, 21 Sep 1995 14:14:15 +0900 (JST) Cc: mbone, cu-seeme-l@cornell.edu In-Reply-To: <199509210149.KAA16748@hic.etri.re.kr> from "cjh@hic.etri.re.kr" at Sep 21, 95 10:49:36 am X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 1426 > Anyone know how MBONE stream(Video/Audio) transmit to cu-seem via reflector? > I have Solaris 2.4, SunVideo board and reflector. > I know that reflector can send nv stream to cu-seeme(Windows version)? > But it does not work, I can't see anything. > help me. You should configure reflect.conf in CU-SeeMe reflector... (reflect.conf file in CU-SeeMe reflector version 4.0b2 has a lot of comments. please refer to it... Keyword: NV-* VAT-*) And... You MUST transmit the voice in DVI format, and the movie in CU-SeeMe format (Grayscale) with *SMALL* size in vat and nv. I tried reflector 3.0b3, 4.0b2, 4.0b2.1 and CU-SeeMe 0.6x and 0.7x. Reflector version 4.x dumps core when vat and CU-SeeMe works cooperatively. But 3.0b3 does not. If only one CU-SeeMe client and MBONE application is connected to a reflector, the output (video/audio) of CU-SeeMe does not transferred to MBONE application. (I guess the reflector misunderstand that just one client connected. - "So, I'm not transfer the data of client to anyone (including vat).") But, two or more CU-SeeMe clients, it works. This is the all of my experience. Hope this helps... -Jung Joowon -- Jung Joowon | E-mail: jwjung@camis.kaist.ac.kr Center for Adv. Management Info. System | Phone(Office): +82-42-869-8321~4 Korea Advanced Inst. of Sci. and Tech. | Fax : +82-42-869-8330 Taejon, Republic of Korea, 305-701 | http://camis.kaist.ac.kr/~jwjung/ From list-mgr@ISI.EDU Thu Sep 21 11:30:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07847>; Thu, 21 Sep 1995 00:39:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07591>; Thu, 21 Sep 1995 00:32:41 -0700 Received: from ceres.fokus.gmd.de by venera.isi.edu (5.65c/5.61+local-22) id <AA07584>; Thu, 21 Sep 1995 00:32:35 -0700 Message-Id: <199509210732.AA07584@venera.isi.edu> Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Thu, 21 Sep 1995 09:30:38 +0200 X-Mailer: exmh version 1.6.2 8/09/95 To: Christian Wettergren <cwe@csli.stanford.edu> Cc: Mark Handley <M.Handley@cs.ucl.ac.uk>, mbenson@davinci.gmu.edu (Michael Benson), mbone From: Henning Schulzrinne <schulzrinne@fokus.gmd.de> X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Re: A couple questions In-Reply-To: Your message of "Wed, 20 Sep 1995 17:43:10 PDT." <199509210043.RAA23581@Csli.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Sep 1995 09:30:34 +0200 Sender: schulzrinne@fokus.gmd.de > > I also wonder about RTPv2-based audio tools? Will UCL+INRIA's tool > be RTP-based? I guess so? I'd be surprised if it weren't... > > Is nevot RTP-based? And where is it, I haven't found it linked up > from anywhere yet. Yes. Check out the RTP/AVT page at http://www.fokus.gmd.de/step/rtp > > I am also interested in anyone who has experience in trying to sync > the audio and video of higher-bandwidth streams, around 1 Mbps. > My current plan is to write a 'sync-monitor' that syncronized > the media-streams coming in over the network, and then deliver the > streams independantly through local delivery to the proper tools. > (local == localhost for example.) > > And yet another question (turning into a FAQ-section almost), > is where is the rtp_testbed source code? There is rtpdump, which does RTP parsing. Most of the slightly more involved pieces of RTP handling can be gotten from the implementations. However, in most cases, the RTP part is relatively straightforward, not very performance critical and easy to test. Coding and other signal processing is the hard part... Henning From list-mgr@ISI.EDU Thu Sep 21 12:39:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09397>; Thu, 21 Sep 1995 01:43:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09371>; Thu, 21 Sep 1995 01:40:01 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-22) id <AA09364>; Thu, 21 Sep 1995 01:39:53 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id KAA26353 (8.6.12/7.4g-FAU);; Thu, 21 Sep 1995 10:39:31 +0200 From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de> Message-Id: <199509210839.KAA26353@faui40.informatik.uni-erlangen.de> Subject: Re: A couple questions To: cwe@Csli.Stanford.EDU (Christian Wettergren) Date: Thu, 21 Sep 1995 10:39:29 +0200 (MET DST) Cc: M.Handley@cs.ucl.ac.uk, mbenson@davinci.gmu.edu, mbone In-Reply-To: <199509210043.RAA23581@Csli.Stanford.EDU> from "Christian Wettergren" at Sep 20, 95 05:43:10 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 523 > What is the interface for the audio modules? I'd be most happy > to get "richer" audio format, that samples at higher freq. > (I'm no audio guy, but I'm under the probably wrong impression > that higher sampling rate might increase the quality - if one > has the bandwidth. Am I wrong there?) Yes, Yes, i support the motion. I am pleading for this for years. I'd especially like to get mpeg encoded audio into VAT. (You know: i never got an answer from the VAT folks, but you surely would have guessed that). Toerless From list-mgr@ISI.EDU Thu Sep 21 13:25:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10542>; Thu, 21 Sep 1995 02:29:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10514>; Thu, 21 Sep 1995 02:26:17 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA10506>; Thu, 21 Sep 1995 02:26:02 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id LAA02466; Thu, 21 Sep 1995 11:24:00 +0200 Message-Id: <199509210924.LAA02466@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de> Cc: mbone Subject: Re: A couple questions In-Reply-To: Your message of "Thu, 21 Sep 1995 10:39:29 +0200." <199509210839.KAA26353@faui40.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Sep 1995 11:25:01 +0200 From: Magnus <e93_mda@it.kth.se> > > What is the interface for the audio modules? I'd be most happy > > to get "richer" audio format, that samples at higher freq. > > (I'm no audio guy, but I'm under the probably wrong impression > > that higher sampling rate might increase the quality - if one > > has the bandwidth. Am I wrong there?) No. > > Yes, Yes, i support the motion. I am pleading for this for years. > I'd especially like to get mpeg encoded audio into VAT. > (You know: i never got an answer from the VAT folks, but you surely would > have guessed that). > > Toerless > For those which have a lot of bandwidth to waste would just plain 16 bit audio in 32 kHz, 44.1 kHz and 48 kHz be most welcome, since there is more audio devices that support such speeds. They will also work with AES/EBU interfaces and SPDIF (consummer digital) interface. Not to talk about a hole bunch of standard equipment for digital audio. I do not say that it should be the prefered transmission channel for such data, but in some cases worth considering. Question is, should this issue be discussed on the mbone list or not. Magnus KTH/IT From list-mgr@ISI.EDU Thu Sep 21 14:20:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11211>; Thu, 21 Sep 1995 03:38:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11178>; Thu, 21 Sep 1995 03:37:29 -0700 Received: from artemis.rus.uni-stuttgart.de by venera.isi.edu (5.65c/5.61+local-22) id <AA11152>; Thu, 21 Sep 1995 03:32:51 -0700 Received: from kssun7.rus.uni-stuttgart.de (kssun7.rus.uni-stuttgart.de [193.196.152.1]) by artemis.rus.uni-stuttgart.de with SMTP id MAA04240 (8.6.12/IDA-1.6); Thu, 21 Sep 1995 12:28:30 +0200 Received: by kssun7.rus.uni-stuttgart.de (4.1/BelWue-1.2SUN) id AA04607; Thu, 21 Sep 95 12:20:04 +0200 Date: Thu, 21 Sep 95 12:20:04 +0200 From: Schulz@RUS.Uni-Stuttgart.DE (Claus-Dieter Schulz) Message-Id: <9509211020.AA04607@kssun7.rus.uni-stuttgart.de> To: Toerless.Eckert@informatik.uni-erlangen.de, e93_mda@it.kth.se Subject: Re: A couple questions Cc: mbone > > For those which have a lot of bandwidth to waste would just plain 16 bit audio > in 32 kHz, 44.1 kHz and 48 kHz be most welcome, since there is more audio > devices that support such speeds. Sure we have to stick to these standard sampling rates. But I think no one wants to waste any bandwidth. It's easy to put some simple, easy to implement compression scheme in and get free bandwitdth for video or more audio channels. > They will also work with AES/EBU interfaces > and SPDIF (consummer digital) interface. Not to talk about a hole bunch of > standard equipment for digital audio. But that does relate only to the signal before encoding or after decoding. Claus-Dieter From list-mgr@ISI.EDU Thu Sep 21 12:35:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11378>; Thu, 21 Sep 1995 03:41:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11193>; Thu, 21 Sep 1995 03:37:44 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA11186>; Thu, 21 Sep 1995 03:37:43 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA01242>; Thu, 21 Sep 1995 03:37:37 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.08887-0@bells.cs.ucl.ac.uk>; Thu, 21 Sep 1995 11:35:51 +0100 From: Mark Handley <M.Handley@cs.ucl.ac.uk> Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: Christian Wettergren <cwe@Csli.Stanford.EDU> Cc: mbenson@davinci.gmu.edu (Michael Benson), mbone Subject: Re: A couple questions In-Reply-To: Your message of "Wed, 20 Sep 95 17:43:10 PDT." <199509210043.RAA23581@Csli.Stanford.EDU> Date: Thu, 21 Sep 95 11:35:42 +0100 Message-Id: <13125.811679742@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >| >5) Is there any work underway for better compression methods (or plug in >| > compression routines) to be put into VAT? >| >| Give Van the compression module and ask nicely... > >What is the interface for the audio modules? I'd be most happy >to get "richer" audio format, that samples at higher freq. >(I'm no audio guy, but I'm under the probably wrong impression >that higher sampling rate might increase the quality - if one >has the bandwidth. Am I wrong there?) You're correct. Also as ADPCM is really not so expensive, you can get improved quality audio from 16KHz sampled ADPCM for the same bandwidth as 8KHz PCM and still have cycles left for video. It's on our "to do" list, along with 1001 other things... >| There are also other experimental audio tools either available (nevot) >| or shortly to be available (UCL + INRIA work). Any particular >| compression schemes you'd like to see? > >I also wonder about RTPv2-based audio tools? Will UCL+INRIA's tool >be RTP-based? I guess so? Yes >I am also interested in anyone who has experience in trying to sync >the audio and video of higher-bandwidth streams, around 1 Mbps. >My current plan is to write a 'sync-monitor' that syncronized the media-streams coming in over the network, and then deliver the >streams independantly through local delivery to the proper tools. >(local == localhost for example.) Isidor Kouvelas here modified a vic to lip-sync to audio from Vicky Hardman's experimental RTPv2 audio tool a month or so ago. This code is still very experimental, but we hope it will feed through into later versions of vic. Van described this 18 months ago in one of the MICE seminars and again at Sigcomm '94 - you just need to have your audio and video tools adapt their playout buffers in a cooperative manner - it's not really complicated but it does significantly impact the design of your video tool, and requires an RTP based audio tool. >And yet another question (turning into a FAQ-section almost), >is where is the rtp_testbed source code? > >Many questions, indeed. > >Regards, > Christian Wettergren > KTH/Teleinformatics > From list-mgr@ISI.EDU Thu Sep 21 08:25:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20537>; Thu, 21 Sep 1995 09:25:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20525>; Thu, 21 Sep 1995 09:25:29 -0700 Received: from bus.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA20518>; Thu, 21 Sep 1995 09:25:28 -0700 Received: (dschluss@localhost) by bus.engin.umich.edu (8.6.12/8.6.4) id MAA00440; Thu, 21 Sep 1995 12:25:17 -0400 Date: Thu, 21 Sep 1995 12:25:15 -0400 (EDT) From: "david a. schlussel" <dschluss@engin.umich.edu> To: cjh@hic.etri.re.kr Cc: mbone Subject: Re: transmit MBONE stream to cu-seeme? In-Reply-To: <199509210149.KAA16748@hic.etri.re.kr> Message-Id: <Pine.SOL.3.91.950921122511.367D-100000@bus.engin.umich.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII see my home page +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ On Thu, 21 Sep 1995 cjh@hic.etri.re.kr wrote: > Anyone know how MBONE stream(Video/Audio) transmit to cu-seem via reflector? > I have Solaris 2.4, SunVideo board and reflector. > I know that reflector can send nv stream to cu-seeme(Windows version)? > But it does not work, I can't see anything. > help me. > -- > -------------------------------------------------------------------------------- > Choi JoonHyuk > Service Architectur Section > E-Mail:cjh@hic.etri.re.kr > Phone :042-860-6770 > http://hic.etri.re.kr > -------------------------------------------------------------------------------- > > From list-mgr@ISI.EDU Thu Sep 21 09:08:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22791>; Thu, 21 Sep 1995 10:11:26 -0700 Received: from nic.near.net by venera.isi.edu (5.65c/5.61+local-22) id <AA22784>; Thu, 21 Sep 1995 10:11:25 -0700 Received: from wpine.com by nic.near.net id aa21525; 21 Sep 95 13:11 EDT Received: from visual.wpine.com by wpnext.wpine.com (8.6.9/WM-941104.2) id NAA01943; Thu, 21 Sep 1995 13:11:26 -0400 Received: from boggs.wpine.com.wpine.com by visual.wpine.com (8.6.9/VM-941107.1) id NAA25010; Thu, 21 Sep 1995 13:13:38 -0400 Received: by boggs.wpine.com.wpine.com (4.1/VN941029.1) id AA08423; Thu, 21 Sep 95 13:08:07 EDT Message-Id: <9509211708.AA08423@boggs.wpine.com.wpine.com> To: mbone-na Cc: dbundy@wpine.com Subject: Suitable tunnel site. Date: Thu, 21 Sep 1995 13:08:06 -0400 From: Brian O'Shea <boshea@wpine.com> Hi, I'm looking for the best site to tunnel to. We will need occasional access to the MBONE, but I don't beleive we can support the traffic that would be generated on a regular basis. Our main offices are in Nashua, where we have our internet connection. Unfortunately, our internet providers table of tunnels is full, so we must use a tunnel to another site. As a quick experiment I tunneled to cornell, which worked fine, but that's not a long term solution. Our internet provider suggested a tunnel to Dartmouth? The IP address of the machine I will be running mrouted on is 192.80.72.4. I want to be connected in time to connect to the MBONE Monday or Tuesday next week. There is a broadcast from the Atlanta BNetworld+InterOP that I want to receive on Wednesday (9/27) and Thursday (9/28) next week. Thank you.. -bos +***********************************************************************+ + Brian O'Shea White Pine Software + + Network/OS Software Engineer 15 Messenger Square + + boshea@wpine.com Suite 8A + + Voice 508-699-9163 Fax 508-695-2378 Plainville MA, 02762 + + All it takes is all you've got. + +***********************************************************************+ From list-mgr@ISI.EDU Thu Sep 21 11:48:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00437>; Thu, 21 Sep 1995 12:49:15 -0700 Received: from portal.netedge.com by venera.isi.edu (5.65c/5.61+local-22) id <AA00430>; Thu, 21 Sep 1995 12:49:13 -0700 Received: from NetEdge.COM by portal.netedge.com id AA23314; Thu, 21 Sep 95 15:48:47 EDT Received: from suicidesix.NetEdge.COM by NetEdge.COM id AA29220; Thu, 21 Sep 95 15:49:06 EDT Return-Path: <Tom_Pusateri@NetEdge.COM> Received: from localhost by suicidesix.NetEdge.COM (4.1/NECL-6.14) id AA05471; Thu, 21 Sep 95 15:48:45 EDT Message-Id: <9509211948.AA05471@NetEdge.COM> To: Brian O'Shea <boshea@wpine.com> Cc: mbone-na, dbundy@wpine.com Subject: Re: Suitable tunnel site. In-Reply-To: Your message of "Thu, 21 Sep 1995 13:08:06 EDT." <9509211708.AA08423@boggs.wpine.com.wpine.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <5468.811712924.1@suicidesix.netedge.com> Date: Thu, 21 Sep 1995 15:48:45 -0400 From: Thomas Pusateri <pusateri@NetEdge.COM> In message <9509211708.AA08423@boggs.wpine.com.wpine.com> you write: > >Hi, > >I'm looking for the best site to tunnel to. We will need occasional access to >the MBONE, but I don't beleive we can support the traffic that would be >generated on a regular basis. Our main offices are in Nashua, where we have >our internet connection. >Unfortunately, our internet providers table of tunnels is full... I didn't realize there was a configurable limit. Anyway, I would think that your provider would want to discourage transit tunnels as much as possible. This is probably going to degrade the quality on all of their existing tunnels. Tom From list-mgr@ISI.EDU Thu Sep 21 12:23:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02082>; Thu, 21 Sep 1995 13:24:38 -0700 Received: from bbnplanet.com (poblano.near.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA02071>; Thu, 21 Sep 1995 13:24:35 -0700 Subject: Suitable tunnel site. (fwd) To: mbone-na Date: Thu, 21 Sep 1995 16:23:54 -0400 (EDT) From: Henry Clark <hclark@bbnplanet.com> X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1536 Message-Id: <9509211623.aa18807@poblano.bbnplanet.com> We'll fix him up. henry Forwarded message: > Message-Id: <9509211708.AA08423@boggs.wpine.com.wpine.com> > To: mbone-na@isi.edu > Cc: dbundy@wpine.com > Subject: Suitable tunnel site. > Date: Thu, 21 Sep 1995 13:08:06 -0400 > From: Brian O'Shea <boshea@wpine.com> > > > Hi, > > I'm looking for the best site to tunnel to. We will need occasional access to > the MBONE, but I don't beleive we can support the traffic that would be > generated on a regular basis. Our main offices are in Nashua, where we have > our internet connection. Unfortunately, our internet providers table of > tunnels is full, so we must use a tunnel to another site. As a quick > experiment I tunneled to cornell, which worked fine, but that's not a long > term solution. Our internet provider suggested a tunnel to Dartmouth? The IP > address of the machine I will be running mrouted on is 192.80.72.4. I want to > be connected in time to connect to the MBONE Monday or Tuesday next week. > There is a broadcast from the Atlanta BNetworld+InterOP that I want to receive > on Wednesday (9/27) and Thursday (9/28) next week. > > Thank you.. > > -bos > > +***********************************************************************+ > + Brian O'Shea White Pine Software + > + Network/OS Software Engineer 15 Messenger Square + > + boshea@wpine.com Suite 8A + > + Voice 508-699-9163 Fax 508-695-2378 Plainville MA, 02762 + > + All it takes is all you've got. + > +***********************************************************************+ From list-mgr@ISI.EDU Fri Sep 22 07:47:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09814>; Fri, 22 Sep 1995 08:47:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09787>; Fri, 22 Sep 1995 08:47:05 -0700 Received: from calvin.dgbt.doc.ca ([142.92.36.41]) by venera.isi.edu (5.65c/5.61+local-22) id <AA09778>; Fri, 22 Sep 1995 08:47:02 -0700 Received: by calvin.dgbt.doc.ca (4.1/SMI-4.1) id AA01682; Fri, 22 Sep 95 11:47:01 EDT Date: Fri, 22 Sep 95 11:47:01 EDT From: andrew@calvin.dgbt.doc.ca (Andrew Patrick) Message-Id: <9509221547.AA01682@calvin.dgbt.doc.ca> Reply-To: andrew@calvin.dgbt.doc.ca X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: mbone Subject: WB Question I am setting up WhiteBoard (Version 1.59) to handle PostScript slides using 'gs'. I am using the Usenix LISA slides to test with. The platform is a Sun SPARC 2 running SunOS 4.1.4. WB and gs seem to be working fine, but when I try to view the LISA slides in landscape mode the lower 1/3 of the slide is blank. The slides look fine when I select the portrait button in WB, but it is a little hard to read sideways. Anyone seen this before? Is this normal behaviour for WB? -- Andrew Patrick, Ph.D. andrew@calvin.dgbt.doc.CA <HTML> The Authoring Language for the World Wide Web </HTML> A 2-day training seminar, Oct 4-5, 1995, Ottawa. See http://debra.dgbt.doc.ca or contact me for details. From list-mgr@ISI.EDU Fri Sep 22 07:55:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10144>; Fri, 22 Sep 1995 08:55:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10128>; Fri, 22 Sep 1995 08:55:19 -0700 Received: from philabs.philips.com by venera.isi.edu (5.65c/5.61+local-22) id <AA10121>; Fri, 22 Sep 1995 08:55:18 -0700 Received: from frank.philabs.philips.com (frank.philabs.philips.com [130.140.55.10]) by philabs.philips.com (8.6.11/8.6.12) with SMTP id LAA13819 for <mbone@isi.edu>; Fri, 22 Sep 1995 11:55:16 -0400 From: brf@philabs.philips.com Received: from loopback by frank.philabs.philips.com (4.1/SMI-4.1) id AA25044; Fri, 22 Sep 95 11:55:15 EDT Message-Id: <9509221555.AA25044@frank.philabs.philips.com> To: mbone Cc: brf@philabs.philips.com, rxf@philabs.philips.com Subject: IP multicast support in 10/100 Enet Switches Date: Fri, 22 Sep 95 11:55:14 -0400 Greetings, We have never met before but I hope you can help. I am designing a multimedia LAN and am very concerned about local high bandwidth IP multicast traffic congesting dedicated 10Mbit ports. A couple of quick questions: 1 - Besides cisco, is they other vendors who support IP multicast on a port by port level in Enet Switches? 2 - Do you know of others who have already done such research and came up with solutions? Any info related to this topic would be greatly appreciated. Thanks in advance... Bill ----------------------------------------------------------------------------- Bill Friday Internet: brf@philabs.philips.com Senior Network Administrator Communications and Computing Resources Philips Laboratories Voice: (914) 945-6087 345 Scarborough Road Briarcliff Manor, NY USA 10510 Fax: (914) 945-6511 ----------------------------------------------------------------------------- From list-mgr@ISI.EDU Fri Sep 22 21:30:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14802>; Fri, 22 Sep 1995 10:33:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14590>; Fri, 22 Sep 1995 10:31:35 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA14576>; Fri, 22 Sep 1995 10:31:32 -0700 Received: from pax.inria.fr by quark.isi.edu (5.65c/5.61+local-20) id <AA17413>; Fri, 22 Sep 1995 10:31:28 -0700 Received: by pax.inria.fr (8.6.12/8.6.12) id TAA27869; Fri, 22 Sep 1995 19:30:01 +0200 Message-Id: <199509221730.TAA27869@pax.inria.fr> To: mice@cs.ucl.ac.uk, hipparch@sophia.inria.fr, mbone Subject: W3C/INRIA job offer Date: Fri, 22 Sep 1995 19:30:00 +0200 From: Walid Dabbous <Walid.Dabbous@sophia.inria.fr> Dear collegue, Could you please forward this job offer around you or send it to interested persons you may know. thanks, Walid Dabbous sorry if you receive multiple copies! ---------------------------- W3C/INRIA seeks a software designer to work in the integration of WWW and real-time protocols. The position is at INRIA Sophia Antipolis, for two years. The support of real-time services in WWW may be done through a variation of the access protocol. If the document is audio and video, and if the client request real-time rendition IETF's RTP may be used. On the other hand, RTP provides feedback to the application as to the bandwidth available, latencies and jitters, together with an indication of the rate of data loss. The information provided may be used to do some sort of rate based congestion control. This will ease the application flow control for real time traffic. The person will be responsible for a protocol integration framework, as well as experimental implementations. Qualifications: A BSc or above in Computer Science or related discipline. Working knowledge of TCP/IP, RTP, HTTP and HTML. Please send resume to Hakon.Lie@inria.fr and/or Walid.Dabbous@inria.fr Walid Dabbous INRIA U.R. de Sophia Antipolis | Email : dabbous@sophia.inria.fr 2004, Route des Lucioles BP 93 | Phone : +33 93 65 77 18 06902 Sophia Antipolis CEDEX France | Fax : +33 93 65 77 65 From list-mgr@ISI.EDU Fri Sep 22 11:49:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21408>; Fri, 22 Sep 1995 12:50:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21391>; Fri, 22 Sep 1995 12:49:33 -0700 Received: from cayenne.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA21383>; Fri, 22 Sep 1995 12:49:28 -0700 Received: by cayenne.lcs.mit.edu; id AA02847; Fri, 22 Sep 1995 15:49:23 -0400 Message-Id: <9509221949.AA02847@cayenne.lcs.mit.edu> To: mbone Cc: mbone@mit.edu Subject: Request for a tunnel Date: Fri, 22 Sep 95 15:49:23 -0400 From: turletti@cayenne.lcs.mit.edu X-Mts: smtp I'm looking for an mbone feed closer to MIT. I retrieved the 101318-69.tar.Z and Solaris_mc33.2.3.tar.Z patches and installed them on my Solaris 2.3 platform (sorrel.lcs.mit.edu). The IP address of my tunnel endpoint is 18.31.0.130. Thanks in advance, Thierry Turletti --------- Telemedia, Networks, and Systems e-mail: turletti@lcs.mit.edu Laboratory for Computer Science ivs-site: salt.lcs.mit.edu Massachussets Institute of Technology Phone: (617) 258-8270 NE43-505, 545 Technology Square Fax: (617) 253-2673 Cambridge, MA 021139 http://www.tns.lcs.mit.edu/~turletti/ From list-mgr@ISI.EDU Sat Sep 23 08:45:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26019>; Sat, 23 Sep 1995 09:43:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26004>; Sat, 23 Sep 1995 09:42:57 -0700 Received: from FAUST.BBN.SAN-DIEGO.CA.US ([199.56.164.6]) by venera.isi.edu (5.65c/5.61+local-22) id <AA25997>; Sat, 23 Sep 1995 09:42:55 -0700 Received: (mfausett@localhost) by FAUST.BBN.SAN-DIEGO.CA.US (8.6.10/8.6.4) id MAA01625 for mbone@ISI.EDU; Sat, 23 Sep 1995 12:45:11 -0400 Date: Sat, 23 Sep 1995 12:45:11 -0400 From: "Mark L. Fausett" <mfausett@BBN.COM> Message-Id: <199509231645.MAA01625@FAUST.BBN.SAN-DIEGO.CA.US> To: mbone Subject: Re: [Q] MBONE through satellite I'm using it with relative success through: Satellite links, high-latency land lines (eg often 800-1600 ms delays). various mixtures of the above. No worries, watch packet loss real carefully; mf > Does anyone tried MBONE connection through satellite channel? > If someone decide to connect internet through satellite, how can he realize > it with current technology, and what will be the major problems? > Thanks in advance... > -Jung Joowon From list-mgr@ISI.EDU Sat Sep 23 11:52:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28854>; Sat, 23 Sep 1995 11:53:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28847>; Sat, 23 Sep 1995 11:52:42 -0700 Received: from lassie.eunet.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA28840>; Sat, 23 Sep 1995 11:52:39 -0700 Received: from linux.travel.fi by lassie.eunet.fi with SMTP id AA10828 (5.67a/IDA-1.5 for <mbone@isi.edu>); Sat, 23 Sep 1995 21:52:30 +0300 Received: by linux.travel.fi (8.6.12/20-jun-90) id VAA24953; Sat, 23 Sep 1995 21:54:15 +0300 Date: Sat, 23 Sep 1995 21:54:14 +0300 (EET DST) From: Rauno Tuhkanen <rtuhkane@travel.fi> To: mbone Message-Id: <Pine.LNX.3.91.950923215327.24945A-100000@linux.travel.fi> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII UNSUBSCRIBE mbone From list-mgr@ISI.EDU Sun Sep 24 02:21:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20504>; Sun, 24 Sep 1995 09:23:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20474>; Sun, 24 Sep 1995 09:21:15 -0700 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA20467>; Sun, 24 Sep 1995 09:21:13 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA09338 (5.65c/IDA-1.4.4nsd for <mbone@isi.edu>); Sun, 24 Sep 1995 09:21:06 -0700 Received: by jaspar.NSD.3Com.COM id AA18870 (5.65c/IDA-1.4.4-910730 for mbone@isi.edu); Sun, 24 Sep 1995 09:21:01 -0700 From: "Cyndi M. Jung" <cmj@NSD.3Com.COM> Message-Id: <199509241621.AA18870@jaspar.NSD.3Com.COM> Subject: NET 45.0.0.0 255.0.0.0 To: mbone Date: Sun, 24 Sep 1995 09:21:01 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 228 Could whoever is advertising 45.0.0.0 255.0.0.0 into MBONE please stop. We're trying to attach the Interop network to the MBONE, and when the tunnel comes up we hear this route - but it is our net number! Thanks, Cyndi Jung From list-mgr@ISI.EDU Sun Sep 24 02:55:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21169>; Sun, 24 Sep 1995 09:56:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21154>; Sun, 24 Sep 1995 09:55:28 -0700 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA21147>; Sun, 24 Sep 1995 09:55:27 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA11142 (5.65c/IDA-1.4.4nsd for <mbone@isi.edu>); Sun, 24 Sep 1995 09:55:17 -0700 Received: by jaspar.NSD.3Com.COM id AA18946 (5.65c/IDA-1.4.4-910730 for mbone@isi.edu); Sun, 24 Sep 1995 09:55:23 -0700 From: "Cyndi M. Jung" <cmj@NSD.3Com.COM> Message-Id: <199509241655.AA18946@jaspar.NSD.3Com.COM> Subject: NET 45.0.0.0 255.0.0.0 (fwd) To: mbone Date: Sun, 24 Sep 1995 09:55:22 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 410 Well, we still can't find it, but it goes away everywhere if we turn our tunnel off. It must be coming from us! Only just a little embarrassing ... Cyndi > > > > Could whoever is advertising 45.0.0.0 255.0.0.0 into MBONE please stop. > We're trying to attach the Interop network to the MBONE, and when the > tunnel comes up we hear this route - but it is our net number! > > Thanks, > Cyndi Jung > From list-mgr@ISI.EDU Sun Sep 24 03:28:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21940>; Sun, 24 Sep 1995 10:30:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21933>; Sun, 24 Sep 1995 10:28:52 -0700 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA21926>; Sun, 24 Sep 1995 10:28:51 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA13032 (5.65c/IDA-1.4.4nsd for <mbone@isi.edu>); Sun, 24 Sep 1995 10:28:43 -0700 Received: by jaspar.NSD.3Com.COM id AA19010 (5.65c/IDA-1.4.4-910730 for mbone@isi.edu); Sun, 24 Sep 1995 10:28:46 -0700 From: "Cyndi M. Jung" <cmj@NSD.3Com.COM> Message-Id: <199509241728.AA19010@jaspar.NSD.3Com.COM> Subject: NET 45.0.0.0 To: mbone Date: Sun, 24 Sep 1995 10:28:45 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 560 Since I bothered you all - We changed the termination point of our end of the tunnel to an IP address (on the same machine) that is on NET 45 - and the problem went away. We aren't sure if this is a spec-type problem or an implementation problem - perhaps the folkloric wisdom of DVMRP says you never use an IP address that is not "inside" your network (we used the interface address that was "closest" to the other end of the tunnel - which was on a class C network we use for our demarc). Things are looking better now - it was very interesting. Cyndi From list-mgr@ISI.EDU Mon Sep 25 12:25:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02862>; Mon, 25 Sep 1995 13:25:31 -0700 Received: from foyer.homecom.com by venera.isi.edu (5.65c/5.61+local-22) id <AA02855>; Mon, 25 Sep 1995 13:25:23 -0700 Received: from basement.homecom.com (basement.homecom.com [204.198.148.11]) by foyer.homecom.com (8.6.12/8.6.5) with ESMTP id QAA03043 for <mbone-na@isi.edu>; Mon, 25 Sep 1995 16:25:05 -0400 Received: (brian@localhost) by basement.homecom.com (8.6.12/8.6.5) id QAA11946 for mbone-na@isi.edu; Mon, 25 Sep 1995 16:25:14 -0400 From: Brian Atkins <brian@homecom.com> Message-Id: <199509252025.QAA11946@basement.homecom.com> Subject: Newbie needs some help To: mbone-na Date: Mon, 25 Sep 1995 16:25:14 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3327 I'm trying to get us hooked up to the mbone here at work. I have a tunnel configured to one of Suranet's machines: 192.221.9.242. The tunnel goes to our Indy(204.198.148.64), which is running Irix5.3 and mrouted3.4. I seem to get sd data fine... although it is somewhat slow, and not all the sites show up. For instance, as soon as I start it up I can see radio free vat, mbone video, etc. Then maybe a while later, the NASA feeds show up. And that is it. I get none of the congress stuff, or talk radio. Perhaps this is just a problem with low ttls ? The more serious problem is that once I pick a conference to join, I don't get any of the info from it. Say I pick both the NASA feeds. vat and nv start up, and vat shows me many many people listening in. Yet even if I leave them sitting there for hours, I get no sound or video data. So that is the main problem I am trying to figure out: why I get sd data ok, but nothing else. Here is the mrouted.conf: tunnel 204.198.148.64 192.221.9.242 metric 1 threshold 32 I did a traceroute, and besides our Cisco2500 router there were a couple of others between here and Sura, so should the metric be higher? I'm not sure what other data I need to provide... here is the dump file from a kill -USR1: Virtual Interface Table Vif Name Local-Address M Thr Rate Flags 0 ec0 204.198.148.64 subnet: 204.198.148 1 1 0 querier groups: 224.2.253.119 224.2.127.255 224.0.0.4 pkts in : 16813 pkts out: 55593 1 ec0 204.198.148.64 tunnel: 192.221.9.242 1 32 0 peers: 192.221.9.242 (0.0) pkts in : 16813 pkts out: 55593 Multicast Routing Table (1820 entries) Origin-Subnet From-Gateway Metric In-Vif Out-Vifs 36 192.221.9.242 9 1 0* 35.8 192.221.9.242 11 1 0* 128.6 192.221.9.242 12 1 0* 128.10 192.221.9.242 10 1 0* 128.32 192.221.9.242 12 1 0* 128.39 192.221.9.242 9 1 0* 128.46 192.221.9.242 10 1 0* 128.52 192.221.9.242 12 1 0* 128.55 192.221.9.242 10 1 0* 128.93 192.221.9.242 8 1 0* 128.100 192.221.9.242 15 1 0* 128.110 192.221.9.242 14 1 0* 128.118 192.221.9.242 13 1 0* 128.119 192.221.9.242 10 1 0* 128.141 192.221.9.242 9 1 0* 128.174 192.221.9.242 12 1 0* 128.185 192.221.9.242 10 1 0* 128.210 192.221.9.242 10 1 0* 128.211 192.221.9.242 10 1 0* 128.214 192.221.9.242 9 1 0* 128.219 192.221.9.242 13 1 0* 128.223 192.221.9.242 17 1 0* 128.235 192.221.9.242 12 1 0* 129.20 192.221.9.242 8 1 0* [truncated] any help would be appreciated! -- Brian Atkins Web and more hacker at Homecom(http://www.homecom.com) From list-mgr@ISI.EDU Mon Sep 25 07:39:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06545>; Mon, 25 Sep 1995 14:40:17 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA06535>; Mon, 25 Sep 1995 14:40:14 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14497(5)>; Mon, 25 Sep 1995 14:39:58 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Mon, 25 Sep 1995 14:39:43 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Brian Atkins <brian@homecom.com> Cc: mbone-na, multicast@sura.net Subject: Re: Newbie needs some help In-Reply-To: Your message of "Mon, 25 Sep 95 13:25:14 PDT." <199509252025.QAA11946@basement.homecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Sep 1995 14:39:34 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Sep25.143943pdt.177475@crevenia.parc.xerox.com> In message <199509252025.QAA11946@basement.homecom.com> you write: >I get none of the congress stuff, or talk radio. Perhaps >this is just a problem with low ttls ? No, this is a problem with routes (see below) >The more serious problem is that once I pick a conference to join, I don't >get any of the info from it. Say I pick both the NASA feeds. vat and nv >start up, and vat shows me many many people listening in. Yet even if I >leave them sitting there for hours, I get no sound or video data. That's because nobody is transmitting on the NASA session yet. I would volunteer to speak up on MBONE Audio so that you know that things are working, but your routing problem (see below) precludes that. >I did a traceroute, and besides our Cisco2500 router there were a couple >of others between here and Sura, so should the metric be higher? No, your mrouted.conf is fine. The metric is for the multicast route, not the unicast route, and there is only one multicast hop (the tunnel). >Multicast Routing Table (1820 entries) Here is your problem, you are missing about 30% of the routes that make up the MBONE. My multicast router has 2600 routes. (If you don't have a route for a source, you can't receive traffic from that source.) I guess I am somewhat suspicious of lex-mp1.sura.net, as I have heard strange problem reports from tunnels with Proteons before, and nobody has ever characterized the problem completely. Perhaps the proteon is dropping routes...? Bill From list-mgr@ISI.EDU Mon Sep 25 13:52:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07511>; Mon, 25 Sep 1995 14:56:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07346>; Mon, 25 Sep 1995 14:53:36 -0700 Received: from davinci.gmu.edu ([206.197.101.10]) by venera.isi.edu (5.65c/5.61+local-22) id <AA07321>; Mon, 25 Sep 1995 14:53:33 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for mbone@isi.edu id RAA21283; Mon, 25 Sep 1995 17:52:40 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199509252152.RAA21283@davinci.gmu.edu> Subject: Question for creating tunnel without mrouted To: mbone Date: Mon, 25 Sep 1995 17:52:40 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 599 I am in need of creating a tunnel between two sites. One end of a site needs to be Linux which doesn't currently support mrouted. The other end can be Linux, SGI or SUN. Since I can not route packets using mrouted, is there another way of creating a static route between these systems? From my previous email here recently, I also assume there is NO ONE working on an mrouted program for Windows NT? Michael -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Tue Sep 26 09:51:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01485>; Tue, 26 Sep 1995 14:51:09 -0700 Received: from ncar.ucar.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA01478>; Tue, 26 Sep 1995 14:51:07 -0700 Received: from niwot.scd.ucar.EDU by ncar.ucar.EDU (NCAR-local/ NCAR Central Post Office 03/11/93) id PAA24234; Tue, 26 Sep 1995 15:51:05 -0600 Received: from triceratops.scd.ucar.edu by niwot.scd.ucar.EDU (NCAR-local/ NCAR Mail Server 04/10/90) id PAA24658; Tue, 26 Sep 1995 15:51:05 -0600 Received: from localhost by triceratops.scd.ucar.edu via SMTP (940816.SGI.8.6.9/930416.SGI) for <mbone-na@isi.edu> id PAA26736; Tue, 26 Sep 1995 15:51:04 -0600 Message-Id: <199509262151.PAA26736@triceratops.scd.ucar.edu> To: mbone-na Reply-To: hyder@ncar.ucar.edu Subject: NCAR Mbone connectivity is down Date: Tue, 26 Sep 1995 15:51:03 -0600 From: Paul Hyder <hyder@triceratops.scd.ucar.edu> We had this snow storm last Thursday that brought down many of the trees here in Boulder, CO. Unfortunately a large number of these trees landed on power and phone lines. We have been working to get network linkage patched since then. At this time mbone connectivity via NCAR is down. Sites that are leaf nodes from NCAR will not see the Mbone. From what I can tell based on queries and complaints this includes the NWnet area and a significant portion of the central US. The regional connectivity here is up and awaiting re-connection to the central Mbone. I'll advise the list when connectivity is restored. Paul Hyder Network Engineer National Center for Atmospheric Research(NCAR) Boulder, CO 80307-3000 FYI: This is also a good example of the current topology flux on the Mbone. Our redundant connectivity had been via NWnet, however their tunnel to BARRnet was dropped a few months back. We've been working on getting the Mbone shifted to the vBNS and as part of that our commodity tunnel to NCSA was also recently dropped by them. The current situation is that our vBNS linkage is still down after the storm. From list-mgr@ISI.EDU Wed Sep 27 09:23:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18506>; Wed, 27 Sep 1995 14:24:01 -0700 Received: from ncar.ucar.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA18499>; Wed, 27 Sep 1995 14:23:59 -0700 Received: from niwot.scd.ucar.EDU by ncar.ucar.EDU (NCAR-local/ NCAR Central Post Office 03/11/93) id PAA23620; Wed, 27 Sep 1995 15:23:57 -0600 Received: from mrbean.scd.ucar.edu.scd.ucar.EDU by niwot.scd.ucar.EDU (NCAR-local/ NCAR Mail Server 04/10/90) id PAA26198; Wed, 27 Sep 1995 15:23:49 -0600 Message-Id: <199509272123.PAA01969@mrbean.scd.ucar.edu> Received: from LOCALHOST by mrbean.scd.ucar.edu (NCAR-local/ NCAR Mail Client 04/19/90) id PAA01969; Wed, 27 Sep 1995 15:23:48 -0600 To: mbone-na Cc: cgarner@westnet.net, curtis@plains.nodak.edu, ne@nwnet.net, meyer@frostbite-falls.uoregon.edu, dcmwood@spot.colorado.edu Reply-To: hyder@cpo.ucar.edu Subject: NCAR Mbone linkage back online Date: Wed, 27 Sep 95 15:23:37 -0600 From: hyder@niwot.scd.ucar.EDU The failed links at NCAR have been repaired. Mbone connectivity to leaf sites fed from here should be working. Please send email to mbone@ncar.ucar.edu if any continued problems are seen. Paul Hyder NCAR From list-mgr@ISI.EDU Fri Sep 29 05:56:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22741>; Fri, 29 Sep 1995 13:00:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22430>; Fri, 29 Sep 1995 12:56:39 -0700 Received: from hp.com by venera.isi.edu (5.65c/5.61+local-22) id <AA22423>; Fri, 29 Sep 1995 12:56:38 -0700 Received: from hpindlm.cup.hp.com by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA204314596; Fri, 29 Sep 1995 12:56:36 -0700 Received: by hpindlm.cup.hp.com (1.38.193.5/15.5+IOS 3.20+cup+OMrelay) id AA16337; Fri, 29 Sep 1995 12:56:16 -0700 From: Ming Ming Chen <mchen@hpindlm.cup.hp.com> Message-Id: <9509291956.AA16337@hpindlm.cup.hp.com> Subject: Kernel Assert mods To: fenner@parc.xerox.com Date: Fri, 29 Sep 95 12:56:15 PDT Cc: pusateri@hpindlm.cup.hp.com, mchen@hpindlm.cup.hp.com, clemenj@hpindlm.cup.hp.com, doug_cohol@hp6600.desk.hp.com, mbone, jgc@hpindlm.cup.hp.com Mailer: Elm [revision: 70.85.2.1] Hi Bill, IPM3.6 release has a problem to support pim assert. A while ago Tom has sent you the proposal about the two methods to fix the assert problem. Have you decided which one you will take and put in the next release ? (I've sent you a mail a couple of weeks ago, and I haven't got reply from you, so I try it again) Thanks Ming |Ming Ming Chen Hewlett Packard | |Information Network Division 19410 Homestead Road | |mchen@hpindlm.cup.hp.com Cupertino, CA 95014 | |408-447-2357 Mail Stop: 43LM | |_____________________________________________________________________________| ================================== Here is Tom's original mail > Bill, > I am sending you two alternatives for the assert problem. > > Alternative 1: > This uses IP addresses passed up to the routing protocol and uses > the if_addrlist as you suggested. Since there wasn't any an if_addrlist > associated with a tunnel ifp, this patch adds this by allocating a > MT_IFADDR mbuf and storing the remote tunnel address in the list. > This makes the use of IP addresses more complicated. > > Alternative 2: > This uses the existing vif number approach. It is a much simpler > change that doesn't require changing the igmpmsg structure and therefore > no changes to gated are required. It also doesn't require the extra mbuf > per tunnel interface to hold the remote address in the if_addrlist. > > I will let you decide which one you prefer. I can accomodate either. > > Thanks, > Tom > From list-mgr@ISI.EDU Fri Sep 29 06:30:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24351>; Fri, 29 Sep 1995 13:32:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24324>; Fri, 29 Sep 1995 13:31:49 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA24317>; Fri, 29 Sep 1995 13:31:47 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15115(1)>; Fri, 29 Sep 1995 13:31:31 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Fri, 29 Sep 1995 13:31:14 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Ming Ming Chen <mchen@hpindlm.cup.hp.com> Cc: fenner@parc.xerox.com, pusateri@netedge.com, pusateri@hpindlm.cup.hp.com, clemenj@hpindlm.cup.hp.com, doug_cohol@hp6600.desk.hp.com, mbone, jgc@hpindlm.cup.hp.com Subject: Re: Kernel Assert mods In-Reply-To: Your message of "Fri, 29 Sep 95 12:56:15 PDT." <9509291956.AA16337@hpindlm.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Sep 1995 13:30:58 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Sep29.133114pdt.177475@crevenia.parc.xerox.com> Ming, Very sorry for not replying; often if I don't reply to things right away because I have to think about them, they get completely buried in my inbox. We have decided that the for loop is O.K. in the upcall case, both for the NOCACHE and the WRONGVIF message, and that will be what is in our next release. Bill From list-mgr@ISI.EDU Wed Sep 30 22:33:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19611>; Sat, 30 Sep 1995 23:38:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19595>; Sat, 30 Sep 1995 23:37:41 -0700 Received: from radicalmedia.com by venera.isi.edu (5.65c/5.61+local-22) id <AA19588>; Sat, 30 Sep 1995 23:37:39 -0700 Received: (from phiber@localhost) by radicalmedia.com (8.6.12/8.6.12) id CAA06880; Sun, 1 Oct 1995 02:33:11 -0400 From: Mark Abene <phiber@radicalmedia.com> Message-Id: <199510010633.CAA06880@radicalmedia.com> Subject: MBONE and Solaris To: mbone Date: Sun, 1 Oct 1995 02:33:11 -0400 (EDT) Cc: van@ee.lbl.gov X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 446 So I've got an MBONE feed and mrouted running on our Solaris x86 2.4 box. I have but one request: since source code is still unavailable for the popular MBONE apps like sd, vat, vic, etc., perhaps the code maintainers would be kind enough to release binaries for Solaris on Intel platforms? Shouldn't be a big deal. I'm also curious as to the status of said source code and when it might be made available. -Mark Abene Radical Media, Inc. From list-mgr@ISI.EDU Sun Oct 1 11:05:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22532>; Sun, 1 Oct 1995 02:07:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22508>; Sun, 1 Oct 1995 02:05:57 -0700 Received: from zaphod.axion.bt.co.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA22501>; Sun, 1 Oct 1995 02:05:55 -0700 Message-Id: <199510010905.AA22501@venera.isi.edu> Received: from bt-web.bt.co.uk by zaphod.axion.bt.co.uk via DECnet inbound channel id <sg.23626-0@zaphod.axion.bt.co.uk>; Sun, 1 Oct 1995 10:05:51 +0100 X-Vms-To: R11F::ISI.EDU::MBONE To: mbone From: courtenay_j_m <courtenay_j_m@bt-web.bt.co.uk> Subject: mrouted under Solaris - please help (now) Date: Sun, 1 Oct 1995 10:05:51 +0100 This is a "now or never" request for help. It expires Monday, 2nd October at 1100 GMT. I will post again if I still need help after this time. Thanks in advance if you respond. I'm trying to get mrouted running on a Sparc 5 running Solaris 2.4 remotely from home. The mrouted package is the combined IP multicast amd mrouted to be found at playground.sun.com/pub/multicast (can't remember the precise tar file name at present: anyway it includes the substring 33.2.4, i.e. ipmulti v3.3 and mrouted 3.4, I think). I've run the install script (install.multi, I believe) and rebooted. mrouted doesn't appear in the processes table. I invoke it interactively and it just exits silently. So does mrinfo. No error messages, no entry in ps -elf. When I get in on Monday I will be physically moving the machine to where its parent mrouted can see it. So there is no tunnel pointing to it at present. But I'm sure it should be possible to get it to run even without this. There wasn't an mrouted.conf template with the distibution, so I copied a SunOS ipmulti3.3 mrouted.conf and edited in the correct local address. Still no joy. Again, thanks. Mark -- J Mark Courtenay tel. +44 1473 645423/640871 MLB 4 15/ADMIN 2 OP4 fax. +44 1473 620101/640709 BT Labs, Martlesham Heath Ipswich, UK IP5 7RE courtejm@boat.bt.co.uk From list-mgr@ISI.EDU Sun Oct 1 11:32:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23005>; Sun, 1 Oct 1995 02:32:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22998>; Sun, 1 Oct 1995 02:32:29 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA22991>; Sun, 1 Oct 1995 02:32:26 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id KAA14662; Sun, 1 Oct 1995 10:31:47 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id KAA17576; Sun, 1 Oct 1995 10:32:21 +0100 Date: Sun, 1 Oct 1995 10:32:21 +0100 (BST) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: courtenay_j_m <courtenay_j_m@bt-web.bt.co.uk> Cc: mbone Subject: Re: mrouted under Solaris - please help (now) In-Reply-To: <199510010905.AA22501@venera.isi.edu> Message-Id: <Pine.SV4.3.91.951001101650.17551A-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 1 Oct 1995, courtenay_j_m wrote: Hi Mark, > This is a "now or never" request for help. It expires Monday, 2nd October > at 1100 GMT. I will post again if I still need help after this time. > Thanks in advance if you respond. > > I'm trying to get mrouted running on a Sparc 5 running Solaris 2.4 > remotely from home. The mrouted package is the combined IP multicast > amd mrouted to be found at playground.sun.com/pub/multicast (can't > remember the precise tar file name at present: anyway it includes the > substring 33.2.4, i.e. ipmulti v3.3 and mrouted 3.4, I think). Solaris_mc33.2.4.tar.Z? > I've run the install script (install.multi, I believe) and rebooted. > mrouted doesn't appear in the processes table. I invoke it > interactively and it just exits silently. So does mrinfo. No error > messages, no entry in ps -elf. Well the installation script should have created a file in /etc/rc2.d called S69mrouted. This will start mrouted at boot time. I supect that this is happening but that it is then dying. > When I get in on Monday I will be physically moving the machine to > where its parent mrouted can see it. So there is no tunnel pointing > to it at present. But I'm sure it should be possible to get it to run > even without this. Ahh this is possibly where the problem lies. > There wasn't an mrouted.conf template with the distibution, so I > copied a SunOS ipmulti3.3 mrouted.conf and edited in the correct local > address. Still no joy. You must make sure that the mrouted.conf file in /etc/ contains at least one valid tunnel entry. If it doesn't mrouted will assume that there is no work to be done and will die. Your ivs problem is strange but I know that it does not work too well if you are using a virtual desktop window manager such as tvtwm and olvwm. If you are using one of these try using the non-virtual version and see if that fixes your problem. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Sun Oct 1 09:37:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29379>; Sun, 1 Oct 1995 10:37:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29360>; Sun, 1 Oct 1995 10:37:20 -0700 Received: from davinci.gmu.edu ([206.197.101.10]) by venera.isi.edu (5.65c/5.61+local-22) id <AA29353>; Sun, 1 Oct 1995 10:37:18 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id NAA06032; Sun, 1 Oct 1995 13:37:38 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199510011737.NAA06032@davinci.gmu.edu> Subject: Re: MBONE and Solaris To: phiber@radicalmedia.com (Mark Abene) Date: Sun, 1 Oct 1995 13:37:38 -0400 (EDT) Cc: mbone, van@ee.lbl.gov In-Reply-To: <199510010633.CAA06880@radicalmedia.com> from "Mark Abene" at Oct 1, 95 02:33:11 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 719 What is the reason for not releasing the source code? Michael > > > So I've got an MBONE feed and mrouted running on our Solaris x86 2.4 box. > I have but one request: since source code is still unavailable for the > popular MBONE apps like sd, vat, vic, etc., perhaps the code maintainers > would be kind enough to release binaries for Solaris on Intel platforms? > Shouldn't be a big deal. I'm also curious as to the status of said source > code and when it might be made available. > > -Mark Abene > Radical Media, Inc. > -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Sun Oct 1 07:07:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04281>; Sun, 1 Oct 1995 14:26:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04028>; Sun, 1 Oct 1995 14:08:50 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA04018>; Sun, 1 Oct 1995 14:08:25 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14842(6)>; Sun, 1 Oct 1995 14:08:16 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Sun, 1 Oct 1995 14:08:06 -0700 To: courtenay_j_m <courtenay_j_m@bt-web.bt.co.uk> Cc: mbone Subject: Re: mrouted under Solaris - please help (now) In-Reply-To: Your message of "Sun, 01 Oct 95 02:05:51 PDT." <199510010905.AA22501@venera.isi.edu> Date: Sun, 1 Oct 1995 14:07:58 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct1.140806pdt.177475@crevenia.parc.xerox.com> In message <199510010905.AA22501@venera.isi.edu> you write: >I invoke it >interactively and it just exits silently. So does mrinfo. No error >messages... Did you look in /var/adm/messages (or wherever it is on Solaris) for error messages? mrouted uses syslog as its sole error logging, unless you invoke it with debugging on (which you could also try - "mrouted -d" might give you more information on why it is failing.) Bill From list-mgr@ISI.EDU Sun Oct 1 23:57:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05385>; Sun, 1 Oct 1995 15:15:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04942>; Sun, 1 Oct 1995 14:57:35 -0700 Received: from zaphod.axion.bt.co.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA04935>; Sun, 1 Oct 1995 14:57:33 -0700 Message-Id: <199510012157.AA04935@venera.isi.edu> Received: from bt-web.bt.co.uk by zaphod.axion.bt.co.uk via DECnet inbound channel id <sg.06459-0@zaphod.axion.bt.co.uk>; Sun, 1 Oct 1995 22:57:27 +0100 X-Vms-To: R11F::ISI.EDU::MBONE To: mbone From: courtenay_j_m <courtenay_j_m@bt-web.bt.co.uk> Subject: Re: mrouted under Solaris - please help (now) Date: Sun, 1 Oct 1995 22:57:27 +0100 Hmm ... doing mrouted -d was even more worrying (by the way the man page takes some reading to find out which way round the -d switch works, well, IMHO): debug level 2 mrouted version 3.4a installing le0 (132.146.196.183 on subnet 132.146.196) as vif #0 - rate=0 installing tunnel from 132.146.196.183 to 128.4.0.8 as vif #1 - rate=500 setsockopt DVMRP_ADD_VIF: Option not supported by protocol where the local address is correct but the remote tunnel endpoint is not. My mrouted.conf: tunnel 132.146.196.183 128.4.0.8 metric 3 rate_limit 500 boundary 239.2.3.3/16 # 239.2.x.x is scoped which is a slightly hacked version of the one that comes with the distibution, which I have now found. I should have said it doesn't get installed in /etc, which is probably reasonable (though that's where I looked for it). Again, thanks. Mark -- J Mark Courtenay tel. +44 1473 645423/640871 MLB 4 15/ADMIN 2 OP4 fax. +44 1473 620101/640709 BT Labs, Martlesham Heath Ipswich, UK IP5 7RE courtejm@boat.bt.co.uk From list-mgr@ISI.EDU Sun Oct 1 17:39:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07310>; Sun, 1 Oct 1995 16:36:46 -0700 Received: from newton.visgraf.impa.br by venera.isi.edu (5.65c/5.61+local-22) id <AA07301>; Sun, 1 Oct 1995 16:36:41 -0700 Received: (from lvelho@localhost) by Newton.visgraf.impa.br (8.6.10/8.6.10) id UAA04121 for mbone-na@ISI.EDU; Sun, 1 Oct 1995 20:39:52 -0300 From: Luiz Velho <lvelho@visgraf.impa.br> Message-Id: <199510012339.UAA04121@Newton.visgraf.impa.br> Subject: connection to Mbone To: mbone-na Date: Sun, 1 Oct 1995 20:39:51 -0300 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 662 We would like to connect our local network to the Mbone. As far as we know, there is not a Mbone link in Rio or in Brazil. The academic metropolitan network in Rio is connected to San Diego (sdsc-brnet.cerf.net). This is the closest point to the Mbone in US. Can anyone help us to set up a tunnel there? Thank's --Luiz ------------------------------------------------------------------------ Luiz Velho lvelho@visgraf.impa.br IMPA - Instituto de Matematica Pura e Aplicada Estrada Dona Castorina, 110 Tel: (5521)294-9032 22460 Rio de Janeiro, RJ, Brasil Fax: (5521)512-4115 From list-mgr@ISI.EDU Sun Oct 1 15:19:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08259>; Sun, 1 Oct 1995 17:16:48 -0700 Received: from imageek.york.cuny.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA08252>; Sun, 1 Oct 1995 17:16:47 -0700 Received: by imageek.york.cuny.edu (940816.SGI.8.6.9/940406.SGI) for mbone-na@ISI.EDU id UAA22134; Sun, 1 Oct 1995 20:19:15 -0400 From: geek@imageek.york.cuny.edu (Erik Van Riper) Message-Id: <199510020019.UAA22134@imageek.york.cuny.edu> Subject: MBone connection To: mbone-na Date: Sun, 1 Oct 1995 20:19:15 -0500 (EDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 605 Being that City University of New York is not yet on the MBONE, I would like to take the lead and start things off. I have tried to contact the people at nysernet, but to no avail. Hopefully someone on this list will see this plea and respond. :) Normal email is fine. Thank you in advance. -- geek@imageek.york.cuny.edu http://imageek.york.cuny.edu Erik Van Riper (718) 262-2667 Systems Administrator Go player Photon Counter Hacker Coffee lover Language design is 10% science and 90% psychology. -- Larry Wall From list-mgr@ISI.EDU Sun Oct 1 15:06:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14807>; Sun, 1 Oct 1995 22:13:53 -0700 Received: from hawk.csusm.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA14800>; Sun, 1 Oct 1995 22:13:51 -0700 Received: by hawk.csusm.edu (AIX 4.1/UCB 5.64/4.03) id AA16892; Sun, 1 Oct 1995 22:06:30 -0700 Date: Sun, 1 Oct 1995 22:06:30 -0700 (PDT) From: Mark Chorak <chorak1@coyote.csusm.edu> X-Sender: chorak1@hawk.csusm.edu To: Luiz Velho <lvelho@visgraf.impa.br> Cc: mbone-na Subject: Re: connection to Mbone In-Reply-To: <199510012339.UAA04121@Newton.visgraf.impa.br> Message-Id: <Pine.A32.3.91.951001220516.6134A-100000@hawk.csusm.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We at California State University San Marcos, 20 minutes north of San Diego, would like a feed into the mbone as well. Mark On Sun, 1 Oct 1995, Luiz Velho wrote: > Date: Sun, 1 Oct 1995 20:39:51 -0300 (EST) > From: Luiz Velho <lvelho@visgraf.impa.br> > To: mbone-na@ISI.EDU > Subject: connection to Mbone > > > We would like to connect our local network to the Mbone. > As far as we know, there is not a Mbone link in Rio or > in Brazil. The academic metropolitan network in Rio is > connected to San Diego (sdsc-brnet.cerf.net). This is > the closest point to the Mbone in US. Can anyone help us > to set up a tunnel there? > > Thank's > > --Luiz > > ------------------------------------------------------------------------ > Luiz Velho lvelho@visgraf.impa.br > IMPA - Instituto de Matematica Pura e Aplicada > Estrada Dona Castorina, 110 Tel: (5521)294-9032 > 22460 Rio de Janeiro, RJ, Brasil Fax: (5521)512-4115 > From list-mgr@ISI.EDU Sun Oct 1 16:38:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16747>; Sun, 1 Oct 1995 23:38:14 -0700 Received: from starfleet (starfleet.internex.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA16740>; Sun, 1 Oct 1995 23:38:12 -0700 Received: from farragut.InterNex.Net by starfleet (SMI-8.6.9/SMI-SVR4) id XAA14056; Sun, 1 Oct 1995 23:38:11 -0700 Received: by farragut.InterNex.Net (5.x/SMI-SVR4) id AA01296; Sun, 1 Oct 1995 23:38:04 -0700 From: "Marcos Della" <mdella@farragut.InterNex.Net> Message-Id: <9510012338.ZM1294@farragut> Date: Sun, 1 Oct 1995 23:38:03 -0700 X-Mailer: Z-Mail (3.2.1 10apr95) To: mbone-na Subject: Mbone from Mae-West Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Well, I've been looking now for around a month or so and no luck. I had a connection from Sprint that we broke, looks like we whould put it back up in place. No one at Mae-west appears to be tunneling through there... Marcos -- ''' (o o) --------------------------oOO--(_)--OOo-------------------------- Marcos R. Della Email: mdella@InterNex.Net Director, Network Engineering InterNex Information Services Phone: 408/496-5466 http://www.internex.net/~mdella From list-mgr@ISI.EDU Mon Oct 2 09:34:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18282>; Mon, 2 Oct 1995 00:41:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17953>; Mon, 2 Oct 1995 00:34:51 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA17946>; Mon, 2 Oct 1995 00:34:49 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA11236>; Mon, 2 Oct 1995 00:34:48 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.04686-0@bells.cs.ucl.ac.uk>; Mon, 2 Oct 1995 08:34:28 +0100 To: mbenson@davinci.gmu.edu (Michael Benson) Cc: phiber@radicalmedia.com (Mark Abene), mbone, van@ee.lbl.gov Subject: Re: MBONE and Solaris In-Reply-To: Your message of "Sun, 01 Oct 95 13:37:38 EDT." <199510011737.NAA06032@davinci.gmu.edu> Date: Mon, 02 Oct 95 08:34:26 +0100 Message-Id: <678.812619266@cs.ucl.ac.uk> From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> >What is the reason for not releasing the source code? Michael source code of vic is available..... UCL released source code of our version of sd.... most the other applications have other versions - the only one we are waiting for is vat, and it is promised as soon as......? meanwhile, it isn't that much work to write an audio tool quickly (especially if you join ACM SIGCOMM and get last years conference tutorial notes from van's session) >> So I've got an MBONE feed and mrouted running on our Solaris x86 2.4 box. >> I have but one request: since source code is still unavailable for the >> popular MBONE apps like sd, vat, vic, etc., perhaps the code maintainers >> would be kind enough to release binaries for Solaris on Intel platforms? >> Shouldn't be a big deal. I'm also curious as to the status of said source >> code and when it might be made available. jon From list-mgr@ISI.EDU Sun Oct 1 23:52:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18754>; Mon, 2 Oct 1995 01:02:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18559>; Mon, 2 Oct 1995 00:57:13 -0700 Received: from radicalmedia.com by venera.isi.edu (5.65c/5.61+local-22) id <AA18551>; Mon, 2 Oct 1995 00:57:11 -0700 Received: (from phiber@localhost) by radicalmedia.com (8.6.12/8.6.12) id DAA10923; Mon, 2 Oct 1995 03:52:42 -0400 From: Mark Abene <phiber@radicalmedia.com> Message-Id: <199510020752.DAA10923@radicalmedia.com> Subject: Re: MBONE and Solaris To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Mon, 2 Oct 1995 03:52:42 -0400 (EDT) Cc: mbone In-Reply-To: <678.812619266@cs.ucl.ac.uk> from "Jon Crowcroft" at Oct 2, 95 08:34:26 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 764 > > source code of vic is available..... > UCL released source code of our version of sd.... > most the other applications have other versions - the only one we are > waiting for is vat, and it is promised as soon as......? > > meanwhile, it isn't that much work to write an audio tool quickly (especially if > you join ACM SIGCOMM and get last years conference tutorial notes from van's > session) > > > jon > OK, I'll bite. A pointer to your release of an sd tool would be appreciated. I'm assuming it's graphical, since there are plenty of sd_listen -type programs floating around which are text based, and it's a rather simple matter to write one. A graphical one would be nice. And yes, vat would be nice as well. -Mark Abene Radical Media, Inc. From list-mgr@ISI.EDU Mon Oct 2 10:38:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19653>; Mon, 2 Oct 1995 01:42:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19478>; Mon, 2 Oct 1995 01:38:43 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA19468>; Mon, 2 Oct 1995 01:38:22 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id JAA17048; Mon, 2 Oct 1995 09:37:39 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id JAA18837; Mon, 2 Oct 1995 09:38:12 +0100 Date: Mon, 2 Oct 1995 09:38:11 +0100 (BST) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: courtenay_j_m <courtenay_j_m@bt-web.bt.co.uk> Cc: mbone Subject: Re: mrouted under Solaris - please help (now) In-Reply-To: <199510012157.AA04935@venera.isi.edu> Message-Id: <Pine.SV4.3.91.951002093651.18811A-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 1 Oct 1995, courtenay_j_m wrote: > Hmm ... doing mrouted -d was even more worrying (by the way the man > page takes some reading to find out which way round the -d switch > works, well, IMHO): > > debug level 2 > mrouted version 3.4a > installing le0 (132.146.196.183 on subnet 132.146.196) as vif #0 - rate=0 > installing tunnel from 132.146.196.183 to 128.4.0.8 as vif #1 - rate=500 > setsockopt DVMRP_ADD_VIF: Option not supported by protocol Ohhh. "setsockopt DVMRP_ADD_VIF: Option not supported by protocol" means that your haven't got the appropriate kernel modules installed. Did you apply any patches after installing the IP multicast package? If so you may have undone the installation. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Sun Oct 1 19:57:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20790>; Mon, 2 Oct 1995 02:59:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20775>; Mon, 2 Oct 1995 02:58:06 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA20768>; Mon, 2 Oct 1995 02:58:05 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id CAA02743; Mon, 2 Oct 1995 02:57:39 -0700 Message-Id: <199510020957.CAA02743@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> Cc: mbone, van@ee.lbl.gov Subject: Re: MBONE and Solaris In-Reply-To: Your message of "Mon, 02 Oct 1995 08:34:26 BST." <678.812619266@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Oct 1995 02:57:38 -0700 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Maybe this is a good time to start deploying rtpv2 based tools.. Amancio >>> Jon Crowcroft said: > > > >What is the reason for not releasing the source code? > > Michael > > source code of vic is available..... > UCL released source code of our version of sd.... > most the other applications have other versions - the only one we are > waiting for is vat, and it is promised as soon as......? > > meanwhile, it isn't that much work to write an audio tool quickly (especiall y if > you join ACM SIGCOMM and get last years conference tutorial notes from van's > session) > > >> So I've got an MBONE feed and mrouted running on our Solaris x86 2.4 box . > >> I have but one request: since source code is still unavailable for the > >> popular MBONE apps like sd, vat, vic, etc., perhaps the code maintainers > >> would be kind enough to release binaries for Solaris on Intel platforms? > >> Shouldn't be a big deal. I'm also curious as to the status of said sour ce > >> code and when it might be made available. > > jon > From list-mgr@ISI.EDU Mon Oct 2 12:10:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20927>; Mon, 2 Oct 1995 03:12:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20911>; Mon, 2 Oct 1995 03:11:14 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA20904>; Mon, 2 Oct 1995 03:11:11 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id LAA17866; Mon, 2 Oct 1995 11:09:29 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id LAA19015; Mon, 2 Oct 1995 11:10:04 +0100 Date: Mon, 2 Oct 1995 11:10:03 +0100 (BST) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, mbone, van@ee.lbl.gov Subject: Re: MBONE and Solaris In-Reply-To: <199510020957.CAA02743@rah.star-gate.com> Message-Id: <Pine.SV4.3.91.951002110826.18811D-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 2 Oct 1995, Amancio Hasty Jr. wrote: > Maybe this is a good time to start deploying rtpv2 based tools.. vic is RTPv2 based (though I think the protocol has been changed since vic was produced ?). So is UCL's audio tool and session directory tool. The next version of ivs will also be RTPv2 based. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Mon Oct 2 02:30:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21138>; Mon, 2 Oct 1995 03:36:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21126>; Mon, 2 Oct 1995 03:35:06 -0700 Received: from radicalmedia.com by venera.isi.edu (5.65c/5.61+local-22) id <AA21119>; Mon, 2 Oct 1995 03:35:04 -0700 Received: (from phiber@localhost) by radicalmedia.com (8.6.12/8.6.12) id GAA11576; Mon, 2 Oct 1995 06:30:11 -0400 From: Mark Abene <phiber@radicalmedia.com> Message-Id: <199510021030.GAA11576@radicalmedia.com> Subject: Re: mrouted under Solaris - please help (now) To: Graeme.Wood@ucs.ed.ac.uk Date: Mon, 2 Oct 1995 06:30:11 -0400 (EDT) Cc: mbone In-Reply-To: <Pine.SV4.3.91.951002093651.18811A-100000@scorpio.ucs.ed.ac.uk> from "Graeme Wood" at Oct 2, 95 09:38:11 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1545 No, he's right. I installed the new drivers as well, and got the same error. So, I went and installed mrouted 2.2, and it works fine. -Mark Abene Radical Media, Inc. > > On Sun, 1 Oct 1995, courtenay_j_m wrote: > > > Hmm ... doing mrouted -d was even more worrying (by the way the man > > page takes some reading to find out which way round the -d switch > > works, well, IMHO): > > > > debug level 2 > > mrouted version 3.4a > > installing le0 (132.146.196.183 on subnet 132.146.196) as vif #0 - rate=0 > > installing tunnel from 132.146.196.183 to 128.4.0.8 as vif #1 - rate=500 > > setsockopt DVMRP_ADD_VIF: Option not supported by protocol > > Ohhh. "setsockopt DVMRP_ADD_VIF: Option not supported by protocol" > means that your haven't got the appropriate kernel modules installed. > Did you apply any patches after installing the IP multicast package? If > so you may have undone the installation. > > ============================================================================= > Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk > Unix Systems Support Phone: +44 131 650 5003 > The University of Edinburgh Fax: +44 131 650 6552 > ----------------------------------------------------------------------------- > Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk > for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ > ============================================================================= > > From list-mgr@ISI.EDU Mon Oct 2 12:40:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21268>; Mon, 2 Oct 1995 03:45:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21230>; Mon, 2 Oct 1995 03:40:41 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA21223>; Mon, 2 Oct 1995 03:40:38 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id LAA18062; Mon, 2 Oct 1995 11:39:30 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id LAA19110; Mon, 2 Oct 1995 11:40:01 +0100 Date: Mon, 2 Oct 1995 11:40:00 +0100 (BST) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Mark Abene <phiber@radicalmedia.com> Cc: Graeme.Wood@ucs.ed.ac.uk, mbone Subject: Re: mrouted under Solaris - please help (now) In-Reply-To: <199510021030.GAA11576@radicalmedia.com> Message-Id: <Pine.SV4.3.91.951002113640.18811E-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 2 Oct 1995, Mark Abene wrote: > No, he's right. I installed the new drivers as well, and got the same error. > So, I went and installed mrouted 2.2, and it works fine. > > -Mark Abene > Radical Media, Inc. But that defeats the object of the exercise. The unpatched Solaris kernel will support mrouted 2.2. The patched kernel should support mrouted 3.4. However, if you apply any patches that replace the ip module then you will reverse installation. I can assure you that it does work as I am using a SPARC 5 with Solaris 2.4 with all the recommended patches and then the IP multicast 3.3 patch installed on top. mrouted 3.4 has been running happily for some months. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Mon Oct 2 12:59:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21469>; Mon, 2 Oct 1995 04:02:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21433>; Mon, 2 Oct 1995 04:00:12 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-22) id <AA21412>; Mon, 2 Oct 1995 03:59:59 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id LAA25474 (8.6.12/7.4g-FAU);; Mon, 2 Oct 1995 11:58:36 +0100 From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de> Message-Id: <199510021058.LAA25474@faui40.informatik.uni-erlangen.de> Subject: Re: mrouted under Solaris - please help (now) To: Graeme.Wood@ucs.ed.ac.uk Date: Mon, 2 Oct 1995 11:59:43 +0100 (MET) Cc: phiber@radicalmedia.com, mbone In-Reply-To: <Pine.SV4.3.91.951002113640.18811E-100000@scorpio.ucs.ed.ac.uk> from "Graeme Wood" at Oct 2, 95 11:40:00 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 241 > I can assure you that it does work as I am using a SPARC 5 with Solaris > 2.4 with all the recommended patches and then the IP multicast 3.3 patch > installed on top. mrouted 3.4 has been running happily for some months. How about 3.6 ? From list-mgr@ISI.EDU Mon Oct 2 00:38:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25260>; Mon, 2 Oct 1995 07:39:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25240>; Mon, 2 Oct 1995 07:39:06 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA25233>; Mon, 2 Oct 1995 07:39:04 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15239(1)>; Mon, 2 Oct 1995 07:38:48 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Mon, 2 Oct 1995 07:38:32 -0700 To: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de> Cc: Graeme.Wood@ucs.ed.ac.uk, phiber@radicalmedia.com, mbone Subject: Re: mrouted under Solaris - please help (now) In-Reply-To: Your message of "Mon, 02 Oct 95 03:59:43 PDT." <199510021058.LAA25474@faui40.informatik.uni-erlangen.de> Date: Mon, 2 Oct 1995 07:38:26 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct2.073832pdt.177475@crevenia.parc.xerox.com> In message <199510021058.LAA25474@faui40.informatik.uni-erlangen.de> you write: >How about 3.6 ? The Solaris port of 3.6 is in the works, I think alpha testing should be starting soon. Bill From list-mgr@ISI.EDU Mon Oct 2 05:53:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28597>; Mon, 2 Oct 1995 08:55:21 -0700 Received: from fnal.fnal.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA28589>; Mon, 2 Oct 1995 08:55:19 -0700 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HVYNGPCJI8008TAS@FNAL.FNAL.GOV>; Mon, 02 Oct 1995 10:54:40 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA20864; Mon, 2 Oct 95 10:53:33 CDT Date: Mon, 02 Oct 1995 10:53:32 -0500 From: Matt Crawford <crawdad@FNAL.FNAL.GOV> Subject: Re: connection to Mbone In-Reply-To: Your message of Sun, 01 Oct 95 20:39:51 -0400. <199510012339.UAA04121@Newton.visgraf.impa.br> Sender: crawdad@munin.fnal.gov To: Luiz Velho <lvelho@visgraf.impa.br> Cc: mbone-na Message-Id: <9510021553.AA20864@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > We would like to connect our local network to the Mbone. As far as > we know, there is not a Mbone link in Rio or in Brazil. Luiz, There were MBONE links in Rio and from Rio to the US when I left, but they only existed for the duration of CHEP '95. (Sep 17-22.) There may still be MBONE on the Rede Rio backbone. I suggest you contact Paulo Aguiar at UFRJ. > The academic metropolitan network in Rio is connected to San Diego > (sdsc-brnet.cerf.net). This is the closest point to the Mbone in > US. Can anyone help us to set up a tunnel there? I believe that link is still being upgraded from 256 kb/s to 2Mb/s. When the new link is up and stable, I am sure Rede Rio will set up an MBONE tunnel. cumprimentos, _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A From list-mgr@ISI.EDU Mon Oct 2 05:53:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28597>; Mon, 2 Oct 1995 08:55:21 -0700 Received: from fnal.fnal.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA28589>; Mon, 2 Oct 1995 08:55:19 -0700 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HVYNGPCJI8008TAS@FNAL.FNAL.GOV>; Mon, 02 Oct 1995 10:54:40 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA20864; Mon, 2 Oct 95 10:53:33 CDT Date: Mon, 02 Oct 1995 10:53:32 -0500 From: Matt Crawford <crawdad@FNAL.FNAL.GOV> Subject: Re: connection to Mbone In-Reply-To: Your message of Sun, 01 Oct 95 20:39:51 -0400. <199510012339.UAA04121@Newton.visgraf.impa.br> Sender: crawdad@munin.fnal.gov To: Luiz Velho <lvelho@visgraf.impa.br> Cc: mbone-na Message-Id: <9510021553.AA20864@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > We would like to connect our local network to the Mbone. As far as > we know, there is not a Mbone link in Rio or in Brazil. Luiz, There were MBONE links in Rio and from Rio to the US when I left, but they only existed for the duration of CHEP '95. (Sep 17-22.) There may still be MBONE on the Rede Rio backbone. I suggest you contact Paulo Aguiar at UFRJ. > The academic metropolitan network in Rio is connected to San Diego > (sdsc-brnet.cerf.net). This is the closest point to the Mbone in > US. Can anyone help us to set up a tunnel there? I believe that link is still being upgraded from 256 kb/s to 2Mb/s. When the new link is up and stable, I am sure Rede Rio will set up an MBONE tunnel. cumprimentos, _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A From list-mgr@ISI.EDU Mon Oct 2 03:52:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17765>; Mon, 2 Oct 1995 17:06:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17729>; Mon, 2 Oct 1995 17:06:07 -0700 Received: from hp.com by venera.isi.edu (5.65c/5.61+local-22) id <AA17721>; Mon, 2 Oct 1995 17:06:06 -0700 Received: from hpindlm.cup.hp.com by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA007256390; Mon, 2 Oct 1995 10:53:10 -0700 Received: by hpindlm.cup.hp.com (1.38.193.5/15.5+IOS 3.20+cup+OMrelay) id AA13859; Mon, 2 Oct 1995 10:52:35 -0700 From: Ming Ming Chen <mchen@hpindlm.cup.hp.com> Message-Id: <9510021752.AA13859@hpindlm.cup.hp.com> Subject: Re: Kernel Assert mods To: fenner@parc.xerox.com (Bill Fenner) Date: Mon, 2 Oct 95 10:52:34 PDT Cc: pusateri@netedge.com, pusateri@hpindlm.cup.hp.com, clemenj@hpindlm.cup.hp.com, doug_cohol@hp6600.desk.hp.com, mbone, jgc@hpindlm.cup.hp.com In-Reply-To: <95Sep29.133114pdt.177475@crevenia.parc.xerox.com>; from "Bill Fenner" at Sep 29, 95 1:30 pm Mailer: Elm [revision: 70.85.2.1] Hi Bill, > > Ming, > > Very sorry for not replying; often if I don't reply to things right away > because I have to think about them, they get completely buried in my inbox. > We have decided that the for loop is O.K. in the upcall case, both for the > NOCACHE and the WRONGVIF message, and that will be what is in our next release. Thanks for replying my mail. We looked at the solution 1 and solution 2 and found that both have new for loop code. One is to loop through "ifp->if_addrlist" which requires changes in both ip_mroute.h and ip_mroute.c, the other loops the "viftable". So which for loop? Thanks Ming |Ming Ming Chen Hewlett Packard | |Information Network Division 19410 Homestead Road | |mchen@hpindlm.cup.hp.com Cupertino, CA 95014 | |408-447-2357 Mail Stop: 43LM | |_____________________________________________________________________________| From list-mgr@ISI.EDU Wed Oct 4 05:52:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06187>; Tue, 3 Oct 1995 05:04:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05916>; Tue, 3 Oct 1995 04:49:22 -0700 Received: from fs.naruto-u.ac.jp ([160.204.250.3]) by venera.isi.edu (5.65c/5.61+local-22) id <AA05909>; Tue, 3 Oct 1995 04:49:13 -0700 Received: from [160.204.250.114] (pineapple.naruto-u.ac.jp [160.204.250.114]) by fs.naruto-u.ac.jp (8.6.12+2.5Wb7/3.4Wbeta1/naruto-u 95040411) with SMTP id UAA25751 for <mbone@ISI.EDU>; Tue, 3 Oct 1995 20:52:18 +0900 Date: Tue, 3 Oct 1995 20:52:18 +0900 Message-Id: <199510031152.UAA25751@fs.naruto-u.ac.jp> To: mbone From: matsudak@naruto-u.ac.jp (Kazunor! Matsuda) X-Sender: matsudak@fs.naruto-u.ac.jp Subject: Multicast for ATM-LAN Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Eudora-J(1.3.8.5-J13) I sould appreciate it if someone could kindly teach me the way how MBone multicasts for the ATM-LAN. -Kaz From list-mgr@ISI.EDU Tue Oct 3 03:37:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19391>; Tue, 3 Oct 1995 10:38:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19294>; Tue, 3 Oct 1995 10:37:44 -0700 Received: from anduin.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA19286>; Tue, 3 Oct 1995 10:37:43 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by anduin.ocf.llnl.gov (4.1/SMI-4.0) id AA22994; Tue, 3 Oct 95 10:37:29 PDT Message-Id: <9510031737.AA22994@anduin.ocf.llnl.gov> X-Sender: jed@anduin.ocf.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Oct 1995 10:37:32 -0700 To: matsudak@naruto-u.ac.jp (Kazunor! Matsuda) From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: Multicast for ATM-LAN (or WAN for that matter) Cc: mbone >I sould appreciate it if someone could kindly teach me the way >how MBone multicasts for the ATM-LAN. > >-Kaz My only experience with multicast over ATM is in the impoverished PVC world. I can tell you how it is done on the Bay Area Gigabit NETwork (BAGNET). Bagnet uses PVCs. In that case there are broadcast PVCs set up between each site and all the others. Any multicasted IP packets are broadcast through a site's broadcast PVC from the sending site to all the others. This mechanism does not work very well (it is subject to configuration problems and wastes bandwidth and load to sites not involved in a multicast group) and certainly does not scale well. How multicast will be handled with SVCs I do not know. Perhaps others do. Of course it is possible to simply layer multicast on top of IP and get the multicasting (copying of packets) to be done in routers, but such a mechanism is not applying ATM technology to support multicast. I assume that multicast SVCs can be set up and can track multicast groups in some way, but I don't understand how this can/will be done. I would like to hear how others believe it will be done, so if you hear, please let me know ;-) I assume there is documentation about these mechanisms somewhere. If anybody knows more about these mechanisms, would you please summarize the approach and provide pointers to more information? Thanks! --Jed http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Tue Oct 3 10:49:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23116>; Tue, 3 Oct 1995 11:51:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23101>; Tue, 3 Oct 1995 11:50:56 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA23094>; Tue, 3 Oct 1995 11:50:55 -0700 Received: from mailer.jhuapl.edu by quark.isi.edu (5.65c/5.61+local-20) id <AA00777>; Tue, 3 Oct 1995 11:50:50 -0700 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA24693; Tue, 3 Oct 1995 14:49:33 -0400 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA22510; Tue, 3 Oct 1995 14:49:32 -0400 Date: Tue, 3 Oct 1995 14:49:31 -0400 (EDT) From: Jim Bogard BIX <jimbo@aplcomm.jhuapl.edu> To: mbone <mbone> Subject: sd protocols Message-Id: <Pine.SOL.3.91.951003142348.13588O-100000@aplcomm.jhuapl.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 267 Can someone tell me what protocol is used to transmit sd messages? I need a sanity check. Thanks. Jim ---- Jim Bogard JHU/APL BIX Group "This is my banjo. There are many Backbone Network Engineer like it, but this one is mine." From list-mgr@ISI.EDU Tue Oct 3 05:51:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25878>; Tue, 3 Oct 1995 12:51:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25867>; Tue, 3 Oct 1995 12:51:27 -0700 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA25860>; Tue, 3 Oct 1995 12:51:26 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA13134 (5.65c/IDA-1.4.4nsd for <mbone@isi.edu>); Tue, 3 Oct 1995 12:51:18 -0700 Received: by jaspar.NSD.3Com.COM id AA12054 (5.65c/IDA-1.4.4-910730 for mbone@isi.edu); Tue, 3 Oct 1995 12:51:17 -0700 Date: Tue, 3 Oct 1995 12:51:17 -0700 From: "Cyndi M. Jung" <cmj@NSD.3Com.COM> Message-Id: <199510031951.AA12054@jaspar.NSD.3Com.COM> To: mbone Subject: European Educational Forum Anybody out there interested in hearing about the two multicast routing protocols that we are providing on our CandleStick, er, 3Com routers next month? I will be in Berlin on October 12, giving my first attempt at a presentation on both DVMRP and MOSPF (and opinions on the rest of it) in conjunction with other presentations on new technology from 3Com and research activities at the participating universities - Germany, Poland and Ireland this time. If you are interested, send me email and I will send you an agenda and get you in contact with the organizers. Cyndi Jung From list-mgr@ISI.EDU Tue Oct 3 18:38:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13212>; Tue, 3 Oct 1995 19:41:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13168>; Tue, 3 Oct 1995 19:39:49 -0700 Received: from cne.gmu.edu ([199.26.254.1]) by venera.isi.edu (5.65c/5.61+local-22) id <AA13143>; Tue, 3 Oct 1995 19:39:00 -0700 Received: by cne.gmu.edu (4.1/SMI-4.1) id AA06349; Tue, 3 Oct 95 22:38:50 EDT Date: Tue, 3 Oct 95 22:38:50 EDT From: mpullen@cne.gmu.edu (Mark Pullen) Message-Id: <9510040238.AA06349@cne.gmu.edu> To: mbone Subject: Planned MBONE sessions 10-13 October Cc: mpullen@cne.gmu.edu, mbenson@cne.gmu.edu, llavu@cne.gmu.edu, kfrosch@cne.gmu.edu, schettle@davinci.cne.gmu.edu, Frank_Jensen@qmgate.arc.nasa.gov We are planning the following MBONE session: 1. Contents: Computer Aided Education and Training Initiative (CAETI) Kickoff Meeting at NASA-Ames. 2. Session name: CAETI 3. Media: vat, nv, wb 4. Bandwidth: 128kbps 5. Begins at: 1995/10/10 1900UTC (=1500EDT=1200PDT) 6. Ends at: 1995/10/13 1900UTC (=1500EDT=1200PDT)) 7. Initial TTL: 80 8. Contact: Frank Jensen, NASA Ames 9. Email address: Frank_Jensen@qmgate.arc.nasa.gov Mark Pullen <mpullen@gmu.edu> GMU C3I Center From list-mgr@ISI.EDU Tue Oct 3 18:50:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13520>; Tue, 3 Oct 1995 19:51:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13494>; Tue, 3 Oct 1995 19:50:21 -0700 Received: from cne.gmu.edu ([199.26.254.1]) by venera.isi.edu (5.65c/5.61+local-22) id <AA13487>; Tue, 3 Oct 1995 19:50:19 -0700 Received: by cne.gmu.edu (4.1/SMI-4.1) id AA06462; Tue, 3 Oct 95 22:50:13 EDT Date: Tue, 3 Oct 95 22:50:13 EDT From: mpullen@cne.gmu.edu (Mark Pullen) Message-Id: <9510040250.AA06462@cne.gmu.edu> To: mbone Subject: Planned MBONE sessions 10-13 October Cc: mpullen@cne.gmu.edu, mbenson@cne.gmu.edu, llavu@cne.gmu.edu, kfrosch@cne.gmu.edu, schettle@davinci.cne.gmu.edu, Frank_Jensen@qmgate.arc.nasa.gov We are planning the following MBONE session: 1. Contents: Computer Aided Education and Training Initiative (CAETI) Kickoff Meeting at NASA-Ames. This is an extra whiteboard associated with a regular session announced about 20 minutes ago. 2. Session name: CAETI 3. Media: wb 4. Bandwidth: 0 (burst only for wb) 5. Begins at: 1995/10/10 1900UTC (=1500EDT=1200PDT) 6. Ends at: 1995/10/13 1900UTC (=1500EDT=1200PDT)) 7. Initial TTL: 80 8. Contact: Frank Jensen, NASA Ames 9. Email address: Frank_Jensen@qmgate.arc.nasa.gov Mark Pullen <mpullen@gmu.edu> GMU C3I Center ----- End Included Message ----- From list-mgr@ISI.EDU Sun Oct 4 09:36:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16613>; Tue, 3 Oct 1995 21:40:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16387>; Tue, 3 Oct 1995 21:33:11 -0700 Received: from milpitas.adaptec.com by venera.isi.edu (5.65c/5.61+local-22) id <AA16380>; Tue, 3 Oct 1995 21:33:09 -0700 Received: from corpmail.adaptec.com ([162.62.105.19]) by milpitas.adaptec.com (4.1/SMI-4.1) id AA08740; Tue, 3 Oct 95 21:32:34 PDT Received: from mentor.adaptec.com by corpmail.adaptec.com (4.1/SMI-4.1) id AA16375; Tue, 3 Oct 95 21:10:39 PDT X-Nvlenv-01Date-Transferred: 3-Oct-1995 21:35:41 -0400; at Mentor.Adaptec X-Nvlenv-01Date-Posted: 04-Oct-1995 13:36:20 -0400; at AJL.Adaptec Date: 04 Oct 95 13:36:00 EDT From: TMatsumu@Asia.adaptec.com Subject: re: European Educational Forum Message-Id: <42BE7230016B1673@-SMF-> In-Reply-To: <199510031951.AA12054@jaspar.NSD.3Com.COM> Reply-To: TMatsumu@Asia.adaptec.com References: <199510031951.AA12054@jaspar.NSD.3Com.COM> To: mbone Cyndi, I'm interested, but only how it handles ATM traffic, PVC's only, or SVC's also? and right now my travel is limited to Japan and Calif. Thanks. Ted ***** Ted Matsumura, Adaptec Japan ATM Program Manager InterNetworking Technology (INTO) Adaptec Japan Ltd. (03) 5276-8433 (Voice) (03) 5276-9364 (Fax) tmatsumu@asia.adaptec.com http://www.rahul.net/tedm ***** ------------- Original Text From cmj@NSD.3Com.COM ("Cyndi M. Jung"), on 10/3/95 12:51 PM: Anybody out there interested in hearing about the two multicast routing protocols that we are providing on our CandleStick, er, 3Com routers next month? I will be in Berlin on October 12, giving my first attempt at a presentation on both DVMRP and MOSPF (and opinions on the rest of it) in conjunction with other presentations on new technology from 3Com and research activities at the participating universities - Germany, Poland and Ireland this time. If you are interested, send me email and I will send you an agenda and get you in contact with the organizers. Cyndi Jung From list-mgr@ISI.EDU Wed Oct 4 22:57:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20954>; Wed, 4 Oct 1995 00:21:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20853>; Wed, 4 Oct 1995 00:18:38 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA20846>; Wed, 4 Oct 1995 00:18:36 -0700 Received: from mail.ncku.edu.tw by quark.isi.edu (5.65c/5.61+local-20) id <AA08647>; Wed, 4 Oct 1995 00:16:18 -0700 Received: (from ckwen@localhost) by mail.ncku.edu.tw (8.6.12/8.6.12) id OAA26028; Wed, 4 Oct 1995 14:57:10 +0800 From: Cheng-Kang Wen <ckwen@mail.ncku.edu.tw> Message-Id: <199510040657.OAA26028@mail.ncku.edu.tw> Subject: Re: "[RT]INT but buffer owned by LANCE" problem To: hori@coffee.kyushu-id.ac.jp (Yoshiaki Hori) Date: Wed, 4 Oct 1995 14:57:10 +0800 (WST) Cc: mbone In-Reply-To: <199510031149.UAA30062@cocoa.kyushu-id.ac.jp> from "Yoshiaki Hori" at Oct 3, 95 08:49:56 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 529 Hi, Hori, I was annoyed with the same messages on my Sparc LX which was running SunOS 4.1.3 for a long time. But I got no solution for it. I installed a new SunOS 4.1.3_U1B and that message was gone. But I still don't know why ? Maybe you can try upgrading or patching your OS with network related patches at first. Good Luck, Cheng-Kang Wen > > It appears following messages on SS5 with SunOS4.1.4 and 3.5multicast code. > > le1: [RT]INT but buffer owned by LANCE > > Anyone solves this problem? > Thanks > -- hori > From list-mgr@ISI.EDU Thu Oct 5 01:18:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20867>; Wed, 4 Oct 1995 00:20:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20840>; Wed, 4 Oct 1995 00:17:36 -0700 Received: from aohakobe.ipc.chiba-u.ac.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA20829>; Wed, 4 Oct 1995 00:17:31 -0700 Received: from aohakobe (localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.6.12/3.4Wbeta3 (-: 95041617) with ESMTP id QAA10997 for <mbone@ISI.EDU>; Wed, 4 Oct 1995 16:18:13 +0900 Message-Id: <199510040718.QAA10997@aohakobe.ipc.chiba-u.ac.jp> To: mbone <mbone> Subject: Re: sd protocols In-Reply-To: Your message of "Tue, 03 Oct 1995 14:49:31 -0400." <Pine.SOL.3.91.951003142348.13588O-100000@aplcomm.jhuapl.edu> Date: Wed, 04 Oct 1995 16:18:13 +0900 From: Yozo Toda (TELEPHONE +81-43-290-3539) <yozo@aohakobe.ipc.chiba-u.ac.jp> > Can someone tell me what protocol is used to transmit sd messages? I > need a sanity check. Thanks. some months before, Mr.Handley sent a message to the mailing list "rem-conf" about pre-draft on Session Description Protocol version 2. I think it's of help to understand what the program "sd" does. <http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.01.ps> and as an example source code, sd_listen.c is available: <ftp://agate.lut.ac.uk/pub/mbone/sd_listen.c> here are some lines from sd_listen.c: * Program to listen for SD style packets and print out the * announcements. * * This program is experimental and not guarenteed to digest all * SD packets correctly. Since the packet format was reverse * engineered, packets not seen before may not work. * * Tom Pusateri (pusateri@cs.duke.edu) * * * Redistribution and use in source and binary forms, with or without * modification, are permitted without restriction. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. * * $Id: sd_listen.c,v 1.6 1994/08/30 12:06:06 jon Exp jon $ * * Hacked up a bit by J.P.Knight@lut.ac.uk talking of source codes, I hear on this mailing list UCL's session directory tool are provided with the source. I'm waiting for someone to post the location... -- yozo. From list-mgr@ISI.EDU Wed Oct 4 12:00:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21466>; Wed, 4 Oct 1995 00:39:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21426>; Wed, 4 Oct 1995 00:35:48 -0700 Received: from vx23.cc.monash.edu.au by venera.isi.edu (5.65c/5.61+local-22) id <AA21411>; Wed, 4 Oct 1995 00:35:38 -0700 Received: from "port 4073"@basil.eng.monash.edu.au by vaxc.cc.monash.edu.au (PMDF V4.3-12 #8933) id <01HW1ID4YA4GI2240I@vaxc.cc.monash.edu.au>; Wed, 04 Oct 1995 12:00:37 +1000 Received: from BASIL/SpoolDir by basil.eng.monash.edu.au (Mercury 1.20) ; 4 Oct 95 12:00:43 -1000 Received: from SpoolDir by BASIL (Mercury 1.20); 4 Oct 95 12:00:13 -1000 Date: Wed, 4 Oct 1995 12:00:07 GMT+1100 From: Brett Pentland <brett.pentland@eng.monash.edu.au> Subject: Re: Multicast for ATM-LAN (or WAN for that matter) To: matsudak@naruto-u.ac.jp (Kazunor! Matsuda), jed@llnl.gov (James E. [Jed] Donnelley) Cc: mbone Reply-To: brett.pentland@monash.edu.au Message-Id: <DB0DD91EBB@basil.eng.monash.edu.au> X-Mailer: Pegasus Mail/Windows (v1.22) Content-Transfer-Encoding: 7BIT Priority: normal > Date: Tue, 3 Oct 1995 10:37:32 -0700 > To: matsudak@naruto-u.ac.jp (Kazunor! Matsuda) > From: jed@llnl.gov (James E. [Jed] Donnelley) > Subject: Re: Multicast for ATM-LAN (or WAN for that matter) > Cc: mbone@ISI.EDU > >I sould appreciate it if someone could kindly teach me the way > >how MBone multicasts for the ATM-LAN. > > > >-Kaz > > My only experience with multicast over ATM is in the impoverished > PVC world. > > I can tell you how it is done on the Bay Area Gigabit NETwork > (BAGNET). Bagnet uses PVCs. In that case there are broadcast > PVCs set up between each site and all the others. Any multicasted > IP packets are broadcast through a site's broadcast PVC > from the sending site to all the others. This mechanism does > not work very well (it is subject to configuration problems > and wastes bandwidth and load to sites not involved in > a multicast group) and certainly does not scale well. > > How multicast will be handled with SVCs I do not know. Perhaps > others do. Of course it is possible to simply layer multicast > on top of IP and get the multicasting (copying of packets) to > be done in routers, but such a mechanism is not applying > ATM technology to support multicast. I assume that multicast > SVCs can be set up and can track multicast groups in some way, > but I don't understand how this can/will be done. I would like > to hear how others believe it will be done, so if you hear, please let > me know ;-) I assume there is documentation about these > mechanisms somewhere. If anybody knows more about these > mechanisms, would you please summarize the approach and > provide pointers to more information? > > Thanks! > > --Jed http://www-atp.llnl.gov/atp/jed-signature.html > There is an Internet Draft on multicast over UNI 3.1 based ATM networks by Dr. Grenville Armitage. (I only know of it because he gave a seminar on the subject out here at Monash University) It talks about using Multicast Address Resolution Servers (MARS) to support level 2 multicast over the ATM Forum's UNI 3.1 point to multipoint connection service. Check out : http://www.ietf.cnri.reston.va.us/ids.by.wg/ipatm.html This page has an abstract, and a pointer to the paper itself. Brett ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Brett Pentland brett.pentland@monash.edu.au Centre for Telecommunications and Information Systems Department of Electrical and Computer Systems Engineering Monash University, Wellington Road Clayton, Vic 3168, Australia Phone : +61 3 9905-5245 Fax : +61 3 9905-5757 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From list-mgr@ISI.EDU Wed Oct 4 09:08:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22272>; Wed, 4 Oct 1995 01:11:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22243>; Wed, 4 Oct 1995 01:09:24 -0700 Received: from mons.uio.no by venera.isi.edu (5.65c/5.61+local-22) id <AA22236>; Wed, 4 Oct 1995 01:09:21 -0700 Received: from ulrik.uio.no by mons.uio.no with local-SMTP (PP) id <29045-0@mons.uio.no>; Wed, 4 Oct 1995 09:09:07 +0100 Received: from marion by marion.uio.no ; Wed, 4 Oct 1995 07:08:40 GMT Message-Id: <199510040708.HAA13122@marion.uio.no> X-Mailer: exmh version 1.6 4/21/95 To: mbone Subject: Re: sd protocols In-Reply-To: Your message of "Wed, 04 Oct 1995 16:18:13 MET." <199510040718.QAA10997@aohakobe.ipc.chiba-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 04 Oct 1995 08:08:39 +0100 From: Gorm Haug Eriksen <g.h.eriksen@usit.uio.no> Yozo Toda (TELEPHONE +81-43-290-3539) = <yozo@aohakobe.ipc.chiba-u.ac.jp> said: -> = -> > Can someone tell me what protocol is used to transmit sd messages? = I = -> > need a sanity check. Thanks. -> = -> some months before, Mr.Handley sent a message to the mailing list "rem= -conf" -> about pre-draft on Session Description Protocol version 2. -> I think it's of help to understand what the program "sd" does. -> = -> <http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.01.ps> -> = -> and as an example source code, sd_listen.c is available: -> = -> <ftp://agate.lut.ac.uk/pub/mbone/sd_listen.c> A perl version is also available. You should = also pick up mcast.pl in the same directory if you = plan to use it: ftp://agate.lut.ac.uk/pub/mbone/sd_listen.pl - Gorm From list-mgr@ISI.EDU Wed Oct 4 07:16:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02866>; Wed, 4 Oct 1995 08:30:03 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02433>; Wed, 4 Oct 1995 08:17:24 -0700 Received: from burdell.cc.gatech.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA02426>; Wed, 4 Oct 1995 08:17:21 -0700 Received: from flora.cc.gatech.edu (taddy@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.6.12/8.6.9) with ESMTP id LAA13599; Wed, 4 Oct 1995 11:15:51 -0400 Received: (from taddy@localhost) by flora.cc.gatech.edu (8.6.10/8.6.9) id LAA27688; Wed, 4 Oct 1995 11:16:18 -0400 From: taddy@cc.gatech.edu (Rajesh Talpade) Message-Id: <199510041516.LAA27688@flora.cc.gatech.edu> Subject: Re: Multicast for ATM-LAN (or WAN for that matter) To: brett.pentland@monash.edu.au Date: Wed, 4 Oct 1995 11:16:18 -0400 (EDT) Cc: matsudak@naruto-u.ac.jp, jed@llnl.gov, mbone In-Reply-To: <DB0DD91EBB@basil.eng.monash.edu.au> from "Brett Pentland" at Oct 4, 95 12:00:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1240 > > >I sould appreciate it if someone could kindly teach me the way > > >how MBone multicasts for the ATM-LAN. > > > > > >-Kaz > > > There is an Internet Draft on multicast over UNI 3.1 based ATM > networks by Dr. Grenville Armitage. (I only know of it because he > gave a seminar on the subject out here at Monash University) It > talks about using Multicast Address Resolution Servers (MARS) to > support level 2 multicast over the ATM Forum's UNI 3.1 point to > multipoint connection service. Check out : > > http://www.ietf.cnri.reston.va.us/ids.by.wg/ipatm.html > > This page has an abstract, and a pointer to the paper itself. > There have also been at least two independent implementation efforts of this draft in the industry. I have been involved with one of them. Unfortunately, we do not have any documentation on the implementation yet (hope to soon :-)) However, more information about the draft itself can be found at http://gump.bellcore.com:8000/~gja/i-drafts.html Also, the ip-atm mailing list discusses these issues. You can subscribe to it by sending mail to majordomo@matmos.hpl.hp.com with the subject being "subscribe ip-atm <your addr>". Hope this helps. Regards, Rajesh. taddy@cc.gatech.edu From list-mgr@ISI.EDU Wed Oct 4 12:06:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11471>; Wed, 4 Oct 1995 11:10:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11455>; Wed, 4 Oct 1995 11:10:19 -0700 Received: from cythera.unb.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA11448>; Wed, 4 Oct 1995 11:10:16 -0700 Received: from cythera.unb.ca (cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.6.12/8.6.5) with SMTP id PAA08296 for <mbone@isi.edu>; Wed, 4 Oct 1995 15:06:34 -0300 Date: Wed, 4 Oct 1995 15:06:34 -0300 (ADT) From: "Dwight E. Spencer" <spencer@unb.ca> To: mbone Subject: problems on a sparc 4. Message-Id: <Pine.SOL.3.91.951004144620.21557c-100000@cythera.unb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Afternoon I've been having a few problems with a sparc 4 that I've gotten setup for mbone applications. I've installed a SunVideo card into the workstation after the OS install, and installed the software (SUNWrtvc/xil,etc) to get that working. Works "ok". I installed Suns multicast patch, to get mrouted v 3.3 (3.4) working properly as well. This works "ok". I've also added an audio option. Now when I added this, I had audio problems (with all audio applications) and subsequently installed the audio patch for sparc 5's. This seemed to clear up the problem. however, I've recently been having kernel panics, usually "memory addres alignment" errors, ie: Oct 3 09:38:20 eclipse unix: BAD TRAP: type=7 rp=f05abddc addr=0 mmu_fsr=0 rw=0 Oct 3 09:38:20 eclipse unix: Xsun: Memory address alignment [traceback left out] Oct 3 09:38:20 eclipse unix: End traceback... Oct 3 09:38:20 eclipse unix: panic: Memory address alignment Oct 3 09:38:20 eclipse unix: syncing file systems... 2 2 ..... so on.. This Memory address alignment error occurs on any running process (nice, xterm, Xsun, etc). I asked our local unix administration, and they suggested that I remove the audio patch that I applied (for sparc 5's), and try from there. I'm in the process of taking this off, and if this stops audio from functioning on the workstation, then that makes it quite useless. Aside, the machine was quite stable up until I had installed the audio card and patch, and I'm not sure if the card itself, or the patch could be the problem. If anyone else out there is running a similar platform and could offer suggestions, I'd appreciate it. Installing SunOS was one suggestion I heard online, and didn't really fancy, since all of my workstations are running solaris, and I would rather stay with this os. ===== Hardware Specifics Sun Sparc 4/70, 32megs ram, 70 megs swap SunVideo Kit Sun 16bit audio option for sparc 4 Software Specifics Solaris 2.4, + recommended patches + multicast patch + sparc 5 audio patch ===== suggestions welcome, and thanks, dwight s. ---------------------------------------------------------------------------- Dwight E. Spencer Community Access Program eMail: spencer@unb.ca "C-Net" Server Administrator Phone: +1 506 453 4614 UNB, Fredericton, NB, Canada Url: http://cnet.unb.ca/cspace/staff/dspencer/ From list-mgr@ISI.EDU Wed Oct 4 12:41:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13339>; Wed, 4 Oct 1995 11:45:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13324>; Wed, 4 Oct 1995 11:44:48 -0700 Received: from cythera.unb.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA13308>; Wed, 4 Oct 1995 11:44:45 -0700 Received: from cythera.unb.ca (cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.6.12/8.6.5) with SMTP id PAA08505; Wed, 4 Oct 1995 15:41:04 -0300 Date: Wed, 4 Oct 1995 15:41:04 -0300 (ADT) From: "Dwight E. Spencer" <spencer@unb.ca> To: Magnus <e93_mda@it.kth.se> Cc: mbone, Tony Fitzgerald <jaf@unb.ca> Subject: Re: problems on a sparc 4. In-Reply-To: <199510041818.TAA23708@piraya.electrum.kth.se> Message-Id: <Pine.SOL.3.91.951004152131.21557i-100000@cythera.unb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 4 Oct 1995, Magnus wrote: > I think that the SS5's audio problem was only due to their audio chip, > which to my knowledge hasen't been used in any other machine. Possibly, in the solaris 2.4 patch report, this following is mentioned,: Patch-ID# 102125-02 Synopsis: SunOS 5.4: Audio device driver jumbo patch - I had this patch installed, and have just removed it. My audiocontrol works ok (I've an audio source going through line-in to audio out). I just tried vat, and talked to bill fenner, albeit choppy, but it was there. I'll keep using it as is, and see how it goes. > Hmm... this seems to be related to a bug that caused Sbus mapping errors. > Not sure anyhow, there is a bugfix for it. Check with people how has CDrom's. Could this be the culprit (taken from the messages file as well)? : Oct 3 09:32:34 eclipse unix: BAD TRAP: type=9 rp=f05e45bc addr=84ef3308 mmu_fsr=126 rw=1 Oct 3 09:32:34 eclipse unix: rpc.rstatd: Data fault Oct 3 09:32:34 eclipse unix: kernel read fault at addr=0x84ef3308, pme=0x0 [....] Oct 3 09:32:34 eclipse unix: Begin traceback... sp = f05e4608 Oct 3 09:32:36 eclipse unix: End traceback... Oct 3 09:32:36 eclipse unix: panic: Data fault Oct 3 09:32:37 eclipse unix: syncing file systems... [.....] Oct 3 09:32:37 eclipse unix: 2236 static and sysmap kernel pages [...] Oct 3 09:32:37 eclipse unix: WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@4,8400000/esp@4,8800000/sd@3,0 (sd3): Oct 3 09:32:37 eclipse unix: SCSI transport failed: reason 'reset': retrying command Oct 3 09:32:37 eclipse unix: 2886 total pages, dump succeeded > My experience comes from SS5's and SS20 machines. > Good luck! suggestions, again, welcome dwight s. ---------------------------------------------------------------------------- Dwight E. Spencer Community Access Program eMail: spencer@unb.ca "C-Net" Server Administrator Phone: +1 506 453 4614 UNB, Fredericton, NB, Canada Url: http://cnet.unb.ca/cspace/staff/dspencer/ From list-mgr@ISI.EDU Wed Oct 4 14:36:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25237>; Wed, 4 Oct 1995 15:40:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25220>; Wed, 4 Oct 1995 15:40:37 -0700 Received: from nic.near.net by venera.isi.edu (5.65c/5.61+local-22) id <AA25213>; Wed, 4 Oct 1995 15:40:36 -0700 Received: from wpine.com by nic.near.net id aa24176; 4 Oct 95 18:40 EDT Received: from visual.wpine.com by wpnext.wpine.com (8.6.9/WM-941104.2) id SAA19600; Wed, 4 Oct 1995 18:40:26 -0400 Received: from boggs.wpine.com.wpine.com by visual.wpine.com (8.6.9/VM-941107.1) id SAA01514; Wed, 4 Oct 1995 18:34:54 -0400 Received: by boggs.wpine.com.wpine.com (4.1/VN941029.1) id AA17838; Wed, 4 Oct 95 18:36:32 EDT Message-Id: <9510042236.AA17838@boggs.wpine.com.wpine.com> To: mbone Subject: DECstation 3100 running Ultrix 4.1, and multicasting. Date: Wed, 04 Oct 1995 18:36:31 -0400 From: Brian O'Shea <boshea@wpine.com> I have already gotten multicast working on several of our Sparc 2's running SunOS 4.1.1 and 4.1.2. (Piece of cake with the script provided!). However the Ultrix port isn't as automated and isn't working for me. I ran "nv 224.0.1.2 444" and I get an "ip_multicast_ttl: Invalid argument" error. Without boring everyone with the gory details, is there anybody out there that has Ultrix multicasting working that might be willing to help me isolate my stupidity or point me to some source I can use to test the multicast functionality? Thanks -bos +***********************************************************************+ + Brian O'Shea White Pine Software + + Network/OS Software Engineer 15 Messenger Square + + boshea@wpine.com Suite 8A + + Voice 508-699-9163 Fax 508-695-2378 Plainville MA, 02762 + + All it takes is all you've got. + +***********************************************************************+ From list-mgr@ISI.EDU Thu Oct 5 09:21:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11417>; Thu, 5 Oct 1995 00:25:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11278>; Thu, 5 Oct 1995 00:22:24 -0700 Received: from eros.EMBL-Heidelberg.DE by venera.isi.edu (5.65c/5.61+local-22) id <AA11269>; Thu, 5 Oct 1995 00:22:13 -0700 Received: from [193.175.249.138] (mac-cg3.EMBL-Heidelberg.DE) by EMBL-Heidelberg.DE (PMDF V4.3-7 #2491) id <01HW2P06A1E89ZMTOM@EMBL-Heidelberg.DE>; Thu, 5 Oct 1995 08:21:48 +0100 Date: Thu, 05 Oct 1995 08:21:48 +0100 Date-Warning: Date header was inserted by EMBL-Heidelberg.DE From: luca.toldo@EMBL-Heidelberg.DE (Luca Ida Giovanni TOLDO) Subject: unsubscribe X-Sender: toldo@odin.embl-heidelberg.de To: mbone Message-Id: <v0153050199caaed96165@[193.175.249.138]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT unsubscribe From list-mgr@ISI.EDU Thu Oct 5 10:41:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13359>; Thu, 5 Oct 1995 01:43:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13342>; Thu, 5 Oct 1995 01:42:07 -0700 Received: from eros.EMBL-Heidelberg.DE by venera.isi.edu (5.65c/5.61+local-22) id <AA13330>; Thu, 5 Oct 1995 01:41:55 -0700 Received: from [193.175.249.138] (mac-cg3.EMBL-Heidelberg.DE) by EMBL-Heidelberg.DE (PMDF V4.3-7 #2491) id <01HW2RSCS1809ZMXM4@EMBL-Heidelberg.DE>; Thu, 5 Oct 1995 09:41:47 +0100 Date: Thu, 05 Oct 1995 09:41:47 +0100 Date-Warning: Date header was inserted by EMBL-Heidelberg.DE From: Luca.Toldo@EMBL-Heidelberg.DE (Luca Ida Giovanni TOLDO) Subject: UNSUBSCRIBE X-Sender: toldo@odin.embl-heidelberg.de To: mbone Message-Id: <v0153050d99cac194c809@[193.175.249.138]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT UNSUBSCRIBE From list-mgr@ISI.EDU Wed Oct 4 21:45:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16953>; Thu, 5 Oct 1995 04:46:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16940>; Thu, 5 Oct 1995 04:45:06 -0700 Received: from mvs.oac.ucla.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA16933>; Thu, 5 Oct 1995 04:45:05 -0700 Message-Id: <199510051145.AA16933@venera.isi.edu> Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1) with BSMTP id 5936; Thu, 05 Oct 95 04:45:54 PST Date: Thu, 05 Oct 95 04:45 PDT To: rem-conf@ES.NET From: Denis DeLaRoca (310) 825-4580 <CSP1DWD@MVS.OAC.UCLA.EDU> Subject: Sound Cards/Drivers for 386/BSD Cc: mbone What audio cards and drivers are people with 386/BSD systems using with VAT and the other audio tools? Do any of these cards support full duplex? -- Denis From list-mgr@ISI.EDU Thu Oct 5 02:31:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26811>; Thu, 5 Oct 1995 09:31:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26792>; Thu, 5 Oct 1995 09:31:07 -0700 Received: from dns1.eecs.wsu.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA26784>; Thu, 5 Oct 1995 09:31:06 -0700 Received: from raghu by dns1.eecs.wsu.edu (8.6.10/8.940801) id JAA24868; Thu, 5 Oct 1995 09:31:01 -0700 From: Cauligi Raghavendra <raghu@eecs.wsu.edu> Received: by raghu (5.65) id AA08250; Thu, 5 Oct 1995 09:31:00 -0700 Message-Id: <9510051631.AA08250@raghu> Subject: Unsubscribe To: mbone Date: Thu, 5 Oct 1995 09:31:00 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 ME7] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 12 unsubscribe From list-mgr@ISI.EDU Thu Oct 5 04:29:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03891>; Thu, 5 Oct 1995 11:29:21 -0700 Received: from microplex.com (ludwig.microplex.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA03884>; Thu, 5 Oct 1995 11:29:19 -0700 Received: by microplex.com (4.1/SMI-4.1/920826) id AA01773; Thu, 5 Oct 95 11:29:17 PDT From: csd@microplex.com (Christian Daudt) Message-Id: <9510051829.AA01773@microplex.com> Subject: Tunnel request for Burnaby, BC, Canada To: mbone-na Date: Thu, 5 Oct 1995 11:29:16 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 736 Hi, I would like to request a MBONE tunnel. We're not network providers, but our provider is not interested in setting up a MBONE tunnel now. traceroute reveals (from ludwig.microplex.com): we are 7 hops away from ix-iinternet.on.canet.ca we are 5 hops away from border2-serial3-2.Seattle.mci.net I'm connected to fonorola and apparently these are their best connections to other networks. thanks in advance, Christian -- ---------------------------------------------------------------- Christian Daudt (csd@microplex.com) Software Engineer Microplex Systems Ltd. URL: http://www.microplex.com/ "You can tell how far we have to go, when FORTRAN is the language of supercomputers." -- Steven Feiner From list-mgr@ISI.EDU Thu Oct 5 09:06:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15860>; Thu, 5 Oct 1995 16:06:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15843>; Thu, 5 Oct 1995 16:06:15 -0700 Received: from elaine20.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA15836>; Thu, 5 Oct 1995 16:06:13 -0700 Received: (from mandami@localhost) by elaine20.Stanford.EDU (8.6.12/8.6.12) id QAA19463 for mbone@ISI.edu; Thu, 5 Oct 1995 16:06:12 -0700 From: Meng-Day Yu <mandami@leland.Stanford.EDU> Message-Id: <199510052306.QAA19463@elaine20.Stanford.EDU> Subject: VIC problems To: mbone Date: Thu, 5 Oct 1995 16:06:11 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1162 When I click the transmit button in VICv2.6, I receive the following error message: ----------------------------------------------------- Salamanca:~/mbone/atm/script> XilDefaultErrorFunc: error category: System error string: SUNWRtvc: could not open SUNWRtvc device error id: SUNWrtvc-4 primary error detected at location RtvcCreateType280 in XIL object info: No such device or address XilDefaultErrorFunc: error category: System error string: Could not create imagetype error id: di-188 secondary error detected at location RtvcCreateType190 in XIL XilDefaultErrorFunc: error category: System error string: Could not create input/output device error id: di-149 primary error detected at location XilImage1730 in XIL XilDefaultErrorFunc: error category: System error string: Could not create image error id: di-147 secondary error detected at location XilSystemState228 in XIL Bus Error ------------------------------------------------------- I am running VIC on a SUNSparc5 running Solaris 2.4. I am using a SUNVideo card. Does anyone have any ideas? Mandel From list-mgr@ISI.EDU Fri Oct 6 02:18:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19192>; Thu, 5 Oct 1995 17:24:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18968>; Thu, 5 Oct 1995 17:18:51 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA18959>; Thu, 5 Oct 1995 17:18:48 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id BAA09664; Fri, 6 Oct 1995 01:15:46 +0100 Message-Id: <199510060015.BAA09664@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: Meng-Day Yu <mandami@leland.stanford.edu> Cc: mbone, e93_mda@it.kth.se Subject: Re: VIC problems In-Reply-To: Your message of "Thu, 05 Oct 1995 16:06:11 MST." <199510052306.QAA19463@elaine20.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Oct 1995 01:18:22 +0100 From: Magnus <e93_mda@it.kth.se> > When I click the transmit button in VICv2.6, I receive > the following error message: > > I am running VIC on a SUNSparc5 running Solaris 2.4. I am using a > SUNVideo card. Does anyone have any ideas? > > Mandel > Well, there are two binaries (at least :-) vic.xil and vic.rtvc. I'm not sure if this still goes for 2.6, but anyway, get all versions and test them. (Also check stuff like, is the green LED shining on the back, is the camera working, cause otherwise these errors might occur as well) Magnus (with some help of Erik Brage) From list-mgr@ISI.EDU Fri Oct 6 11:10:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11640>; Fri, 6 Oct 1995 02:11:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11627>; Fri, 6 Oct 1995 02:10:30 -0700 Received: from cismsun.univ-lyon1.fr by venera.isi.edu (5.65c/5.61+local-22) id <AA11620>; Fri, 6 Oct 1995 02:10:22 -0700 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id KAA04079; Fri, 6 Oct 1995 10:10:12 +0100 Message-Id: <199510060910.KAA04079@cismsun.univ-lyon1.fr> Subject: Re: VIC problems To: mandami@leland.Stanford.EDU (Meng-Day Yu) Date: Fri, 6 Oct 1995 10:10:12 +0100 (MET) From: "Lucia Gradinariu" <lucia@univ-lyon1.fr> Cc: mbone, rem-conf@es.net In-Reply-To: <199510052306.QAA19463@elaine20.Stanford.EDU> from "Meng-Day Yu" at Oct 5, 95 04:06:11 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1656 > > > When I click the transmit button in VICv2.6, I receive > the following error message: > > > > ----------------------------------------------------- > > Salamanca:~/mbone/atm/script> XilDefaultErrorFunc: > error category: System > error string: SUNWRtvc: could not open SUNWRtvc device > error id: SUNWrtvc-4 > primary error detected at location RtvcCreateType280 in XIL > object info: No such device or address > XilDefaultErrorFunc: > error category: System > error string: Could not create imagetype > error id: di-188 > secondary error detected at location RtvcCreateType190 in XIL > XilDefaultErrorFunc: > error category: System > error string: Could not create input/output device > error id: di-149 > primary error detected at location XilImage1730 in XIL > XilDefaultErrorFunc: > error category: System > error string: Could not create image > error id: di-147 > secondary error detected at location XilSystemState228 in XIL > Bus Error > ------------------------------------------------------- > > I am running VIC on a SUNSparc5 running Solaris 2.4. I am using a > SUNVideo card. Does anyone have any ideas? > Mandel > I have this problem with vic.xil, in fact this is the behaviour of the SunVideo driven by xil like functions when there is no image to capture (I'm not sure it's still the same when there is an image which is not in NTSC or PAL format). Try vic.rtvc I saw it works (gives a black image) even when there is no camera. Lucia.Gradinariu@univ-lyon1.fr PS: I think we must use rem-conf@es.net for this kind of questions From list-mgr@ISI.EDU Fri Oct 6 02:18:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12721>; Fri, 6 Oct 1995 03:21:38 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12643>; Fri, 6 Oct 1995 03:18:19 -0700 Received: from andy.dia.atd.net by venera.isi.edu (5.65c/5.61+local-22) id <AA12633>; Fri, 6 Oct 1995 03:18:17 -0700 Received: (from crobson@localhost) by andy.dia.atd.net (8.6.9/8.6.9) id GAA00495; Fri, 6 Oct 1995 06:18:54 -0400 Date: Fri, 6 Oct 1995 06:18:53 -0400 (EDT) From: Chris Robson ATDNet Admin <crobson@andy.dia.atd.net> To: mbone Subject: VAT/VIC/NV/WB/SD for Win95 Message-Id: <Pine.SUN.3.91.951006061727.485B-100000@andy.dia.atd.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Any chance this has been or will be done? ...chris From list-mgr@ISI.EDU Fri Oct 6 13:15:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13603>; Fri, 6 Oct 1995 04:18:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13573>; Fri, 6 Oct 1995 04:15:40 -0700 Received: from jupiter.pt.hk-r.se by venera.isi.edu (5.65c/5.61+local-22) id <AA13565>; Fri, 6 Oct 1995 04:15:36 -0700 Received: from epimetheus.pt.hk-r.se (mpt95aes@epimetheus.pt.hk-r.se [194.47.132.19]) by jupiter.pt.hk-r.se (8.6.9/8.6.9) with ESMTP id MAA16584 for <mbone@ISI.EDU>; Fri, 6 Oct 1995 12:15:37 +0100 From: Andrew Eskilsson <mpt95aes@pt.hk-r.se> Received: (mpt95aes@localhost) by epimetheus.pt.hk-r.se (8.6.9/8.6.9) id MAA07959; Fri, 6 Oct 1995 12:15:32 +0100 Date: Fri, 6 Oct 1995 12:15:32 +0100 Message-Id: <199510061115.MAA07959@epimetheus.pt.hk-r.se> To: mbone In-Reply-To: Meng-Day Yu's message of Thu, 5 Oct 1995 16:06:11 -0700 (PDT) Subject: Re: VIC problems References: <199510052306.QAA19463@elaine20.Stanford.EDU> / Meng-Day Yu <mandami@leland.Stanford.EDU> wrote: | | | I am running VIC on a SUNSparc5 running Solaris 2.4. I am using a | SUNVideo card. Does anyone have any ideas? | | Mandel | I have interpreted these erromessages as if some device already has locked the video output (a "bad" exit from som other program or even vic himself). I am going to dig deeper into this, but the intermediate solution I use is to reboot the computer. /andy From list-mgr@ISI.EDU Fri Oct 6 03:22:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13668>; Fri, 6 Oct 1995 04:23:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13651>; Fri, 6 Oct 1995 04:22:55 -0700 Received: from VAX.HEC.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA13644>; Fri, 6 Oct 1995 04:22:53 -0700 Received: from VAX.HEC.CA by VAX.HEC.CA (PMDF V5.0-5 #10107) id <01HW417OGJSS00067R@VAX.HEC.CA> for MBONE@ISI.EDU; Fri, 06 Oct 1995 07:22:44 -0400 (EDT) Date: Fri, 06 Oct 1995 07:22:44 -0400 (EDT) From: Herve Goyette <Herve.Goyette@HEC.CA> Subject: unsubscribe To: MBONE Message-Id: <01HW417OGTGE00067R@VAX.HEC.CA> Organization: Ecole des Hautes Etudes Commerciales de Montreal X-Vms-To: MBONE@ISI.EDU Mime-Version: 1.0 X-Mailer: PMDF V5.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT unsubscribe From list-mgr@ISI.EDU Fri Oct 6 04:16:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14521>; Fri, 6 Oct 1995 05:29:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14419>; Fri, 6 Oct 1995 05:18:30 -0700 Received: from sioux.eel.ufl.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA14412>; Fri, 6 Oct 1995 05:18:29 -0700 Received: from iriquois.eel.ufl.edu by sioux.eel.ufl.edu (1.37.109.16/4.09) id AA142761905; Fri, 6 Oct 1995 08:18:25 -0400 From: "Mahesh Ramachandran" <rr@eel.ufl.edu> Message-Id: <199510061218.AA142761905@sioux.eel.ufl.edu> Subject: Re: VIC problems To: mandami@leland.Stanford.EDU (Meng-Day Yu) Date: Fri, 6 Oct 1995 08:16:34 -0400 (EDT) Cc: mbone In-Reply-To: <199510052306.QAA19463@elaine20.Stanford.EDU> from "Meng-Day Yu" at Oct 5, 95 04:06:11 pm Organization: Electrical Engineering, University of Florida ___ X-Phone: (904) 392-4568 <o,o> X-Operating-System: HP-UX A.09.01 9000/715 ( . ) X-Url: http://www.eel.ufl.edu/~rr -"-"- X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 693 Meng-Day Yu wrote: |> |> When I click the transmit button in VICv2.6, I receive |> the following error message: |> [...] |> I am running VIC on a SUNSparc5 running Solaris 2.4. I am using a |> SUNVideo card. Does anyone have any ideas? |> The error is caused because you dont have permission to access the devices SUNW,rtvc@1,0:rtvc0 and SUNW,rtvc@1,0:rtvcctl0 in /devices/iommu@0,10000000/sbus@0,10001000. So go in there and change the permission on them such that you can r/w to them. However, at every reboot the permissions on those devices would get reset. I'm yet to figure out from where Solaris is doing that. Or else just run as root ... things should work fine. -rr -- From list-mgr@ISI.EDU Fri Oct 6 05:10:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15048>; Fri, 6 Oct 1995 06:11:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15041>; Fri, 6 Oct 1995 06:10:52 -0700 Received: from gw2.att.com by venera.isi.edu (5.65c/5.61+local-22) id <AA15034>; Fri, 6 Oct 1995 06:10:48 -0700 Received: from mtgpfs1.mt.att.com by ig1.att.att.com id AA27127; Fri, 6 Oct 95 09:07:50 EDT Received: from mtgpdf12.gp (mtgpdf12.mt.att.com) by mtgpfs1.mt.att.com (4.1/EMS-1.1.1 SunOS) id AA20967; Fri, 6 Oct 95 09:10:23 EDT Date: Fri, 6 Oct 95 09:10:23 EDT Message-Id: <9510061310.AA20967@mtgpfs1.mt.att.com> From: ldo@mtgpfs1.mt.att.com (Lawrence D Odell) To: mbone Subject: unsubscribe unsubscribe From list-mgr@ISI.EDU Fri Oct 6 15:18:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15203>; Fri, 6 Oct 1995 06:20:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15192>; Fri, 6 Oct 1995 06:20:04 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA15185>; Fri, 6 Oct 1995 06:20:02 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA19297>; Fri, 6 Oct 1995 06:19:57 -0700 Message-Id: <199510061319.AA19297@quark.isi.edu> Received: from howser.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.21391-0@bells.cs.ucl.ac.uk>; Fri, 6 Oct 1995 14:18:35 +0100 X-Mailer: exmh version 1.6.2 7/18/95 From: Piers O'Hanlon <P.OHanlon@cs.ucl.ac.uk> Organisation: University College London, AV Dept. Phone: +44 171 636 8333 ext 3056 (Hang on in there...) X-Url: http://av.avc.ucl.ac.uk To: Mahesh Ramachandran <rr@eel.ufl.edu> Cc: P.OHanlon@cs.ucl.ac.uk, mbone Subject: Re: VIC problems In-Reply-To: Your message of "Fri, 06 Oct 95 08:16:34 EDT." <199510061218.AA142761905@sioux.eel.ufl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Oct 95 14:18:30 +0100 Sender: P.OHanlon@cs.ucl.ac.uk > Meng-Day Yu wrote: > |> > |> When I click the transmit button in VICv2.6, I receive > |> the following error message: > |> > [...] > |> I am running VIC on a SUNSparc5 running Solaris 2.4. I am using a > |> SUNVideo card. Does anyone have any ideas? > |> > > The error is caused because you dont have permission to access the > devices SUNW,rtvc@1,0:rtvc0 and SUNW,rtvc@1,0:rtvcctl0 in > /devices/iommu@0,10000000/sbus@0,10001000. > So go in there and change the permission on them such that you can r/w > to them. > > However, at every reboot the permissions on those devices would get > reset. I'm yet to figure out from where Solaris is doing that. > Or else just run as root ... things should work fine. > > -rr > > -- Try: /etc/logindevperm man -s 4 logindevperm Piers O'Hanlon ______________ Audio Visual Centre University College London. From list-mgr@ISI.EDU Fri Oct 6 17:51:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16485>; Fri, 6 Oct 1995 06:54:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16431>; Fri, 6 Oct 1995 06:53:45 -0700 Received: from msa.tte.vtt.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA16399>; Fri, 6 Oct 1995 06:53:42 -0700 Received: (from msa@localhost) by msa.tte.vtt.fi (8.7/8.7) id PAA05504; Fri, 6 Oct 1995 15:51:55 +0200 (EET) Date: Fri, 6 Oct 1995 15:51:55 +0200 (EET) From: Markku Savela <msa@msa.tte.vtt.fi> Message-Id: <199510061351.PAA05504@msa.tte.vtt.fi> To: mbone Subject: Whta is going on MBONE? Reply-To: msa@hemuli.tte.vtt.fi (Markku Savela) I suddenly started getting a lot of messages like Oct 6 15:49:33 msa vmunix: ip_mforward: ip_mrouter socket queue full and things break.. Something is flooding the mbone with something?? I am running mrouted 3.5. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From list-mgr@ISI.EDU Fri Oct 6 07:50:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16490>; Fri, 6 Oct 1995 06:54:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16469>; Fri, 6 Oct 1995 06:53:51 -0700 Received: from cythera.unb.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA16433>; Fri, 6 Oct 1995 06:53:45 -0700 Received: from cythera.unb.ca (cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.6.12/8.6.5) with SMTP id KAA20721 for <mbone@isi.edu>; Fri, 6 Oct 1995 10:50:08 -0300 Date: Fri, 6 Oct 1995 10:50:07 -0300 (ADT) From: "Dwight E. Spencer" <spencer@unb.ca> To: mbone Subject: someone doing something bad? Message-Id: <Pine.SOL.3.91.951006104824.21557h-100000@cythera.unb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII is someone flooding routes to the mbone? my mrouted is having a fieldday with my cpu, and i've got no local traffic. the only error in my log files are: Oct 6 10:11:34 cythera last message repeated 2 times Oct 6 10:22:22 cythera mrouted[114]: warning - prune message received incorrectly PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 114 root -25 0 3836K 2952K run 172:42 78.05% 87.47% mrouted dwight s. ---------------------------------------------------------------------------- Dwight E. Spencer Community Access Program eMail: spencer@unb.ca "C-Net" Server Administrator Phone: +1 506 453 4614 UNB, Fredericton, NB, Canada Url: http://cnet.unb.ca/cspace/staff/dspencer/ From list-mgr@ISI.EDU Fri Oct 6 06:09:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16956>; Fri, 6 Oct 1995 07:10:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16945>; Fri, 6 Oct 1995 07:10:02 -0700 Received: from vax.darpa.mil (darpa.mil) by venera.isi.edu (5.65c/5.61+local-22) id <AA16938>; Fri, 6 Oct 1995 07:10:00 -0700 Received: from next146.darpa.mil (next146.darpa.mil) by vax.darpa.mil (5.65c/5.61+local-5) id <AA04738>; Fri, 6 Oct 1995 10:08:52 -0400 Received: by next146.darpa.mil (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA01328; Fri, 6 Oct 95 10:09:25 EDT Date: Fri, 6 Oct 1995 10:09:23 -0400 (EDT) From: bmiller@ito.snap.org Subject: Re: Whta is going on MBONE? To: Markku Savela <msa@hemuli.tte.vtt.fi> Cc: mbone Message-Id: <951006100923.1122AABmI.bmiller@next146> In-Reply-To: <199510061351.PAA05504@msa.tte.vtt.fi> Mime-Version: 1.0 (Generated by Eloquent) Content-Type: text/plain; charset=US-ASCII X-Mailer: Eloquent[2.01]; Eloquent is a Trademark of Take 3 |>I suddenly started getting a lot of messages like |> |>Oct 6 15:49:33 msa vmunix: ip_mforward: ip_mrouter socket queue full |> |>and things break.. Something is flooding the mbone with something?? I |>am running mrouted 3.5. Same thing here. I had to kill mrouted on noc.hpc.org - it kept killing my machine; 'mbuf map full' is it's last dying gasp. brian, who promises to get a new version of mrouted up very soon From list-mgr@ISI.EDU Fri Oct 6 06:21:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17256>; Fri, 6 Oct 1995 07:22:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17244>; Fri, 6 Oct 1995 07:21:57 -0700 Received: from davinci.gmu.edu ([206.197.101.10]) by venera.isi.edu (5.65c/5.61+local-22) id <AA17237>; Fri, 6 Oct 1995 07:21:55 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id KAA12346; Fri, 6 Oct 1995 10:21:57 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199510061421.KAA12346@davinci.gmu.edu> Subject: Re: VAT/VIC/NV/WB/SD for Win95 To: crobson@andy.dia.atd.net (Chris Robson ATDNet Admin) Date: Fri, 6 Oct 1995 10:21:57 -0400 (EDT) Cc: mbone In-Reply-To: <Pine.SUN.3.91.951006061727.485B-100000@andy.dia.atd.net> from "Chris Robson ATDNet Admin" at Oct 6, 95 06:18:53 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 366 My guess is that they don't want this done so as to not flood the mbone with Window's users bandwidth. Michael > > > Any chance this has been or will be done? > > > ...chris > -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Fri Oct 6 16:32:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17539>; Fri, 6 Oct 1995 07:33:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17521>; Fri, 6 Oct 1995 07:32:44 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA17510>; Fri, 6 Oct 1995 07:32:11 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id PAA21731 for <mbone@isi.edu>; Fri, 6 Oct 1995 15:32:06 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id PAA02633; Fri, 6 Oct 1995 15:32:01 +0100 Date: Fri, 6 Oct 1995 15:32:00 +0100 (BST) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: mbone Subject: mrouted explosion Message-Id: <Pine.SV4.3.91.951006153002.1907A-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Somebody is injecting unicast routes into the multicast routing table. My mrouted has over 25,000 entries at the moment and is using up considerable amounts of CPU. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Fri Oct 6 06:29:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17734>; Fri, 6 Oct 1995 07:37:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17717>; Fri, 6 Oct 1995 07:36:31 -0700 Received: from maelstrom.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA17710>; Fri, 6 Oct 1995 07:36:30 -0700 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.6.10/8.6.6) id KAA13847; Fri, 6 Oct 1995 10:29:33 -0400 Message-Id: <199510061429.KAA13847@maelstrom.cc.mcgill.ca> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Yves Lepage <yves@CC.McGill.CA> Date: Fri, 6 Oct 95 10:29:31 -0400 To: msa@hemuli.tte.vtt.fi (Markku Savela) Subject: Re: Whta is going on MBONE? Cc: mbone Reply-To: yves@cc.mcgill.ca References: <199510061351.PAA05504@msa.tte.vtt.fi> Hello, Same here. My mrouted is taking up 115.6% (FreeBSD festure? ;-)) of the cpu and it seems to be passing the same disease down to my downfeeds... Using tcpdump, I could not find any evidence of someone flooding... Yves Lepage yves@cc.mcgill.ca From list-mgr@ISI.EDU Fri Oct 6 16:54:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18427>; Fri, 6 Oct 1995 07:58:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18418>; Fri, 6 Oct 1995 07:58:17 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA18411>; Fri, 6 Oct 1995 07:58:16 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA19927>; Fri, 6 Oct 1995 07:56:40 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.28432-0@bells.cs.ucl.ac.uk>; Fri, 6 Oct 1995 15:54:51 +0100 From: Mark Handley <M.Handley@cs.ucl.ac.uk> Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: bmiller@ito.snap.org Cc: Markku Savela <msa@hemuli.tte.vtt.fi>, mbone Subject: Re: Whta is going on MBONE? In-Reply-To: Your message of "Fri, 06 Oct 95 10:09:23 EDT." <951006100923.1122AABmI.bmiller@next146> Date: Fri, 06 Oct 95 15:54:45 +0100 Message-Id: <3721.812991285@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >|>I suddenly started getting a lot of messages like >|> >|>Oct 6 15:49:33 msa vmunix: ip_mforward: ip_mrouter socket queue full >|> >|>and things break.. Something is flooding the mbone with something?? I >|>am running mrouted 3.5. > >Same thing here. I had to kill mrouted on noc.hpc.org - it kept >killing my machine; 'mbuf map full' is it's last dying gasp. I'm seeing an abnormally large multicast routing table (on laphroaig.cs.ucl.ac.uk): Multicast Routing Table (14106 entries) Origin-Subnet From-Gateway Metric Tmr In-Vif Out-Vifs Of these, 11036 are "From-Gateway" mbone.sura.net, which to me implies someone outside Europe (either in the US or behind the US) dumped a lot of routes into DVMRP routing. Like everyone else, laphroaig's very heavily loaded.... Mark From list-mgr@ISI.EDU Fri Oct 6 01:09:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18789>; Fri, 6 Oct 1995 08:09:51 -0700 Received: from microplex.com (ludwig.microplex.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA18782>; Fri, 6 Oct 1995 08:09:50 -0700 Received: by microplex.com (4.1/SMI-4.1/920826) id AA08845; Fri, 6 Oct 95 08:09:49 PDT From: csd@microplex.com (Christian Daudt) Message-Id: <9510061509.AA08845@microplex.com> Subject: New info on tunnel request for Burnaby To: mbone-na Date: Fri, 6 Oct 1995 08:09:47 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 966 Hello again, I have just talked to my provider here (which is now called iSTAR Internet and not fONOROLA Internet) and here is the situation. From Vancouver, we have the following options to go out (and come in): - MCI in Seattle - ANS in Seattle - fONOROLA in Ottawa (which is being upgraded to a full T1 these days). From Ottawa, there are direct connections to Toronto, CA*net and New York. These are all full T1 links. So I would like to request a tunnel to people directly connected to those networks (iSTAR also told me that the 2 links to Seattle much less likely to be congested so they would be a better choice). Thanks again, -- ---------------------------------------------------------------- Christian Daudt (csd@microplex.com) Software Engineer Microplex Systems Ltd. URL: http://www.microplex.com/ "You can tell how far we have to go, when FORTRAN is the language of supercomputers." -- Steven Feiner From list-mgr@ISI.EDU Fri Oct 6 07:14:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18920>; Fri, 6 Oct 1995 08:15:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18906>; Fri, 6 Oct 1995 08:14:32 -0700 Received: from chips.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA18899>; Fri, 6 Oct 1995 08:14:30 -0700 Received: (dschluss@localhost) by chips.engin.umich.edu (8.6.12/8.6.4) id LAA29217; Fri, 6 Oct 1995 11:14:20 -0400 Date: Fri, 6 Oct 1995 11:14:18 -0400 (EDT) From: "david a. schlussel" <dschluss@engin.umich.edu> To: MBone <mbone> Subject: Re: Whta is going on MBONE? In-Reply-To: <951006100923.1122AABmI.bmiller@next146> Message-Id: <Pine.SUN.3.91.951006111304.28507L-100000@chips.engin.umich.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII mrouted was taking up 22% of my cpu, looks like the same problem +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ On Fri, 6 Oct 1995 bmiller@ito.snap.org wrote: > |>I suddenly started getting a lot of messages like > |> > |>Oct 6 15:49:33 msa vmunix: ip_mforward: ip_mrouter socket queue full > |> > |>and things break.. Something is flooding the mbone with something?? I > |>am running mrouted 3.5. > > Same thing here. I had to kill mrouted on noc.hpc.org - it kept > killing my machine; 'mbuf map full' is it's last dying gasp. > > brian, who promises to get a new version of mrouted up very soon > > From list-mgr@ISI.EDU Fri Oct 6 07:17:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19143>; Fri, 6 Oct 1995 08:18:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19120>; Fri, 6 Oct 1995 08:18:01 -0700 Received: from chips.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA19113>; Fri, 6 Oct 1995 08:18:00 -0700 Received: (dschluss@localhost) by chips.engin.umich.edu (8.6.12/8.6.4) id LAA29223; Fri, 6 Oct 1995 11:17:56 -0400 Date: Fri, 6 Oct 1995 11:17:54 -0400 (EDT) From: "david a. schlussel" <dschluss@engin.umich.edu> To: CU-SEEME <CU-SEEME-L@cornell.edu> Cc: MBone <mbone> Subject: mrouted explosion (fwd) Message-Id: <Pine.SUN.3.91.951006111723.28507M-100000@chips.engin.umich.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm guessing this has something to do with cu-seemers +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ---------- Forwarded message ---------- Date: Fri, 6 Oct 1995 15:32:00 +0100 (BST) From: Graeme Wood <jaw@ucs.ed.ac.uk> To: mbone@ISI.EDU Subject: mrouted explosion Somebody is injecting unicast routes into the multicast routing table. My mrouted has over 25,000 entries at the moment and is using up considerable amounts of CPU. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Fri Oct 6 17:41:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20037>; Fri, 6 Oct 1995 08:41:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20024>; Fri, 6 Oct 1995 08:41:24 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA20017>; Fri, 6 Oct 1995 08:41:22 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id QAA21107; Fri, 6 Oct 1995 16:38:44 +0100 Message-Id: <199510061538.QAA21107@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: Graeme.Wood@ucs.ed.ac.uk Cc: mbone, e93_mda@it.kth.se Subject: Re: mrouted explosion In-Reply-To: Your message of "Fri, 06 Oct 1995 15:32:00 +0100." <Pine.SV4.3.91.951006153002.1907A-100000@scorpio.ucs.ed.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Oct 1995 16:41:27 +0100 From: Magnus <e93_mda@it.kth.se> > Somebody is injecting unicast routes into the multicast routing table. > My mrouted has over 25,000 entries at the moment and is using up > considerable amounts of CPU. Hmm... unicast routes in multicast routing tables... not what we want rigth now, do we?? I have heard this before.... Magnus From list-mgr@ISI.EDU Fri Oct 6 02:00:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21166>; Fri, 6 Oct 1995 09:05:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20859>; Fri, 6 Oct 1995 09:01:16 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA20852>; Fri, 6 Oct 1995 09:01:15 -0700 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id JAA04075; Fri, 6 Oct 1995 09:00:23 -0700 X-Sender: fred@stilton.cisco.com Message-Id: <v0213050bac9afc22ca4c@[171.69.128.114]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Oct 1995 09:00:25 -0700 To: mbenson@davinci.gmu.edu (Michael Benson) From: fred@cisco.com (Fred Baker) Subject: Re: VAT/VIC/NV/WB/SD for Win95 Cc: crobson@andy.dia.atd.net (Chris Robson ATDNet Admin), mbone At 10:21 AM 10/6/95, Michael Benson wrote: >My guess is that they don't want this done so as to not flood the >mbone with Window's users bandwidth. My guess is that it's not the bandwidth they'd worry about. If you want Win95 versions of these, I'd suggest that you convince Van and company to spin off a Windows development shop and fund their research with it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "I know they'll sell it to me, I saw it at InterOp" From list-mgr@ISI.EDU Fri Oct 6 08:06:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21240>; Fri, 6 Oct 1995 09:06:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21180>; Fri, 6 Oct 1995 09:06:13 -0700 Received: from davinci.gmu.edu ([206.197.101.10]) by venera.isi.edu (5.65c/5.61+local-22) id <AA21173>; Fri, 6 Oct 1995 09:06:10 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id MAA12800; Fri, 6 Oct 1995 12:06:19 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199510061606.MAA12800@davinci.gmu.edu> Subject: Re: VAT/VIC/NV/WB/SD for Win95 To: fred@cisco.com (Fred Baker) Date: Fri, 6 Oct 1995 12:06:19 -0400 (EDT) Cc: crobson@andy.dia.atd.net, mbone In-Reply-To: <v0213050bac9afc22ca4c@[171.69.128.114]> from "Fred Baker" at Oct 6, 95 09:00:25 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 872 My apologies if I am mistaken, but I thought several people on this list have offered to do ports of the code to Windows provided they can get the source... Michael > > At 10:21 AM 10/6/95, Michael Benson wrote: > >My guess is that they don't want this done so as to not flood the > >mbone with Window's users bandwidth. > > My guess is that it's not the bandwidth they'd worry about. If you want > Win95 versions of these, I'd suggest that you convince Van and company to > spin off a Windows development shop and fund their research with it. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > "I know they'll sell it to me, I saw it at InterOp" > > -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Fri Oct 6 02:22:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22031>; Fri, 6 Oct 1995 09:23:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22005>; Fri, 6 Oct 1995 09:22:42 -0700 Received: from hitl.hitl.washington.edu (hitl-new.hitl.washington.edu) by venera.isi.edu (5.65c/5.61+local-22) id <AA21998>; Fri, 6 Oct 1995 09:22:41 -0700 Received: from porter.hitl.washington.edu (porter.hitl.washington.edu [128.95.74.40]) by hitl.hitl.washington.edu (8.6.12/8.6.12) with SMTP id JAA26088 for <mbone@isi.edu>; Fri, 6 Oct 1995 09:22:40 -0700 Date: Fri, 6 Oct 1995 09:22:40 -0700 (PDT) From: Paul Schwartz <pschwrtz@hitl.washington.edu> To: mbone Subject: subscribe Message-Id: <Pine.OSF.3.91.951006092215.15875B-100000@porter.hitl.washington.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe //---pschwrtz@hitl.washington.edu------------------ Human Interface Technology Laboratory, University of Washington For beatification |"Notes From a Bottle two miracles are required; | Found on the Beach at Carmel" For martyrdom, none. | Evan S. Connell, Jr. From list-mgr@ISI.EDU Fri Oct 6 02:40:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22910>; Fri, 6 Oct 1995 09:41:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22887>; Fri, 6 Oct 1995 09:41:22 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA22880>; Fri, 6 Oct 1995 09:41:20 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id JAA06070; Fri, 6 Oct 1995 09:40:14 -0700 Message-Id: <199510061640.JAA06070@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Magnus <e93_mda@it.kth.se> Cc: Graeme.Wood@ucs.ed.ac.uk, mbone Subject: Re: mrouted explosion In-Reply-To: Your message of "Fri, 06 Oct 1995 16:41:27 BST." <199510061538.QAA21107@piraya.electrum.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Oct 1995 09:40:13 -0700 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> No problems over here with FreeBSD and mrouted 3.6. Amancio >>> Magnus said: > > Somebody is injecting unicast routes into the multicast routing table. > > My mrouted has over 25,000 entries at the moment and is using up > > considerable amounts of CPU. > > Hmm... unicast routes in multicast routing tables... not what we want rigth > now, > do we?? > > I have heard this before.... > > Magnus > > From list-mgr@ISI.EDU Fri Oct 6 18:35:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22996>; Fri, 6 Oct 1995 09:44:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22802>; Fri, 6 Oct 1995 09:38:50 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA22795>; Fri, 6 Oct 1995 09:38:49 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA21005>; Fri, 6 Oct 1995 09:38:21 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.04132-0@bells.cs.ucl.ac.uk>; Fri, 6 Oct 1995 17:35:47 +0100 To: fred@cisco.com (Fred Baker) Cc: mbone Subject: Re: VAT/VIC/NV/WB/SD for Win95 In-Reply-To: Your message of "Fri, 06 Oct 95 09:00:25 PDT." <v0213050bac9afc22ca4c@[171.69.128.114]> Date: Fri, 06 Oct 95 17:35:47 +0100 Message-Id: <11346.812997347@cs.ucl.ac.uk> From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> >My guess is that it's not the bandwidth they'd worry about. If you want >Win95 versions of these, I'd suggest that you convince Van and company to >spin off a Windows development shop and fund their research with it. the mbone tools are all releatively simple in terms of their API requirements GUI and Video output: most require tcl/tk, some require raw X a couple need both Windows and MAC equivalents are either trivial, or easy... Network: they require multicast sockets winsock (e.g. FTP s/ws or trumpet or the latest microsoft) all do this very very close to the yway bsd ("deering") sockets work Video Input ivs, nv and vic have an abstraction for the idea of a framegrabber already - to retro fit the video for windows abstraction should be relatively simple... Video Output - see above... Audio i/o this is either hte most tricky or the easiest depending your point of view. Most assume 8 bit PCM samples, though some just assume a read of x bytes gives you at most x bytes, and that the application knows the sample rate/size so may be able to use this as a clock too... Finally, the tricky bit: Timers and Tasking Some use select based wait loops to schedule their i/o. while some use the read completion on a synchronous input sample (e.g. audio above)...and yet others use real timer events (poor accuracy - e.g. sigalrm but some versions of Un*x do have reasonable itimer granularity...) Some use 1 task and mux/demux the multiple audio/video etc streams, others spawn a child per input stream...... of course, they are all mono-media tools (except ivs) so if you don't have some decent taskig (though cooperative multitasking like MACs or Windows 3 may just be enough - in fact ,the lack of preemtpiton in them may make some aspects of things easier!) Interstream Synchrionisation - as far as i know, we are the only people so far t try synching audio/video are LBL and us....we do it in a way that is compatibvle wih windows 3 tasking as far as i can tell....so it should be straightforward i'm waiting for a C and C++ compiler and the net to get good enuff so i can ftp the tcl/tk release for windows, and a book on how to get at audio under windows 3.... jon p.s. you could of course just also run solaris on you intel processor of course, or linux if you are more anarchistically inclined... but for the great unwashed M*soft users, we feel we ought to enlgihten their mbone access somehow... From list-mgr@ISI.EDU Fri Oct 6 02:20:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25764>; Fri, 6 Oct 1995 10:37:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25640>; Fri, 6 Oct 1995 10:34:27 -0700 Received: from osi-east.es.net by venera.isi.edu (5.65c/5.61+local-22) id <AA25633>; Fri, 6 Oct 1995 10:34:25 -0700 Received: from sas-hp.nersc.gov by osi-east.es.net with ESnet SMTP (PP); Fri, 6 Oct 1995 10:33:50 -0700 Received: from [198.124.2.67] (bacon-mac.es.net) by sas-hp.nersc.gov with SMTP (1.37.109.16/16.3) id AA264270826; Fri, 6 Oct 1995 10:33:46 -0700 X-Sender: aiken@sas-sun.nersc.gov Message-Id: <v02110112ac9b21ae3ad2@[198.124.2.67]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Oct 1995 10:20:04 -0800 To: mbenson@davinci.gmu.edu (Michael Benson), fred@cisco.com (Fred Baker), crobson@andy.dia.atd.net, mbone From: aiken@es.net (Robert J. Aiken) Subject: e: VAT/VIC/NV/WB/SD for Win95- Who wanst to develop these? > From: mbenson@davinci.gmu.edu (Michael Benson) > Message-Id: <199510061606.MAA12800@davinci.gmu.edu> > Subject: Re: VAT/VIC/NV/WB/SD for Win95 > To: fred@cisco.com (Fred Baker) > Date: Fri, 6 Oct 1995 12:06:19 -0400 (EDT) > Cc: crobson@andy.dia.atd.net, mbone@ISI.EDU > In-Reply-To: <v0213050bac9afc22ca4c@[171.69.128.114]> from "Fred Baker" >at Oct 6, 95 09:00:25 am > X-Mailer: ELM [version 2.4 PL24] > Mime-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Content-Length: 872 > Status: RO > > My apologies if I am mistaken, but I thought several people on this list > have offered to do ports of the code to Windows provided they can get the > source... If there are any people out there who are dying to "do ports of the code to Windows provided they can get the source.." please respond to me directly (aiken@es.net) with your request. thanks bob > > Michael > > > > At 10:21 AM 10/6/95, Michael Benson wrote: > > >My guess is that they don't want this done so as to not flood the > > >mbone with Window's users bandwidth. > > > > My guess is that it's not the bandwidth they'd worry about. If you want > > Win95 versions of these, I'd suggest that you convince Van and company to > > spin off a Windows development shop and fund their research with it. > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > "I know they'll sell it to me, I saw it at InterOp" > > > > > > > -- > Michael Benson > Computer science graduate student at George Mason University > WWW: http://cne.gmu.edu/~mbenson > Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson > Robert J. Aiken, Department of Energy/ Lawrence Livermore Lab ER-31, 19901 Germantown Rd., Germantown, MD. 20874-1290 301-903-5800, 301-903-7774 (fax), aiken@es.net "Always drink upstream from the herd" From list-mgr@ISI.EDU Fri Oct 6 04:51:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29459>; Fri, 6 Oct 1995 11:54:09 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29412>; Fri, 6 Oct 1995 11:52:45 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA29402>; Fri, 6 Oct 1995 11:52:42 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16425(1)>; Fri, 6 Oct 1995 11:51:58 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Fri, 6 Oct 1995 11:51:34 -0700 To: bmiller@ito.snap.org Cc: Markku Savela <msa@hemuli.tte.vtt.fi>, mbone Subject: Re: Whta is going on MBONE? In-Reply-To: Your message of "Fri, 06 Oct 95 07:09:23 PDT." <951006100923.1122AABmI.bmiller@next146> Date: Fri, 6 Oct 1995 11:51:34 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct6.115134pdt.177475@crevenia.parc.xerox.com> In message <951006100923.1122AABmI.bmiller@next146> you write: >Same thing here. I had to kill mrouted on noc.hpc.org - it kept >killing my machine; 'mbuf map full' is it's last dying gasp. Just as a note, this kind of problem will continue to kill any 2.x multicast routers, since they keep the full routing table in the kernel; it will just slow down 3.x routers since they keep it in user space (ain't virtual memory great?) Bill From list-mgr@ISI.EDU Fri Oct 6 04:48:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29208>; Fri, 6 Oct 1995 11:50:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29192>; Fri, 6 Oct 1995 11:49:28 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA29185>; Fri, 6 Oct 1995 11:49:26 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16381(6)>; Fri, 6 Oct 1995 11:49:14 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Fri, 6 Oct 1995 11:49:00 -0700 To: "david a. schlussel" <dschluss@engin.umich.edu> Cc: CU-SEEME <CU-SEEME-L@cornell.edu>, MBone <mbone> Subject: Re: mrouted explosion (fwd) In-Reply-To: Your message of "Fri, 06 Oct 95 08:17:54 PDT." <Pine.SUN.3.91.951006111723.28507M-100000@chips.engin.umich.edu> Date: Fri, 6 Oct 1995 11:48:58 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct6.114900pdt.177475@crevenia.parc.xerox.com> In message <Pine.SUN.3.91.951006111723.28507M-100000@chips.engin.umich.edu> you write: >I'm guessing this has something to do with cu-seemers Only if a cu-seeme'r turned on a misconfigured Cisco, or found some other creative way to inject unicast routing tables into the MBONE. I wasn't awake during the problem, but my routing table size monitor sure was: 951006-0301 2785 951006-0400 2792 951006-0500 26725 951006-0600 26139 951006-0700 26042 951006-0800 26319 951006-0900 2335 So, somewhere between 0400 and 0500 PDT was the start, and it ended between 0800 and 0900. Bill From list-mgr@ISI.EDU Fri Oct 6 10:57:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29950>; Fri, 6 Oct 1995 12:03:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29873>; Fri, 6 Oct 1995 12:02:01 -0700 Received: from radicalmedia.com by venera.isi.edu (5.65c/5.61+local-22) id <AA29865>; Fri, 6 Oct 1995 12:01:59 -0700 Received: (from phiber@localhost) by radicalmedia.com (8.6.12/8.6.12) id OAA10275 for mbone@isi.edu; Fri, 6 Oct 1995 14:57:25 -0400 From: Mark Abene <phiber@radicalmedia.com> Message-Id: <199510061857.OAA10275@radicalmedia.com> Subject: unicast crap... To: mbone Date: Fri, 6 Oct 1995 14:57:25 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 342 We, too, have many unicast routes in our multicast routing table as of today. Though our server is unlikely to have even flinched, so I didn't notice until I saw all the complaints on this list. I checked out the first few, a couple were originating from the Navy, the next couple from sura.net directly. -Mark Abene Radical Media, Inc. From list-mgr@ISI.EDU Fri Oct 6 07:32:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06796>; Fri, 6 Oct 1995 14:40:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06437>; Fri, 6 Oct 1995 14:32:28 -0700 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA06429>; Fri, 6 Oct 1995 14:32:26 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA19757 (5.65c/IDA-1.4.4nsd for <mbone@isi.edu>); Fri, 6 Oct 1995 14:32:25 -0700 Received: by jaspar.NSD.3Com.COM id AA20479 (5.65c/IDA-1.4.4-910730 for mbone@isi.edu); Fri, 6 Oct 1995 14:32:24 -0700 From: "Cyndi M. Jung" <cmj@NSD.3Com.COM> Message-Id: <199510062132.AA20479@jaspar.NSD.3Com.COM> Subject: European Educational Forum at GMD Fokus To: mbone Date: Fri, 6 Oct 1995 14:32:23 -0700 (PDT) Cc: Olaf_Reibe@3mail.3com.com X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 352 mboners, Thank you for the interest in my presentation. The 3Com Forum has been cancelled, but I will be at the GMD Fokus in Berlin the morning of Thursday, October 12, to give the presentation I had prepared. Anyone interested are welcome. For more information on GMD Fokus, http://www.fokus.gmd.de I hope to see some of you there, Cyndi Jung From list-mgr@ISI.EDU Fri Oct 6 07:56:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07647>; Fri, 6 Oct 1995 14:55:54 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA07640>; Fri, 6 Oct 1995 14:55:53 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id OAA16605; Fri, 6 Oct 1995 14:56:33 -0700 Message-Id: <199510062156.OAA16605@rx7.ee.lbl.gov> To: roscoe@b50-indy.bu.edu Cc: mbone-na Subject: roscoe@b50-indy.bu.edu sending 400kb/s of nv video Date: Fri, 06 Oct 95 14:56:31 PDT From: Van Jacobson <van@ee.lbl.gov> You may not be aware that the nv video that you are currently sending to the "BU MARINER" session is going to over 20,000 machines all over the world. Your nv stream was using up to 400kb/s of bandwidth. The total bandwidth available to the MBone is only 500kb/s so you were using 80% of it. The MBone is a global resource and there are always several events trying to use it; for example, the Ig Nobel prize ceremonies this evening. One session using large amounts of the shared bandwidth causes packet losses for everyone. The mbone usage guidelines say that no session should send more than 128kb/s of video & much less if possible. Please be careful with the nv bandwidth sliders. Thanks. - Van Jacobson From list-mgr@ISI.EDU Fri Oct 6 07:59:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07853>; Fri, 6 Oct 1995 15:01:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07808>; Fri, 6 Oct 1995 15:00:58 -0700 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA07793>; Fri, 6 Oct 1995 15:00:52 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA21510 (5.65c/IDA-1.4.4nsd for <mbone@isi.edu>); Fri, 6 Oct 1995 15:00:29 -0700 Received: by jaspar.NSD.3Com.COM id AA20565 (5.65c/IDA-1.4.4-910730); Fri, 6 Oct 1995 14:59:23 -0700 From: "Cyndi M. Jung" <cmj@NSD.3Com.COM> Message-Id: <199510062159.AA20565@jaspar.NSD.3Com.COM> Subject: Re: unicast crap... To: phiber@radicalmedia.com (Mark Abene) Date: Fri, 6 Oct 1995 14:59:22 -0700 (PDT) Cc: mbone In-Reply-To: <199510061857.OAA10275@radicalmedia.com> from "Mark Abene" at Oct 6, 95 02:57:25 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 543 Well, our new DVMRP implementation survived the thrashing. The last meltdown gave it significant pain, but it has gotten more robust since then. Cyndi Jung 3Com Corporation > > > We, too, have many unicast routes in our multicast routing table as of today. > Though our server is unlikely to have even flinched, so I didn't notice until > I saw all the complaints on this list. I checked out the first few, a couple > were originating from the Navy, the next couple from sura.net directly. > > -Mark Abene > Radical Media, Inc. > > From list-mgr@ISI.EDU Fri Oct 6 20:58:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12664>; Fri, 6 Oct 1995 17:01:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12596>; Fri, 6 Oct 1995 16:59:16 -0700 Received: from alpha.coe.ufrj.br by venera.isi.edu (5.65c/5.61+local-22) id <AA12589>; Fri, 6 Oct 1995 16:59:11 -0700 Received: (from rodolfo@localhost) by alpha.coe.ufrj.br (8.6.12/8.6.10) id UAA21416; Fri, 6 Oct 1995 20:58:36 -0300 From: Rodolfo Heitor Gevaerd de Faria <rodolfo@coe.ufrj.br> Message-Id: <199510062358.UAA21416@alpha.coe.ufrj.br> Subject: Re: VAT/VIC/NV/WB/SD for OS/2 (Was Windows 95) To: J.Crowcroft@cs.ucl.ac.uk Date: Fri, 6 Oct 95 20:58:35 GMT-3:00 Cc: mbone X-Mailer: ELM [version 2.3 PL2] > the mbone tools are all releatively simple in terms of their API > requirements > > GUI and Video output: > most require tcl/tk, some require raw X a couple need both > Windows and MAC equivalents are either trivial, or easy... > > Network: > they require multicast sockets > winsock (e.g. FTP s/ws or trumpet or the latest microsoft) all do this > very very close to the yway bsd ("deering") sockets work > > Video Input > ivs, nv and vic have an abstraction for the idea of a framegrabber > already - to retro fit the video for windows abstraction should be > relatively simple... > > Video Output - see above... > > Audio i/o this is either hte most tricky or the easiest depending > your point of view. > Most assume 8 bit PCM samples, though some just assume a read of x > bytes gives you at most x bytes, and that the application knows the > sample rate/size so may be able to use this as a clock too... > > Finally, the tricky bit: > Timers and Tasking > > Some use select based wait loops to schedule their i/o. while some use > the read completion on a synchronous input sample (e.g. audio > above)...and yet others use real timer events (poor accuracy - e.g. > sigalrm but some versions of Un*x do have reasonable itimer > granularity...) > > Some use 1 task and mux/demux the multiple audio/video etc streams, > others spawn a child per input stream...... > > of course, they are all mono-media tools (except ivs) so if you don't > have some decent taskig (though cooperative multitasking like MACs or > Windows 3 may just be enough - in fact ,the lack of preemtpiton in > them may make some aspects of things easier!) > > Interstream Synchrionisation - as far as i know, we are the only people so > far t try synching audio/video are LBL and us....we do it in a way > that is compatibvle wih windows 3 tasking as far as i can tell....so > it should be straightforward > > i'm waiting for a C and C++ compiler and the net to get good enuff so > i can ftp the tcl/tk release for windows, and a book on how to get at > audio under windows 3.... > Just one question. Except for the multicast support (which I'm not sure if it has), OS/2 has all those features (including Tcl/Tk and GNU C/C++), why don't someone try do do a mbone suppot for OS/2 also ? > jon > p.s. you could of course just > also run solaris on you intel processor of course, or Where can I get the mbone utilities compiled for Intel/Solaris ? > linux if you are more anarchistically inclined... FreeBSD also has a good support for mbone in the Intel plataform. > > but for the great unwashed M*soft users, we feel we ought to enlgihten > their mbone access somehow... > I think the mbone access should have more ports for non-Unix OSes, especially in the Intel plataform. Anyone know what's being done in that direction ? Rodolfo H G Faria <rodolfo@coe.ufrj.br> From list-mgr@ISI.EDU Fri Oct 6 14:32:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20903>; Fri, 6 Oct 1995 22:01:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20892>; Fri, 6 Oct 1995 22:00:48 -0700 Received: from sun3.nsfnet-relay.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA20885>; Fri, 6 Oct 1995 22:00:42 -0700 Received: from hubby.liverpool-john-moores.ac.uk by sun3.nsfnet-relay.ac.uk with JANET SMTP id <sg.16468-0@sun3.nsfnet-relay.ac.uk>; Fri, 6 Oct 1995 15:24:40 +0100 Received: from VAXB (actually host vaxb.livjm.ac.uk) by hubby.livjm.ac.uk with SMTP (PP); Fri, 6 Oct 1995 14:25:46 +0100 Received: from vax.livjm.ac.uk by vax.livjm.ac.uk (PMDF V5.0-3 #10554) id <01HW4G8Q6B52A8QW5Z@vax.livjm.ac.uk> for mbone@ISI.EDU; Fri, 06 Oct 1995 14:32:11 +0000 (GMT) Date: Fri, 06 Oct 1995 14:32:11 +0000 (GMT) From: S.H.BENNETT@livjm.ac.uk Subject: The Hardware needed ! To: mbone Message-Id: <01HW4G8Q6UFSA8QW5Z@vax.livjm.ac.uk> X-Vms-To: IN%"mbone@ISI.EDU" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Hello I would like to introduce myself , I'm Simon Bennett from the John Moores University in Liverpool and as an Mbone mailing list newcomer ( I have been watching and reading for a while ) one aspect which interests me which doesn,t seem to be mentioned much above the neccesity level is such things as camera's , mike's , A/D converters for audio what lighting levels can be supported and what projection possibilities are posible etc . We are planning a free , public arts based Mbone multicast in St. Georges Hall , Liverpool September 1996 and over and above the not inconsiderable problems in setting up a multicast we are interested in the aesthetic / cultural aspects of this new medium . From a technical level there are problems in compressing the audio ( especially with ++++++ bass frequencies ) so as to alleviate surges / drops in the signal and also in projecting visuals through Barco's ( these will be outside the hall on to another building ) as these are not strictly compatible . If anyone has any ideas please do not hesitate in getting in touich with me , although September seems a long way away I'm sure it willl come around with quick speed . Speak to you soon , Simon Bennett . From list-mgr@ISI.EDU Sat Oct 7 14:11:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27672>; Sat, 7 Oct 1995 05:12:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27664>; Sat, 7 Oct 1995 05:11:58 -0700 Received: from gizmo.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA27657>; Sat, 7 Oct 1995 05:11:54 -0700 Received: from localhost (martin@localhost) by gizmo.lut.ac.uk (8.7.1/8.6.9) with SMTP id NAA28687 for <mbone@isi.edu>; Sat, 7 Oct 1995 13:11:47 +0100 (BST) Message-Id: <199510071211.NAA28687@gizmo.lut.ac.uk> X-Mailer: exmh version 1.6.2 7/18/95 To: mbone Subject: Re: mrouted explosion X-Uri: <URL:http://www.roads.lut.ac.uk/~martin> In-Reply-To: Your message of "Fri, 06 Oct 1995 15:32:00 BST." <Pine.SV4.3.91.951006153002.1907A-100000@scorpio.ucs.ed.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Oct 1995 13:11:45 +0100 From: Martin Hamilton <martin@mrrl.lut.ac.uk> Graeme Wood writes: | Somebody is injecting unicast routes into the multicast routing table. | My mrouted has over 25,000 entries at the moment and is using up | considerable amounts of CPU. At about the same time this was happening, syslog stopped working on one of our mrouters (FWIW: a multi-homed, dual processor Sun 690/MP, running SunOS 4.1.3_U1 + ipmulti 3.5 + snmp-mrouted 3.6.2). There's a suspicion that this was down to the volume of "ip_mrouter socket queue full" messages being generated by ip_mforward() Just wondering if anyone else lost their syslog daemon yesterday! Cheerio, Martin From list-mgr@ISI.EDU Sat Oct 7 09:01:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02891>; Sat, 7 Oct 1995 10:10:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02703>; Sat, 7 Oct 1995 10:03:29 -0700 Received: from lhc.nlm.nih.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA02696>; Sat, 7 Oct 1995 10:03:26 -0700 Received: from billings.nlm.nih.gov by lhc.nlm.nih.gov (4.1/SMI-4.0) id AA05424; Sat, 7 Oct 95 13:03:13 EDT Received: by billings.nlm.nih.gov (5.x/SMI-SVR4) id AA18977; Sat, 7 Oct 1995 13:01:47 -0400 Date: Sat, 7 Oct 1995 13:01:47 -0400 From: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Message-Id: <9510071701.AA18977@billings.nlm.nih.gov> To: mbone, S.H.BENNETT@livjm.ac.uk Subject: Re: The Hardware needed ! X-Sun-Charset: US-ASCII Simon, We have tried to address the setup and social aspects of multicasting in our series of reports about multicasting from the Int. WWW Conferences. The report from the Oct. '94 Chicago meeting is at: http://www.nlm.nih.gov/reports.dir/multicasting.dir/report.html and we are putting the finishing touches on the report from the Darmstadt meeting of April '95. Good luck with your own multicasting efforts! Cheerio, Rick Rodgers > From list-mgr@ISI.EDU Sat Oct 7 01:07 EDT 1995 > Date: Fri, 06 Oct 1995 14:32:11 +0000 (GMT) > From: S.H.BENNETT@livjm.ac.uk > Subject: The Hardware needed ! > To: mbone@ISI.EDU > X-Vms-To: IN%"mbone@ISI.EDU" > Mime-Version: 1.0 > Content-Transfer-Encoding: 7BIT > Content-Type: TEXT/PLAIN; CHARSET="US-ASCII" > Content-Length: 1247 > > Hello I would like to introduce myself , I'm Simon Bennett > from the John Moores University in Liverpool and as an Mbone > mailing list newcomer ( I have been watching and reading for > a while ) one aspect which interests me which doesn,t seem > to be mentioned much above the neccesity level is such > things as camera's , mike's , A/D converters for audio what > lighting levels can be supported and what projection > possibilities are posible etc . > > We are planning a free , public arts based Mbone multicast > in St. Georges Hall , Liverpool September 1996 and over and > above the not inconsiderable problems in setting up a > multicast we are interested in the aesthetic / cultural > aspects of this new medium . > > From a technical level there are problems in compressing the > audio ( especially with ++++++ bass frequencies ) so as to > alleviate surges / drops in the signal and also in > projecting visuals through Barco's ( these will be outside > the hall on to another building ) as these are not strictly > compatible . > > If anyone has any ideas please do not hesitate in getting in > touich with me , although September seems a long way away > I'm sure it willl come around with quick speed . > > Speak to you soon , > Simon Bennett . From list-mgr@ISI.EDU Sat Oct 7 14:56:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11030>; Sat, 7 Oct 1995 16:01:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11023>; Sat, 7 Oct 1995 16:01:01 -0700 Received: from radicalmedia.com by venera.isi.edu (5.65c/5.61+local-22) id <AA11016>; Sat, 7 Oct 1995 16:00:58 -0700 Received: (from phiber@localhost) by radicalmedia.com (8.6.12/8.6.12) id SAA21935; Sat, 7 Oct 1995 18:56:25 -0400 From: Mark Abene <phiber@radicalmedia.com> Message-Id: <199510072256.SAA21935@radicalmedia.com> Subject: Re: mrouted explosion To: martin@mrrl.lut.ac.uk (Martin Hamilton) Date: Sat, 7 Oct 1995 18:56:24 -0400 (EDT) Cc: mbone In-Reply-To: <199510071211.NAA28687@gizmo.lut.ac.uk> from "Martin Hamilton" at Oct 7, 95 01:11:45 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 930 > > > Graeme Wood writes: > > | Somebody is injecting unicast routes into the multicast routing table. > | My mrouted has over 25,000 entries at the moment and is using up > | considerable amounts of CPU. > > At about the same time this was happening, syslog stopped working on > one of our mrouters (FWIW: a multi-homed, dual processor Sun 690/MP, > running SunOS 4.1.3_U1 + ipmulti 3.5 + snmp-mrouted 3.6.2). There's > a suspicion that this was down to the volume of "ip_mrouter socket > queue full" messages being generated by ip_mforward() > > Just wondering if anyone else lost their syslog daemon yesterday! > > Cheerio, > > Martin > > > As I told someone else on the list, we have a Solaris x86 2.4 MP server (two Pentiums), and our machine didn't even flinch. Nothing crashed, nothing bombed, nothing disrupted. We're using mrouted 2.2, which I ported to Solaris x86. -Mark Abene Radical Media, Inc. From list-mgr@ISI.EDU Wed Oct 7 19:03:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17924>; Sat, 7 Oct 1995 22:03:15 -0700 Received: from realtime.cc.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA17917>; Sat, 7 Oct 1995 22:03:12 -0700 Received: (from ccshag@localhost) by realtime.cc.missouri.edu (8.6.12/8.6.12) id AAA00754; Sun, 8 Oct 1995 00:03:10 -0500 Date: Sun, 8 Oct 1995 00:03:10 -0500 (CDT) From: "Paul 'Shag' Walmsley" <ccshag@cclabs.missouri.edu> X-Sender: ccshag@realtime.cc.missouri.edu To: mbone-na Subject: Sprintlink's dc-mbone-1.sprintlink.net is down Message-Id: <Pine.SGI.3.91.951007235206.726B-100000@realtime.cc.missouri.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII dc-mbone-1.sprintlink.net (144.228.1.40), one of Sprintlink's major MBONE hubs (it's the one with 20 or 30 tunnels defined), is currently down and has been so since Friday. It appears to be a casualty of Friday's route spewage, considering that it was apparently running a 2.x mrouted. *.missouri.edu's link to the MBONE was through dc-mbone-1. I spoke to someone at the Sprintlink INSC, and he didn't expect the tunnel to be back up before Monday. He stated that it could be as late as Wednesday until someone got around to fixing it (which presumably means "rebooting it," considering that it's not even pingable). As a result, unless some kind multicast router administrator offers us an alternate tunnel into the MBONE, the proposed "Distance Learning ..." and "Technology and the University Classroom" seminars slated for multicast on Monday will not reach the global MBONE. We'll try to record it for rebroadcast later, but if someone out there in Sprintlinkland has another path to the MBONE - say, via dc-mbone-2, or via a different ISP - and is willing to configure a temporary tunnel to us by 8:15AM CDT Monday morning, please send me E-mail. Thanks in advance. - Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu> "Praise and blame alike mean nothing." -- Virginia Woolf From list-mgr@ISI.EDU Wed Oct 7 17:16:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20306>; Sun, 8 Oct 1995 00:18:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20299>; Sun, 8 Oct 1995 00:16:36 -0700 Received: from cher.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA20292>; Sun, 8 Oct 1995 00:16:35 -0700 Received: by cher.stanford.edu (5.65/25-eef) id AA24052; Sun, 8 Oct 1995 00:16:30 -0700 From: agrawals@cher.stanford.edu (Sanjay Kumar Agrawal) Message-Id: <9510080716.AA24052@cher.stanford.edu> Subject: How to use JVdriver in Mbone application To: mbone Date: Sun, 8 Oct 1995 00:16:29 -0700 (PDT) Cc: agrawals@cher.stanford.edu (Sanjay Kumar Agrawal), berc@src.dec.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1537 Hi, I am a Ph.D student Stanford University under Dr. Kazovsky's group. We have designed and implemented network called "STARNET". It is a packet switched optical network operating at 1.25 Gbps. We have developed an STARNET network card which interfaces with DEC 5000 workstation running ultrix 4.2 (also ultrix 4.4 on a seperate partition). I am trying to use MBone to transmit Video data accross two DEC 5000 workstations using STARNET interface instead of conventional TCP/IP or UDP/IP interface. I have obtained JVideo cards for DEC 5000 workstation. Jvideo cards are much faster than standard video card for DEC 5000 workstation. I have compiled and installed mbone software (nvsrc-3.3beta) on my system and it works with standard video cards. As I understand, this should also work with Jvideo cards. I am looking for information on how can that be done. Do I need to set some flag in the makefile to compile it for jvdriver? Do I need to modify the source code to use JVdriver instead of J300? Do I have the right source code? Also, I am wondering if there are newer versions source codes available, which are more applicable for my purpose. Has anybody tried to use Mbone for non IP interface before? If yes, where were the modifications made?? I would appreciate it very much if someone can help me with my questions or point me in the right direction. Thanks for your time and consideration, -Sanjay K. Agrawal email: agrawals@cher.stanford.edu Web address: http://www-leland.stanford.edu/~agrawals From list-mgr@ISI.EDU Sun Oct 8 15:22:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25883>; Sun, 8 Oct 1995 06:23:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25870>; Sun, 8 Oct 1995 06:22:43 -0700 Received: from cismsun.univ-lyon1.fr by venera.isi.edu (5.65c/5.61+local-22) id <AA25863>; Sun, 8 Oct 1995 06:22:40 -0700 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id OAA24771; Sun, 8 Oct 1995 14:22:37 +0100 Message-Id: <199510081322.OAA24771@cismsun.univ-lyon1.fr> Subject: Re: VIC problems To: rr@eel.ufl.edu (Mahesh Ramachandran) Date: Sun, 8 Oct 1995 14:22:36 +0100 (MET) From: "Lucia Gradinariu" <lucia@univ-lyon1.fr> Cc: mbone In-Reply-To: <199510061218.AA142761905@sioux.eel.ufl.edu> from "Mahesh Ramachandran" at Oct 6, 95 08:16:34 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1166 > > Meng-Day Yu wrote: > |> > |> When I click the transmit button in VICv2.6, I receive > |> the following error message: > |> > [...] > |> I am running VIC on a SUNSparc5 running Solaris 2.4. I am using a > |> SUNVideo card. Does anyone have any ideas? > |> > > The error is caused because you dont have permission to access the > devices SUNW,rtvc@1,0:rtvc0 and SUNW,rtvc@1,0:rtvcctl0 in > /devices/iommu@0,10000000/sbus@0,10001000. > So go in there and change the permission on them such that you can r/w > to them. > > However, at every reboot the permissions on those devices would get > reset. I'm yet to figure out from where Solaris is doing that. > Or else just run as root ... things should work fine. > > -rr > > -- > r/w permissions on rtvc devices are set for who's running OW at that moment on the console because it is obvious that the guy who wants to play with SunVideo will do this from the console (and he will be the only one who plays with). I think it's better to restart OW on your account than to change r/w permissions on rtvc devices and then to forget to tell this to the previous user :-) Lucia.Gradinariu@univ-lyon1.fr From list-mgr@ISI.EDU Sun Oct 8 15:08:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16259>; Sun, 8 Oct 1995 22:14:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16130>; Sun, 8 Oct 1995 22:08:11 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA16123>; Sun, 8 Oct 1995 22:08:09 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id WAA02184 for <mbone@ISI.EDU>; Sun, 8 Oct 1995 22:08:04 -0700 Message-Id: <199510090508.WAA02184@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: mbone Subject: mbone feed for v-site.net ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Oct 1995 22:08:03 -0700 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Howdy, I am wondering if anyone can provide us with an MBONE feed close to us? Not sure what is the story with TLGnet but we have been waiting for an MBONE feed from them for about 3 months. My setup is FreeBSD with mrouted 3.6 Thank in advance, Amancio From list-mgr@ISI.EDU Mon Oct 9 10:42:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20746>; Mon, 9 Oct 1995 01:44:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20735>; Mon, 9 Oct 1995 01:43:10 -0700 Received: from baird.cs.strath.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA20728>; Mon, 9 Oct 1995 01:43:02 -0700 Received: from mac-12.cs.strath.ac.uk by baird.cs.strath.ac.uk id aa16479; 9 Oct 95 9:42 +1000 X-Sender: jf@u6pophost.cs.strath.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Oct 1995 09:42:46 +0100 To: mbone From: John Ferguson <jf@cs.strath.ac.uk> Subject: unsubscribe Message-Id: <9510090942.aa16479@baird.cs.strath.ac.uk> unsubscribe From list-mgr@ISI.EDU Mon Oct 9 12:13:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22028>; Mon, 9 Oct 1995 03:17:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22000>; Mon, 9 Oct 1995 03:13:45 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-22) id <AA21989>; Mon, 9 Oct 1995 03:13:27 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id LAA27656 (8.6.12/7.4g-FAU); for <mbone@isi.edu>; Mon, 9 Oct 1995 11:11:03 +0100 From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de> Message-Id: <199510091011.LAA27656@faui40.informatik.uni-erlangen.de> Subject: multicast rwall To: mbone Date: Mon, 9 Oct 1995 11:13:16 +0100 (MET) Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 377 Hi Is there an implementation of rwall out there that uses multicasting ? Thanks -- Toerless Eckert Universitaet Erlangen Nuernberg Lehrstuhl fuer Betriebsysteme Martensstrasse 1 D-91058 Erlangen, Germany Tel.: +49 9131 85 7278 FAX: +49 9131 85 8732 / +49 9131 39388 Toerless.Eckert@Informatik.Uni-Erlangen.DE /C=De/A=D400/P=Uni-Erlangen/OU=Informatik/S=Eckert/G=Toerless/ From list-mgr@ISI.EDU Mon Oct 9 03:10:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02885>; Mon, 9 Oct 1995 10:15:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02623>; Mon, 9 Oct 1995 10:10:36 -0700 Received: from hp.com by venera.isi.edu (5.65c/5.61+local-22) id <AA02614>; Mon, 9 Oct 1995 10:10:34 -0700 Received: from hpindlm.cup.hp.com by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA085328632; Mon, 9 Oct 1995 10:10:32 -0700 Received: by hpindlm.cup.hp.com (1.38.193.5/15.5+IOS 3.20+cup+OMrelay) id AA23338; Mon, 9 Oct 1995 10:10:11 -0700 From: Ming Ming Chen <mchen@hpindlm.cup.hp.com> Message-Id: <9510091710.AA23338@hpindlm.cup.hp.com> Subject: Re: Kernel Assert mods (again) To: fenner@parc.xerox.com Date: Mon, 9 Oct 95 10:10:11 PDT Cc: pusateri@netedge.com, clemenj@hpindlm.cup.hp.com, doug_cohol@hpindlm.cup.hp.com, mbone, jgc@hpindlm.cup.hp.com Mailer: Elm [revision: 70.85.2.1] Hi Bill, Since I didn't hear from you, so I try again. Thanks for replying my mail. We looked at the solution 1 and solution 2 and found that both have new for loop code. solution 1 loops through "ifp->if_addrlist" which requires changes in both ip_mroute.h and ip_mroute.c, solution 2 loops the "viftable". So which for loop? Thanks Ming > > Ming, > > Very sorry for not replying; often if I don't reply to things right away > because I have to think about them, they get completely buried in my inbox. > We have decided that the for loop is O.K. in the upcall case, both for the > NOCACHE and the WRONGVIF message, and that will be what is in our next release. |Ming Ming Chen Hewlett Packard | |Information Network Division 19410 Homestead Road | |mchen@hpindlm.cup.hp.com Cupertino, CA 95014 | |408-447-2357 Mail Stop: 43LM | |_____________________________________________________________________________| From list-mgr@ISI.EDU Mon Oct 9 13:03:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28381>; Mon, 9 Oct 1995 20:12:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28356>; Mon, 9 Oct 1995 20:10:45 -0700 Received: from hawk.csusm.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA28349>; Mon, 9 Oct 1995 20:10:44 -0700 Received: by hawk.csusm.edu (AIX 4.1/UCB 5.64/4.03) id AA14026; Mon, 9 Oct 1995 20:03:45 -0700 Date: Mon, 9 Oct 1995 20:03:45 -0700 (PDT) From: Mark Chorak <chorak1@coyote.csusm.edu> X-Sender: chorak1@hawk.csusm.edu To: mbone Subject: mbone feed to quark.csusm.edu?? In-Reply-To: <199510090508.WAA02184@rah.star-gate.com> Message-Id: <Pine.A32.3.91.951009195817.21942B-100000@hawk.csusm.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thank you for those who responded to our early requests for a mbone feed at Calif. State Univ. San Marcos. 30 minutes north of San Diego CA. However we need a feed ASAP. We would appreciate any advise or someone to contact for a feed at our location. Mark From list-mgr@ISI.EDU Tue Oct 10 05:51:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11365>; Tue, 10 Oct 1995 06:54:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11325>; Tue, 10 Oct 1995 06:51:59 -0700 Received: from mailer.jhuapl.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA11318>; Tue, 10 Oct 1995 06:51:57 -0700 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA24292; Tue, 10 Oct 1995 09:51:54 -0400 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA20678; Tue, 10 Oct 1995 09:51:48 -0400 Date: Tue, 10 Oct 1995 09:51:47 -0400 (EDT) From: Jim Bogard BIX <jimbo@aplcomm.jhuapl.edu> To: mbone <mbone> Subject: Peculiar problem Message-Id: <Pine.SOL.3.91.951010094138.19442D-100000@aplcomm.jhuapl.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1219 I've had mrouted running on several machines for several months now, and have been using the mbone happily with no problems. About 3 weeks ago, it stopped working. Analysis reveals: 1. Our master mrouter (Sparc 2, 4.1.4, mrouted 3.6) is functioning happily. 2. Tunnel traffic out of that unit appears to be going where it should properly; at least as far as I can tell from sniffing around the tunnel endpoints. The odd thing is that no Solaris mrouted (2.3, mrouted 2.2) will hear sd traffic anymore. If I start mrouted on an irix box (5.3, _distribution_ mrouted 2.2, of all things), on the same ethernet segment, everything works fine. This has been duplicated with 2 Solaris boxes on the aforementioned segment, and one on another segment. Unfortunately, I don't have an irix box on the other segment, but I suspect the results would be the same. Is there some wierd version incompatibility going on here, perhaps caused by someone upgrading to 3.6 upstream? I'm confused! Thanks, and I appreciate your thoughts on this matter. J-. ---- Jim Bogard JHU/APL BIX Group "This is my banjo. There are many Backbone Network Engineer like it, but this one is mine." From list-mgr@ISI.EDU Tue Oct 10 08:09:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11693>; Tue, 10 Oct 1995 07:12:49 -0700 Received: from cythera.unb.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA11684>; Tue, 10 Oct 1995 07:12:46 -0700 Received: from cythera.unb.ca (cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.6.12/8.6.5) with SMTP id LAA09466; Tue, 10 Oct 1995 11:09:02 -0300 Date: Tue, 10 Oct 1995 11:09:02 -0300 (ADT) From: "Dwight E. Spencer" <spencer@unb.ca> To: mbone-na Cc: r.cogger@cornell.edu, CU-SEEME-L@cornell.edu Subject: cusm reflector, nv and vat Message-Id: <Pine.SOL.3.91.951010103827.649P-100000@cythera.unb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've successfully gotten nv working with cusm encoding, and a cusm reflector (on irc.unb.ca). However, vat's audio is not coming through to the cusm clients, and vice versa. cusm clients use intel DVI for their audio by default, and support ulaw, linear and a (new) "alpha"-mod vat sends in pcm by default, and I've switched it to all three dvi versions supported, and still audio does not come through i edited my sd entry to include idvi as the audio format. Still no audio going between vat and cusm however. The cusm clients (1 client out of 2, and the cu-reflector) do appear, to an extent, in vat's userlist. 80: NV-MC-PORT 50751 82: NV-MC-IN 224.2.215.173 86: NV-MC-OUT 63 224.2.215.173 97: VAT-MC-PORT 48294 98: VAT-MC-IN 224.2.248.19 103: VAT-MC-OUT 63 224.2.248.19 110: VAT-CONF-ID 4959 cusm://irc.unb.ca/ (131.202.3.6) any suggestions? dwight s. ---------------------------------------------------------------------------- Dwight E. Spencer Community Access Program eMail: spencer@unb.ca "C-Net" Server Administrator Phone: +1 506 453 4614 UNB, Fredericton, NB, Canada Url: http://cnet.unb.ca/cspace/staff/dspencer/ From list-mgr@ISI.EDU Tue Oct 10 00:23:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11922>; Tue, 10 Oct 1995 07:23:56 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11900>; Tue, 10 Oct 1995 07:23:05 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA11893>; Tue, 10 Oct 1995 07:23:04 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id HAA19553; Tue, 10 Oct 1995 07:23:47 -0700 Message-Id: <199510101423.HAA19553@rx7.ee.lbl.gov> To: mbone Subject: some cisco melting down the mbone again Date: Tue, 10 Oct 95 07:23:47 PDT From: Van Jacobson <van@ee.lbl.gov> It looks like some poor soul misconfigured a cisco PIM router again and is injecting all the world's unicast routes into mbone routing. We currently have 30,000 multicast routes and mrouted's are crashing and syslogs are filling up all over our site. I imagine the rest of the world is much the same. This happened just last Friday and seems to be happening every few days. Has cisco just fielded a new test release that makes it even easier to make this configuration mistake? Has anyone been able to track down the culprit(s)? The routers are too overloaded to respond to mtrace so I haven't had much luck. - Van From list-mgr@ISI.EDU Tue Oct 10 16:43:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12566>; Tue, 10 Oct 1995 07:46:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12536>; Tue, 10 Oct 1995 07:45:21 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA12470>; Tue, 10 Oct 1995 07:43:47 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id PAA11789; Tue, 10 Oct 1995 15:43:20 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id PAA11350; Tue, 10 Oct 1995 15:43:13 +0100 Date: Tue, 10 Oct 1995 15:43:12 +0100 (BST) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Van Jacobson <van@ee.lbl.gov> Cc: mbone Subject: Re: some cisco melting down the mbone again In-Reply-To: <199510101423.HAA19553@rx7.ee.lbl.gov> Message-Id: <Pine.SV4.3.91.951010154107.10619W-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Oct 1995, Van Jacobson wrote: > It looks like some poor soul misconfigured a cisco PIM router > again and is injecting all the world's unicast routes into mbone > routing. We currently have 30,000 multicast routes and > mrouted's are crashing and syslogs are filling up all over our > site. I imagine the rest of the world is much the same. This > happened just last Friday and seems to be happening every few > days. Has cisco just fielded a new test release that makes it > even easier to make this configuration mistake? Has anyone been > able to track down the culprit(s)? The routers are too > overloaded to respond to mtrace so I haven't had much luck. I must admit I did not notice it this time but currently (about 20 minutes after you sent your message) I am only seeing 2204 entries in the routing table. So either the episode was short-lived or it did not extend to here (how would this happen?). ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Tue Oct 10 01:18:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14126>; Tue, 10 Oct 1995 08:19:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14099>; Tue, 10 Oct 1995 08:18:53 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA14090>; Tue, 10 Oct 1995 08:18:52 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15794(3)>; Tue, 10 Oct 1995 08:18:36 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Tue, 10 Oct 1995 08:18:28 -0700 To: Van Jacobson <van@ee.lbl.gov> Cc: mbone Subject: Re: some cisco melting down the mbone again In-Reply-To: Your message of "Tue, 10 Oct 95 07:23:47 PDT." <199510101423.HAA19553@rx7.ee.lbl.gov> Date: Tue, 10 Oct 1995 08:18:16 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct10.081828pdt.177475@crevenia.parc.xerox.com> In message <199510101423.HAA19553@rx7.ee.lbl.gov> you write: >The routers are too >overloaded to respond to mtrace so I haven't had much luck. My new 'auto-mtrace-to-all-new-routes' script actually had a little bit of luck: + 206.84.220/24 / 12 Mtrace from 206.84.220.0 to 13.1.100.239 via group 224.2.0.1 Querying full reverse path... * switching to hop-by-hop: 0 tibia-131 (13.1.100.239) -1 tibia-131 (13.1.100.239) DVMRP thresh^ 1 284 ms -2 snaildarter (204.162.228.1) DVMRP thresh^ 16 40 ms -3 ames.dart.net (140.173.144.1) DVMRP thresh^ 1 254 ms -4 mbone2.nsi.nasa.gov (192.203.230.242) DVMRP thresh^ 64 868 ms -5 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 1 1059 ms -6 mbone.sdsc.edu (198.17.47.39) DVMRP thresh^ 64 15 s -7 VINEGAR.SESQUI.NET (128.241.0.91) DVMRP thresh^ 64 323 ms -8 mae-bone.psi.net (192.41.177.247) DVMRP thresh^ 64 -60 s -9 * fmroute1-1.exp.edf.fr (192.70.92.133) DVMRP thresh^ 64 -135 s -10 * * r-jusren.reseau.jussieu.fr (192.44.54.126) doesn't support mtrace Round trip time 2380 ms The metric of the added routes appears to be 12, so the injecting router is probably a hop or two beyond r-jusren.reseau.jussieu.fr . Bill From list-mgr@ISI.EDU Tue Oct 10 19:18:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14138>; Tue, 10 Oct 1995 08:19:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14087>; Tue, 10 Oct 1995 08:18:51 -0700 Received: from cc.lut.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA14079>; Tue, 10 Oct 1995 08:18:49 -0700 Received: (from ruokonen@localhost) by cc.lut.fi (8.6.12/8.6.6/1.17.kim) id RAA01520; Tue, 10 Oct 1995 17:18:40 +0200 From: Vesa Ruokonen <Vesa.Ruokonen@lut.fi> Message-Id: <199510101518.RAA01520@cc.lut.fi> Subject: Re: some cisco melting down the mbone again To: van@ee.lbl.gov (Van Jacobson) Date: Tue, 10 Oct 1995 17:18:40 +0200 (EET) Cc: mbone In-Reply-To: <199510101423.HAA19553@rx7.ee.lbl.gov> from "Van Jacobson" at Oct 10, 95 07:23:47 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1190 > It looks like some poor soul misconfigured a cisco PIM router > again and is injecting all the world's unicast routes into mbone Maybe related maybe not; I can see following nets in my mrouted: sauron:/usr/tmp> grep "^ 10\." mrouted.dump 10.0.36 157.24.23.48 15 0 1* sauron:/usr/tmp> grep "^ 172\." mrouted.dump 172.21 157.24.23.48 14 0 1* 172.31 157.24.23.48 24 0 1* sauron:/usr/tmp> grep "^ 192.168\." mrouted.dump 192.168.6 157.24.23.48 18 0 1* 192.168.8 157.24.23.48 18 0 1* 192.168.22 157.24.23.48 NR 0 1* 192.168.25 157.24.23.48 20 0 1* ... Those nets should be reserved for private use as per RFC 1597. I suppose they should not show up in mrouteds either. Otherwise something weird happens when two private nets meet.. According to metric values I would guess those are injected to mbone in the other side of the net, and they are coming from multiple sources. > routing. We currently have 30,000 multicast routes and Around 24700 a moment ago here. -- <A HREF="http://www.lut.fi/~ruokonen/"> Vesa.Ruokonen@lut.fi </A> From list-mgr@ISI.EDU Tue Oct 10 01:19:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14187>; Tue, 10 Oct 1995 08:21:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14167>; Tue, 10 Oct 1995 08:20:30 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA14160>; Tue, 10 Oct 1995 08:20:29 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15696(2)>; Tue, 10 Oct 1995 08:20:08 PDT Received: by crevenia.parc.xerox.com id <177475>; Tue, 10 Oct 1995 08:19:44 -0700 From: Bill Fenner <fenner@parc.xerox.com> To: Graeme.Wood@ucs.ed.ac.uk, van@ee.lbl.gov Subject: Re: some cisco melting down the mbone again Cc: mbone Message-Id: <95Oct10.081944pdt.177475@crevenia.parc.xerox.com> Date: Tue, 10 Oct 1995 08:19:29 PDT It was extremely short-lived; 951010-0600 2589 951010-0700 26932 951010-0800 2240 Bill From list-mgr@ISI.EDU Tue Oct 10 08:18:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17044>; Tue, 10 Oct 1995 09:21:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16996>; Tue, 10 Oct 1995 09:19:05 -0700 Received: from odin.UU.NET by venera.isi.edu (5.65c/5.61+local-22) id <AA16987>; Tue, 10 Oct 1995 09:19:01 -0700 Received: by odin.UU.NET (maildrop) id QQzkwf16541; Tue, 10 Oct 1995 12:18:59 -0400 Date: Tue, 10 Oct 1995 12:18:59 -0400 Message-Id: <QQzkwf16541.199510101618@odin.UU.NET> From: Henry Kilmer <hank@uunet.uu.net> To: Jim Bogard BIX <jimbo@aplcomm.jhuapl.edu> Cc: mbone <mbone> Subject: Peculiar problem In-Reply-To: <Pine.SOL.3.91.951010094138.19442D-100000@aplcomm.jhuapl.edu> References: <Pine.SOL.3.91.951010094138.19442D-100000@aplcomm.jhuapl.edu> To add more data to this, we upgraded to mrouted 3.6 on Sept. 22. We have the upstream tunnel for jhuapl... -Hank Jim Bogard writes: > >I've had mrouted running on several machines for several months now, and >have been using the mbone happily with no problems. About 3 weeks ago, >it stopped working. Analysis reveals: > >1. Our master mrouter (Sparc 2, 4.1.4, mrouted 3.6) is functioning happily. >2. Tunnel traffic out of that unit appears to be going where it should >properly; at least as far as I can tell from sniffing around the tunnel >endpoints. > >The odd thing is that no Solaris mrouted (2.3, mrouted 2.2) will hear sd >traffic anymore. If I start mrouted on an irix box (5.3, _distribution_ >mrouted 2.2, of all things), on the same ethernet >segment, everything works fine. This has been duplicated with 2 Solaris >boxes on the aforementioned segment, and one on another segment. >Unfortunately, I don't have an irix box on the other segment, but I >suspect the results would be the same. > >Is there some wierd version incompatibility going on here, perhaps caused >by someone upgrading to 3.6 upstream? I'm confused! > >Thanks, and I appreciate your thoughts on this matter. > >J-. >---- >Jim Bogard JHU/APL BIX Group "This is my banjo. There are many >Backbone Network Engineer like it, but this one is mine." > > From list-mgr@ISI.EDU Tue Oct 10 03:57:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22229>; Tue, 10 Oct 1995 10:58:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22079>; Tue, 10 Oct 1995 10:57:20 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA22072>; Tue, 10 Oct 1995 10:57:19 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id KAA19812; Tue, 10 Oct 1995 10:57:16 -0700 Date: Tue, 10 Oct 1995 10:57:16 -0700 From: Dino Farinacci <dino@cisco.com> Message-Id: <199510101757.KAA19812@stilton.cisco.com> To: fenner@parc.xerox.com Cc: van@ee.lbl.gov, mbone In-Reply-To: Bill Fenner's message of Tue, 10 Oct 1995 08:18:16 PDT <95Oct10.081828pdt.177475@crevenia.parc.xerox.com> Subject: some cisco melting down the mbone again >> My new 'auto-mtrace-to-all-new-routes' script actually had a little bit of >> luck: I will be adding a patch to 10.2, 10.3 and 11.0 to monitor routing table sizes and complain as early as possbile when there is a surge. Dino From list-mgr@ISI.EDU Tue Oct 10 12:21:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23535>; Tue, 10 Oct 1995 11:24:57 -0700 Received: from cythera.unb.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA23528>; Tue, 10 Oct 1995 11:24:55 -0700 Received: from cythera.unb.ca (cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.6.12/8.6.5) with SMTP id PAA10553; Tue, 10 Oct 1995 15:21:14 -0300 Date: Tue, 10 Oct 1995 15:21:14 -0300 (ADT) From: "Dwight E. Spencer" <spencer@unb.ca> To: "Brian O'Shea" <boshea@wpine.com> Cc: CU-SEEME-L@cornell.edu, mbone-na, Steve Sloan <sloan@unb.ca> Subject: Re: cusm reflector, nv and vat In-Reply-To: <9510101533.AA17653@boggs.wpine.com.wpine.com> Message-Id: <Pine.SOL.3.91.951010150719.649R-100000@cythera.unb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Oct 1995, Brian O'Shea wrote: > Hmmmm. I would start by reverting to vat defaults and starting vat manually > to verify that it's working with a standard port, and no conference ID. > I used: > 238: VAT-MC-PORT 3456 > 239: VAT-MC-IN 224.2.248.19 > 240: VAT-MC-OUT 63 224.2.248.19 What version of the reflector are you running? .. I'm running version 4.00b2 > Start the reflector with the -broadcast switch so you only have to have 1 cusm > client connected. Whenever I give my reflect.mc a "-flag" option, is does not seem to read the config file, only reading the note about: "See README.reflector.4.00B2.txt for notices, permissions and restrictions" and stops. When I check with refmon, there are no clients connected. if I simply start reflect.mc, then it sees the nv stream immediately cythera:~$ refmon -s irc Waiting for connection to 131.202.3.6 ... Connected > who No Clients > quit cythera:~$ refmon -s irc Waiting for connection to 131.202.3.6 ... Connected > who NV MULTICAST: @131.202.70.96 ===== > SunOS 4.1.1 Host > reflect -broadcast I'm running reflector 4.00b2 on solaris 2.3. Should I try it on system running solaris 2.4? Also, where these two hosts on the same subnet? did tunnels and mrouted come into the picture here? perhaps I should explain my setup here a bit better. machine1(broadcasting mbone via local mrouted (131.202.70.96), to mrouted on machine2 (via tunnel to 131.202.3.18). my reflector is on a machine3 (131.202.3.6) which is picking up multicast packets off of the ethernet segment from ...3.18. the first two machines are running solaris 2.4 and mrouted's version 3.4 , and the last one, with the reflector, is running solaris 2.3. > MAC connect to SunOS 4.1.1 host and transmit audio in dvi format. > The vat host doesn't have a microphone, but does have speakers. The audio > transmitted from the client reached the sun's speakers. If I get a chance to try this, I'll be able to send audio in both directions. I'm testing with a mac pb 520c, and a sun sparc4 with sunvideo and audio kits installed. > + Brian O'Shea White Pine Software + > + Network/OS Software Engineer 15 Messenger Square + > + boshea@wpine.com Suite 8A + Our university is planning to do an mbone broadcast in two weeks (i'll post a formal "request" in the next couple days, 2 30-50 minute broadcasts), and making it available to the mbone community, as well as via cuseeme reflectors would give both worlds a chance to see it. Anyone else having a cusm reflector which would be able to mirror the mbone session back into a reflector are welcome to, assuming I can get my own audio/reflector combination working correctly. Comments welcome. dwight s. ---------------------------------------------------------------------------- Dwight E. Spencer Community Access Program eMail: spencer@unb.ca "C-Net" Server Administrator Phone: +1 506 453 4614 UNB, Fredericton, NB, Canada Url: http://cnet.unb.ca/cspace/staff/dspencer/ From list-mgr@ISI.EDU Tue Oct 10 12:40:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27291>; Tue, 10 Oct 1995 12:42:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27115>; Tue, 10 Oct 1995 12:40:11 -0700 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA27106>; Tue, 10 Oct 1995 12:40:09 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.7.1/8.7.1) id PAA14281; Tue, 10 Oct 1995 15:40:18 -0400 (EDT) Date: Tue, 10 Oct 1995 15:38:07 From: "Dave Thaler" <thalerd@eecs.umich.edu> Subject: some cisco melting down the mbone again Message-Id: <19951010153807.0@dip.eecs.umich.edu> To: mbone In-Reply-To: <> from "Vesa Ruokonen" at Tue, Oct 10, 1995 (13:35) Vesa Ruokonen writes: > Maybe related maybe not; I can see following nets in my mrouted: [...] > Those nets should be reserved for private use as per RFC 1597. > I suppose they should not show up in mrouteds either. Otherwise > something weird happens when two private nets meet.. While it is indeed incorrect behavior, those routes have actually been around for a long time now. I'm not sure where they're coming from, but they haven't hurt the MBone yet. Dave Thaler From list-mgr@ISI.EDU Tue Oct 10 13:04:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01237>; Tue, 10 Oct 1995 14:06:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01119>; Tue, 10 Oct 1995 14:05:58 -0700 Received: from tuolomne.cs.dartmouth.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA01110>; Tue, 10 Oct 1995 14:05:57 -0700 Received: by tuolomne.cs.dartmouth.edu (8.6.12/4.2) id RAA20185; Tue, 10 Oct 1995 17:04:22 -0400 Date: Tue, 10 Oct 1995 17:04:22 -0400 (EDT) From: Jon Howell <jonh@cs.dartmouth.edu> To: mbone Cc: Jon Howell <jonh@cs.dartmouth.edu> Subject: Query status of audio/video tools for Mac platform Message-Id: <Pine.OSF.3.91.951010165703.22484I-100000@tuolomne.cs.dartmouth.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We're possibly about to embark upon developing Mac-based MBone tools which would interoperate with sd, nevot/vat, nv/vic, and possibly eventually wb. I have two queries: 1) Is anyone already headed down this road? We don't want to reinvent the wheel, or compete with a huge wheel-engineering department if they're almost done. :v) (CUSeeMe translators don't count; we're thinking tools that are native to the MBone environment and existing standards) 2) If we go ahead with this, where can I get detailed info on the various packet encoding formats used in the different Unix tools? I've uncovered source to GSM, and I have tips for PCM and DVI. But vat clearly doesn't just use the GSM as it comes from the GSM library I have -- it appears to add some error-correcting data (explaining why it wants 17kbits when GSM can do 13kbits), but I have no idea what the frame format is. Also, I recall someone here is closed to finishing a new version of sd with source distributable. Will that person please drop me a note at your convenience? Thanks for any pointers and tips! --Jon Jon Howell, CS Dept. 420 Mt. Support Rd. Apt. #1 6211 Sudikoff Laboratory Lebanon, NH 03766 Hanover, NH 03755-3510 603-643-2460 jonh@cs.dartmouth.edu Rm. 111, 603 646-3297 http://www.cs.dartmouth.edu/~jonh From list-mgr@ISI.EDU Tue Oct 10 07:08:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01342>; Tue, 10 Oct 1995 14:09:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01323>; Tue, 10 Oct 1995 14:09:01 -0700 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA01314>; Tue, 10 Oct 1995 14:09:00 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA11268 (5.65c/IDA-1.4.4nsd for <mbone@isi.edu>); Tue, 10 Oct 1995 14:08:48 -0700 Received: by jaspar.NSD.3Com.COM id AA29719 (5.65c/IDA-1.4.4-910730); Tue, 10 Oct 1995 14:08:46 -0700 From: "Cyndi M. Jung" <cmj@NSD.3Com.COM> Message-Id: <199510102108.AA29719@jaspar.NSD.3Com.COM> Subject: Re: some cisco melting down the mbone again To: dino@cisco.com (Dino Farinacci) Date: Tue, 10 Oct 1995 14:08:46 -0700 (PDT) Cc: mbone In-Reply-To: <199510101757.KAA19812@stilton.cisco.com> from "Dino Farinacci" at Oct 10, 95 10:57:16 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 309 > > >> My new 'auto-mtrace-to-all-new-routes' script actually had a little bit of > >> luck: > > I will be adding a patch to 10.2, 10.3 and 11.0 to monitor routing table > sizes and complain as early as possbile when there is a surge. > > Dino > Any thoughts about *preventing* the surge? Cyndi From list-mgr@ISI.EDU Tue Oct 10 14:43:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12601>; Tue, 10 Oct 1995 17:39:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12452>; Tue, 10 Oct 1995 17:38:27 -0700 Received: from gold.mv.net by venera.isi.edu (5.65c/5.61+local-22) id <AA12445>; Tue, 10 Oct 1995 17:38:25 -0700 Received: from [199.125.78.103] by gold.mv.net (8.6.10/mv(b)/mem-941101) id UAA09096 for <MBONE@ISI.EDU>; Tue, 10 Oct 1995 20:38:20 -0400 Message-Id: <199510110038.UAA09096@gold.mv.net> X-Sender: pcmn-kr@gold.mv.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Oct 1995 19:43:26 -0500 To: MBONE From: kris@pcmn.mv.com (Kris Marciniak) Subject: unsubscribe unsubscribe Stop sending me all this bloody mail! From list-mgr@ISI.EDU Tue Oct 10 16:38:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12620>; Tue, 10 Oct 1995 17:40:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12535>; Tue, 10 Oct 1995 17:39:07 -0700 Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-22) id <AA12474>; Tue, 10 Oct 1995 17:39:03 -0700 Received: by rodan.UU.NET id QQzkxm16674; Tue, 10 Oct 1995 20:38:54 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: <QQzkxm16674.199510110038@rodan.UU.NET> Subject: Re: some cisco melting down the mbone again To: cmj@NSD.3Com.COM (Cyndi M. Jung) Date: Tue, 10 Oct 1995 20:38:53 -0400 (EDT) Cc: dino@cisco.com, mbone In-Reply-To: <199510102108.AA29719@jaspar.NSD.3Com.COM> from "Cyndi M. Jung" at Oct 10, 95 02:08:46 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 243 Any thought of making the mbone actually able to handle full routing tables? [Some parts of the mbone, like ciscos, can handle real routing tables; some parts can't. The parts that can't should be fixed.] --asp@uunet.uu.net (Andrew Partan) From list-mgr@ISI.EDU Tue Oct 10 20:37:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19724>; Tue, 10 Oct 1995 21:44:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19510>; Tue, 10 Oct 1995 21:38:15 -0700 Received: from portal (portal.netedge.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA19501>; Tue, 10 Oct 1995 21:38:13 -0700 Received: from NetEdge.COM by portal id AA23830; Wed, 11 Oct 95 00:37:28 EDT Received: from suicidesix.NetEdge.COM by NetEdge.COM id AA03605; Wed, 11 Oct 95 00:38:20 EDT Return-Path: <Tom_Pusateri@NetEdge.COM> Received: from localhost by suicidesix.NetEdge.COM (4.1/NECL-6.14) id AA26381; Wed, 11 Oct 95 00:37:25 EDT Message-Id: <9510110437.AA26381@NetEdge.COM> To: asp@uunet.uu.net (Andrew Partan) Cc: mbone Subject: Re: some cisco melting down the mbone again In-Reply-To: Your message of "Tue, 10 Oct 1995 20:38:53 EDT." <QQzkxm16674.199510110038@rodan.UU.NET> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <26378.813386244.1@suicidesix.netedge.com> Date: Wed, 11 Oct 1995 00:37:24 -0400 From: Thomas Pusateri <pusateri@NetEdge.COM> In message <QQzkxm16674.199510110038@rodan.UU.NET> you write: >Any thought of making the mbone actually able to handle full routing >tables? [Some parts of the mbone, like ciscos, can handle real routing >tables; some parts can't. The parts that can't should be fixed.] > --asp@uunet.uu.net (Andrew Partan) Everyone has been trying to get people to upgrade old DVMRP implementations (like the 2.x releases and the Proteon 4200's with limited memory running DVMRP without pruning) but this has been slow. The announcement by 3com to release DVMRP 3.5 and MOSPF should be good news to the owners of the Proteon boundary routers. Can 3com routers perform the multicast boundary router function between MOSPF and DVMRP? The other problem is the amount of CPU is takes to qsort() 25,000 routes. The current mrouted 3.6 implementation sorts the routing table like this with every route update. This is a little painful on older machines. The gated DVMRP implementation (sorry, still finishing up the testing) keeps a main routing table in a patricia tree and seperate arrays of patricia trees (one for each possible mask length) for each target (outgoing interface). As new routes come in, they are inserted in the main tree and if policy allows, they get inserted in the appropriate target trees based on the mask length in the route update. This allows for enormous routing tables without ever having to sort. Since there are different trees for each mask length, DMVRP reports still get sent out sorted by netmask and source network so as to not break older implementations. The source code will be released under the standard Gated Consortium License through the new owner, Merit, when testing is finished. Tom From list-mgr@ISI.EDU Tue Oct 10 19:23:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26597>; Wed, 11 Oct 1995 02:38:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26374>; Wed, 11 Oct 1995 02:24:00 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA26367>; Wed, 11 Oct 1995 02:23:58 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id CAA00915; Wed, 11 Oct 1995 02:23:53 -0700 Date: Wed, 11 Oct 1995 02:23:53 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199510110923.CAA00915@greatdane.cisco.com> To: cmj@nsd.3com.com ("Cyndi M. Jung") Cc: dino@cisco.com (Dino Farinacci), mbone Subject: Re: some cisco melting down the mbone again Any thoughts about *preventing* the surge? Stop trying to carry around a full-mbone set of routes. In the limit, this scales as badly as if every unicast router had to have full unicast routing tables. Tony From list-mgr@ISI.EDU Wed Oct 11 12:15:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26999>; Wed, 11 Oct 1995 03:20:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26973>; Wed, 11 Oct 1995 03:17:57 -0700 Received: from cismhp.univ-lyon1.fr by venera.isi.edu (5.65c/5.61+local-22) id <AA26962>; Wed, 11 Oct 1995 03:17:47 -0700 Received: by cismhp.univ-lyon1.fr (1.37.109.16/16.2) id AA104486505; Wed, 11 Oct 1995 11:15:05 +0100 From: Gilles Rech <gilles@univ-lyon1.fr> Message-Id: <199510111015.AA104486505@cismhp.univ-lyon1.fr> Subject: Re: some cisco melting down the mbone again To: tli@cisco.com (Tony Li) Date: Wed, 11 Oct 1995 11:15:04 +0100 (MET) Cc: cmj@nsd.3com.com, dino@cisco.com, mbone In-Reply-To: <199510110923.CAA00915@greatdane.cisco.com> from "Tony Li" at Oct 11, 95 02:23:53 am Organization: C.I.S.M., Universite Claude Bernard & INSA, Lyon, France. X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 417 Tony Li ecrit: > > Stop trying to carry around a full-mbone set of routes. In the limit, > this scales as badly as if every unicast router had to have full > unicast routing tables. > Could someone tell me if the number of routes advertised on Mbone has suddenly decreased at about 11:02 (GMT + 01:00) today ? Thanks in advance. -- Gilles Rech. C.I.S.M., Universite Claude Bernard Lyon I & INSA Lyon, France. From list-mgr@ISI.EDU Wed Oct 11 12:59:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27332>; Wed, 11 Oct 1995 04:01:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27277>; Wed, 11 Oct 1995 03:59:42 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA27269>; Wed, 11 Oct 1995 03:59:39 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id LAA15922; Wed, 11 Oct 1995 11:59:36 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id LAA13776; Wed, 11 Oct 1995 11:59:33 +0100 Date: Wed, 11 Oct 1995 11:59:32 +0100 (BST) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Gilles Rech <gilles@univ-lyon1.fr> Cc: mbone Subject: Re: some cisco melting down the mbone again In-Reply-To: <199510111015.AA104486505@cismhp.univ-lyon1.fr> Message-Id: <Pine.SV4.3.91.951011115901.13436D-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 11 Oct 1995, Gilles Rech wrote: > Tony Li ecrit: > > > > Stop trying to carry around a full-mbone set of routes. In the limit, > > this scales as badly as if every unicast router had to have full > > unicast routing tables. > > > Could someone tell me if the number of routes advertised on Mbone > has suddenly decreased at about 11:02 (GMT + 01:00) today ? > Thanks in advance. I have currently 2245 routes which is roughly what I would expect. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Wed Oct 11 12:56:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27380>; Wed, 11 Oct 1995 04:05:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27237>; Wed, 11 Oct 1995 03:57:15 -0700 Received: from cismhp.univ-lyon1.fr by venera.isi.edu (5.65c/5.61+local-22) id <AA27228>; Wed, 11 Oct 1995 03:57:12 -0700 Received: by cismhp.univ-lyon1.fr (1.37.109.16/16.2) id AA107729016; Wed, 11 Oct 1995 11:56:56 +0100 From: Gilles Rech <gilles@univ-lyon1.fr> Message-Id: <199510111056.AA107729016@cismhp.univ-lyon1.fr> Subject: PIM-DVMRP configuration problem To: mbone Date: Wed, 11 Oct 1995 11:56:56 +0100 (MET) Organization: C.I.S.M., Universite Claude Bernard & INSA, Lyon, France. X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1701 Hello, My conf: IOS 10.3.5 . I would like to set up several tunnels in DVMRP mode and only advertise through these tunnels the multicast routes my router learnt from the DVMRP routing process. I can't set up access-list beacause it would be too fastidious (too many networks). mrouted mrouted mrouted mrouted ! ! ! ! ! ! ! ! t0 t1 t2 t3 ! ! ! ! ! ------- cisco---- ! ----------------------- ---------------------- Can I achieve it this way : interface tunnel 0 [...] ip dvmrp metric 1 dvmrp interface tunnel 1 [...] ip dvmrp metric 1 dvmrp interface tunnel 2 [...] ip dvmrp metric 1 dvmrp interface tunnel 3 [...] ip dvmrp metric 1 dvmrp I've tried this configuration but I've got the following warning : "No ACL specified. May cause excessive routes to be advertised into the Mbone". Here is the quote from ftp.cisco.com:/ftp/dino/multicast/Docs/All-Commands : [no] ip dvmrp metric <metric> [list <access-list>] [<protocol> <process-id>] | [dvmrp] What is the exact purpose of the trailing 'dvmrp' keyword ? A workaround : let's assume that I don't want to advertise my EGP-learnt routes. Can I achieve it this way : router egp 2060 [...] interface tunnel0 [...] ip dvmrp metric 1 ip dvmrp metric 0 egp 2060 Will the unicast routes learnt by the EGP routing process be advertised ? Is the order of the commands important ? Thanks in advance for any help. -- Gilles Rech. C.I.S.M., Universite Claude Bernard Lyon I & INSA Lyon, France. From list-mgr@ISI.EDU Wed Oct 11 04:17:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28388>; Wed, 11 Oct 1995 05:17:49 -0700 Received: from Clyde.Concordia.CA by venera.isi.edu (5.65c/5.61+local-22) id <AB28381>; Wed, 11 Oct 1995 05:17:47 -0700 Received: from cs.concordia.ca (90@manitou.cs.concordia.ca [132.205.4.3]) by clyde.concordia.ca (8.6.11/8.6.10) with SMTP id IAA25210 for <mbone-na@isi.edu>; Wed, 11 Oct 1995 08:17:44 -0400 Received: from forest.cs.concordia.ca by manitou.cs.concordia.ca id aa09660; 11 Oct 95 12:17 GMT To: mbone-na Cc: bill@cs.concordia.ca Subject: Access to the Mbone Date: Wed, 11 Oct 1995 08:17:42 -0400 From: "J.W. (Bill) Atwood" <bill@cs.concordia.ca> Message-Id: <9510111217.aa09660@manitou.cs.concordia.ca> I am sorry to disturb this list, but I have tried to find information about connecting my university to the Mbone by starting from below, with no success. would someone point me to a contact point? I am located in Montreal (Canada); Concordia University is part of the RISQ (Quebec Scientific Network), which is in turn part of the Canadian network. RISQ has a connection to the US (I believe through the John Von Neumann center). Thank you for your (anticipated) help. Bill Atwood Dr. J.W. Atwood, Associate Professor, Department of Computer Science Concordia University, Montreal, Quebec, Canada H3G 1M8 (514) 848-3046 From list-mgr@ISI.EDU Wed Oct 11 04:29:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28590>; Wed, 11 Oct 1995 05:30:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28562>; Wed, 11 Oct 1995 05:29:07 -0700 Received: from cmsa.gmr.com by venera.isi.edu (5.65c/5.61+local-22) id <AA28555>; Wed, 11 Oct 1995 05:29:06 -0700 Message-Id: <199510111229.AA28555@venera.isi.edu> Received: from AHIPC2S by CMSA.gmr.com (IBM VM SMTP V2R2) with BSMTP id 9705; Wed, 11 Oct 95 08:29:02 EDT Date: Wed, 11 Oct 95 08:29:01 EDT From: GHIRSCH@CMSA.gmr.com To: mbone Subject: Unsubscribe From: Hirsch, Greg A. EDS/ACC 810-986-0129 Subject: Unsubscribe unsubscribe From list-mgr@ISI.EDU Wed Oct 11 05:16:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10435>; Wed, 11 Oct 1995 12:17:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10252>; Wed, 11 Oct 1995 12:16:14 -0700 Received: from nsd-www.MKT.3Com.COM ([139.87.172.5]) by venera.isi.edu (5.65c/5.61+local-22) id <AA10245>; Wed, 11 Oct 1995 12:16:13 -0700 Received: from tmaufer.ops.3com.com (139.87.36.112) by nsd-www.MKT.3Com.COM with SMTP (Apple Internet Mail Server 1.0); Wed, 11 Oct 1995 12:16:07 -0700 X-Sender: maufer@nsd-www.mkt.3Com.com Message-Id: <v0211011daca199048a0c@tmaufer.ops.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Oct 1995 12:16:06 -0700 To: Thomas Pusateri <pusateri@netedge.com> From: Tom Maufer <maufer@nsd.3Com.com> Subject: Re: some cisco melting down the mbone again Cc: asp@uunet.uu.net (Andrew Partan), mbone At 12:37 AM 10/11/95, Thomas Pusateri wrote: >In message <QQzkxm16674.199510110038@rodan.UU.NET> you write: >>Any thought of making the mbone actually able to handle full routing >>tables? [Some parts of the mbone, like ciscos, can handle real routing >>tables; some parts can't. The parts that can't should be fixed.] >> --asp@uunet.uu.net (Andrew Partan) > >Everyone has been trying to get people to upgrade old DVMRP implementations >(like the 2.x releases and the Proteon 4200's with limited memory running >DVMRP without pruning) but this has been slow. > >The announcement by 3com to release DVMRP 3.5 and MOSPF should be good news >to the owners of the Proteon boundary routers. Can 3com routers perform >the multicast boundary router function between MOSPF and DVMRP? Tom-- Yes, we have built 'policies' (i.e., route filters) to allow information exchange between DVMRP and MOSPF. MOSPF can prune back into DVMRP if no one is listening, and you can selectively only import certain multicast groups into MOSPF (or just import all or none of them). If anyone would like to beta test our 8.3 release, I could try to arrange that, just send me e-mail and I'll see what I can do. Cheers, Tom -- Tom Maufer <maufer@nsd.3com.com> 3Com Corporation NETBuilder II Marketing Engineer 5400 Bayfront Plaza, Mailstop 2213 Network Systems Division Santa Clara, CA 95052 Phone: +1 408 764-8814 <URL:http://www.3com.com/> Fax: +1 408 764-5002 From list-mgr@ISI.EDU Wed Oct 11 11:13:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06299>; Wed, 11 Oct 1995 11:14:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06219>; Wed, 11 Oct 1995 11:13:09 -0700 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA06208>; Wed, 11 Oct 1995 11:13:05 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.7.1/8.7.1) id OAA21172; Wed, 11 Oct 1995 14:13:14 -0400 (EDT) Date: Wed, 11 Oct 1995 14:03:53 From: "Dave Thaler" <thalerd@eecs.umich.edu> Subject: some cisco melting down the mbone again Message-Id: <19951011140353.0@dip.eecs.umich.edu> To: mbone In-Reply-To: <> from "Gilles Rech" at Wed, Oct 11, 1995 (10:26) Gilles Rech writes: > Could someone tell me if the number of routes advertised on Mbone > has suddenly decreased at about 11:02 (GMT + 01:00) today ? > Thanks in advance. Not from sydney.eecs.umich.edu. The closest thing here was a decrease by about 15 an hour later. Time Routes Reachable Wed Oct 11 08:41:58 GMT 2203 2202 Wed Oct 11 08:52:00 GMT 2207 2207 Wed Oct 11 09:02:02 GMT 2210 2197 Wed Oct 11 09:12:05 GMT 2218 2217 Wed Oct 11 09:22:07 GMT 2217 2217 Wed Oct 11 09:32:10 GMT 2218 2218 Wed Oct 11 09:42:13 GMT 2220 2220 Wed Oct 11 09:52:15 GMT 2223 2223 Wed Oct 11 10:02:18 GMT 2229 2229 Wed Oct 11 10:12:20 GMT 2242 2241 Wed Oct 11 10:22:23 GMT 2254 2254 Wed Oct 11 10:32:25 GMT 2254 2254 Wed Oct 11 10:42:27 GMT 2259 2259 Wed Oct 11 10:52:30 GMT 2267 2265 Wed Oct 11 11:02:32 GMT 2252 2252 Wed Oct 11 11:12:35 GMT 2256 2256 Wed Oct 11 11:22:37 GMT 2256 2256 Dave Thaler From list-mgr@ISI.EDU Wed Oct 11 19:11:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13465>; Wed, 11 Oct 1995 13:23:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13416>; Wed, 11 Oct 1995 13:22:09 -0700 Received: from cismhp.univ-lyon1.fr by venera.isi.edu (5.65c/5.61+local-22) id <AA13409>; Wed, 11 Oct 1995 13:22:05 -0700 Received: from g-rech.univ-lyon1.fr by cismhp.univ-lyon1.fr with SMTP (1.37.109.16/16.2) id AA131852896; Wed, 11 Oct 1995 21:21:36 +0100 Message-Id: <199510112021.AA131852896@cismhp.univ-lyon1.fr> X-Sender: gilles@cismhp.univ-lyon1.fr X-Mailer: Windows Eudora Version 1.4.3b4 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 11 Oct 1995 21:11:33 -0200 To: "Dave Thaler" <thalerd@eecs.umich.edu>, mbone From: gilles@univ-lyon1.fr (Gilles Rech) Subject: Re: some cisco melting down the mbone again Content-Transfer-Encoding: quoted-printable At 14:03 11/10/1995, Dave Thaler wrote: >Not from sydney.eecs.umich.edu. The closest thing here was a decrease >by about 15 an hour later. > >Dave Thaler Thanks for your reply, Dave. = -- Gilles Rech C.I.S.M., Universite Claude Bernard & INSA =E0 Lyon. From list-mgr@ISI.EDU Wed Oct 11 04:29:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28590>; Wed, 11 Oct 1995 05:30:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28562>; Wed, 11 Oct 1995 05:29:07 -0700 Received: from cmsa.gmr.com by venera.isi.edu (5.65c/5.61+local-22) id <AA28555>; Wed, 11 Oct 1995 05:29:06 -0700 Message-Id: <199510111229.AA28555@venera.isi.edu> Received: from AHIPC2S by CMSA.gmr.com (IBM VM SMTP V2R2) with BSMTP id 9705; Wed, 11 Oct 95 08:29:02 EDT Date: Wed, 11 Oct 95 08:29:01 EDT From: GHIRSCH@CMSA.gmr.com To: mbone Subject: Unsubscribe From: Hirsch, Greg A. EDS/ACC 810-986-0129 Subject: Unsubscribe unsubscribe From list-mgr@ISI.EDU Wed Oct 11 04:17:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28388>; Wed, 11 Oct 1995 05:17:49 -0700 Received: from Clyde.Concordia.CA by venera.isi.edu (5.65c/5.61+local-22) id <AB28381>; Wed, 11 Oct 1995 05:17:47 -0700 Received: from cs.concordia.ca (90@manitou.cs.concordia.ca [132.205.4.3]) by clyde.concordia.ca (8.6.11/8.6.10) with SMTP id IAA25210 for <mbone-na@isi.edu>; Wed, 11 Oct 1995 08:17:44 -0400 Received: from forest.cs.concordia.ca by manitou.cs.concordia.ca id aa09660; 11 Oct 95 12:17 GMT To: mbone-na Cc: bill@cs.concordia.ca Subject: Access to the Mbone Date: Wed, 11 Oct 1995 08:17:42 -0400 From: "J.W. (Bill) Atwood" <bill@cs.concordia.ca> Message-Id: <9510111217.aa09660@manitou.cs.concordia.ca> I am sorry to disturb this list, but I have tried to find information about connecting my university to the Mbone by starting from below, with no success. would someone point me to a contact point? I am located in Montreal (Canada); Concordia University is part of the RISQ (Quebec Scientific Network), which is in turn part of the Canadian network. RISQ has a connection to the US (I believe through the John Von Neumann center). Thank you for your (anticipated) help. Bill Atwood Dr. J.W. Atwood, Associate Professor, Department of Computer Science Concordia University, Montreal, Quebec, Canada H3G 1M8 (514) 848-3046 From list-mgr@ISI.EDU Wed Oct 11 15:14:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21688>; Wed, 11 Oct 1995 16:18:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21539>; Wed, 11 Oct 1995 16:15:36 -0700 Received: from bbnplanet.com (poblano.near.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA21530>; Wed, 11 Oct 1995 16:15:34 -0700 Subject: Re: some cisco melting down the mbone again To: Dave Thaler <thalerd@eecs.umich.edu> Date: Wed, 11 Oct 1995 19:14:30 -0400 (EDT) From: John Hawkinson <jhawk@bbnplanet.com> Cc: mbone In-Reply-To: <19951011140353.0@dip.eecs.umich.edu> from "Dave Thaler" at Oct 11, 95 02:03:53 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1323 Message-Id: <9510111914.aa16358@poblano.bbnplanet.com> > From: Dave Thaler <thalerd@eecs.umich.edu> > To: mbone@isi.edu > Gilles Rech writes: > > Could someone tell me if the number of routes advertised on Mbone > > has suddenly decreased at about 11:02 (GMT + 01:00) today ? > > Thanks in advance. > > Not from sydney.eecs.umich.edu. The closest thing here was a decrease > by about 15 an hour later. Actually, I think there were some sharp spikes. mbone1.ner.bbnplanet.net saw: 12:09:28 %DVMRP-1-ROUTEHOG: Receiving 10856 routes from 18.180.0.2 (Tunnel1) 12:51:38 %DVMRP-1-ROUTEHOG: Receiving 11436 routes from 198.112.8.2 (Tunnel0) 13:30:17 %DVMRP-1-ROUTEHOG: Receiving 11468 routes from 198.112.8.2 (Tunnel0) 14:34:39 %DVMRP-1-ROUTEHOG: Receiving 11452 routes from 198.112.8.2 (Tunnel0) 14:59:04 %DVMRP-1-ROUTEHOG: Receiving 10323 routes from 18.180.0.2 (Tunnel1) 16:20:50 %DVMRP-1-ROUTEHOG: Receiving 10235 routes from 198.112.8.2 (Tunnel0) 16:33:50 %DVMRP-1-ROUTEHOG: Receiving 10695 routes from 198.112.8.2 (Tunnel0) 17:31:11 %DVMRP-1-ROUTEHOG: Receiving 12043 routes from 18.180.0.2 (Tunnel1) 17:48:08 %DVMRP-1-ROUTEHOG: Receiving 11630 routes from 18.180.0.2 (Tunnel1) 17:48:11 %DVMRP-1-ROUTEHOG: Receiving 11886 routes from 198.112.8.2 (Tunnel0) But each time I checked there were only around 2400 routes (normal)... --jhawk@bbnplanet.com John Hawkinson From list-mgr@ISI.EDU Thu Oct 12 02:42:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25474>; Wed, 11 Oct 1995 17:43:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25447>; Wed, 11 Oct 1995 17:42:28 -0700 Received: from ncc.ripe.net by venera.isi.edu (5.65c/5.61+local-22) id <AA25439>; Wed, 11 Oct 1995 17:42:25 -0700 Received: from belegen.ripe.net by ncc.ripe.net with SMTP id AA02808 (5.65a/NCC-2.27); Thu, 12 Oct 1995 01:42:16 +0100 Message-Id: <9510120042.AA02808@ncc.ripe.net> To: asp@uunet.uu.net (Andrew Partan) Cc: mbone From: Geert Jan de Groot <GeertJan.deGroot@ripe.net> X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: Re: some cisco melting down the mbone again In-Reply-To: Your message of "Tue, 10 Oct 1995 20:38:53 -0400." <QQzkxm16674.199510110038@rodan.UU.NET> Date: Thu, 12 Oct 1995 01:42:16 +0100 Sender: GeertJan.deGroot@ripe.net On Tue, 10 Oct 1995 20:38:53 -0400 (EDT) Andrew Partan wrote: > Any thought of making the mbone actually able to handle full routing > tables? [Some parts of the mbone, like ciscos, can handle real routing > tables; some parts can't. The parts that can't should be fixed.] On a box at the NCC which runs full routing, I saw mrouted growing to 8M or so, and it kept running (next to a 19M gated on a BSDI box) The machine did crash a couple of times (panic: m_copym), which I have not investigated, but the machine was able to have the load. Since this box is also the primary router & I don't have time to investigate the crashes, we had to disable mbone till things get quiet again. Hmm.. is this the way to smoke out obsolete mrouted 2.x machines? Geert Jan (routers with virtual memory are Great ;-) From list-mgr@ISI.EDU Wed Oct 11 21:18:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04898>; Wed, 11 Oct 1995 20:29:55 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04581>; Wed, 11 Oct 1995 20:22:15 -0700 Received: from cythera.unb.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA04574>; Wed, 11 Oct 1995 20:22:14 -0700 Received: from cythera.unb.ca (cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.6.12/8.6.5) with SMTP id AAA18939; Thu, 12 Oct 1995 00:18:14 -0300 Date: Thu, 12 Oct 1995 00:18:14 -0300 (ADT) From: "Dwight E. Spencer" <spencer@unb.ca> To: Geert Jan de Groot <GeertJan.deGroot@ripe.net> Cc: Andrew Partan <asp@uunet.uu.net>, mbone Subject: Re: some cisco melting down the mbone again In-Reply-To: <9510120042.AA02808@ncc.ripe.net> Message-Id: <Pine.SOL.3.91.951012001442.649h-100000@cythera.unb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 11 Oct 1995, Geert Jan de Groot wrote: > Hmm.. is this the way to smoke out obsolete mrouted 2.x machines? > Geert Jan > (routers with virtual memory are Great ;-) i've got two machines on my campus running sun mrouted 2.2. One is being upgraded in the "near" future, and the other has to stay. My uplink, mbone.on.canet.ca is a proteon router, with mrouted version 1.0 did i hear a rumor that someone developed(ing) a new version of the OS for these machines, to support pruning? I know it would be great to having pruning in all our sites in canada, having speeds of t1 to 4mbps for inter-province links. dwight. ---------------------------------------------------------------------------- Dwight E. Spencer Community Access Program eMail: spencer@unb.ca "C-Net" Server Administrator Phone: +1 506 453 4614 UNB, Fredericton, NB, Canada Url: http://cnet.unb.ca/cspace/staff/dspencer/ From list-mgr@ISI.EDU Thu Oct 12 01:45:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13589>; Thu, 12 Oct 1995 02:47:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13569>; Thu, 12 Oct 1995 02:45:33 -0700 Received: from andy.dia.atd.net by venera.isi.edu (5.65c/5.61+local-22) id <AA13562>; Thu, 12 Oct 1995 02:45:30 -0700 Received: (from crobson@localhost) by andy.dia.atd.net (8.6.9/8.6.9) id FAA00694; Thu, 12 Oct 1995 05:45:29 -0400 Date: Thu, 12 Oct 1995 05:45:29 -0400 (EDT) From: Chris Robson ATDNet Admin <crobson@andy.dia.atd.net> To: mbone Subject: World Radio? Message-Id: <Pine.SUN.3.91.951012054224.461F-100000@andy.dia.atd.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII With fear that I might start a firestorm could I ask what's up with the World Radio? ...chris From list-mgr@ISI.EDU Thu Oct 12 07:22:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21328>; Thu, 12 Oct 1995 08:25:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21302>; Thu, 12 Oct 1995 08:24:28 -0700 Received: from trystero.radio.com by venera.isi.edu (5.65c/5.61+local-22) id <AA21294>; Thu, 12 Oct 1995 08:24:27 -0700 Received: (carl@localhost) by trystero.radio.com (8.7.1/940816.06ccg) id LAA28101; Thu, 12 Oct 1995 11:22:53 -0400 (EDT) From: Carl Malamud <carl@radio.com> Message-Id: <199510121522.LAA28101@trystero.radio.com> Subject: Re: World Radio? To: crobson@andy.dia.atd.net (Chris Robson ATDNet Admin) Date: Thu, 12 Oct 1995 11:22:53 -0400 (EDT) Cc: mbone In-Reply-To: <Pine.SUN.3.91.951012054224.461F-100000@andy.dia.atd.net> from "Chris Robson ATDNet Admin" at Oct 12, 95 05:45:29 am Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi - Our screwup ... we have a stack of Sparc 1's we use to send out our feeds and they have a bad habit of freezing occassionally. As soon as the VAT SNMP implementation is available, we'll page ourselves at home when it stops. :) Carl According to Chris Robson ATDNet Admin: > > > With fear that I might start a firestorm could I ask what's up with the > World Radio? > > ...chris > From list-mgr@ISI.EDU Thu Oct 12 09:27:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24368>; Thu, 12 Oct 1995 09:27:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24226>; Thu, 12 Oct 1995 09:27:12 -0700 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA24215>; Thu, 12 Oct 1995 09:27:10 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.7.1/8.7.1) id MAA27008; Thu, 12 Oct 1995 12:27:20 -0400 (EDT) Date: Thu, 12 Oct 1995 12:18:42 From: "Dave Thaler" <thalerd@eecs.umich.edu> Subject: some cisco melting down the mbone again Message-Id: <19951012121842.0@dip.eecs.umich.edu> To: mbone A graph of routing table size over the previous 24 hour period (as seen from sydney.eecs.umich.edu) is available at: http://sydney.eecs.umich.edu/cgi-bin/routes Data points are collected at 10 minute intervals. The graph is generated on the fly, so it's always up to date. The link is also accessible via our project home page: http://www.merit.edu/~mbone Dave Thaler From list-mgr@ISI.EDU Thu Oct 12 11:17:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02881>; Thu, 12 Oct 1995 12:18:01 -0700 Received: from all-purpose-gunk.near.net by venera.isi.edu (5.65c/5.61+local-22) id <AA02873>; Thu, 12 Oct 1995 12:17:59 -0700 Received: (from jhawk@localhost) by all-purpose-gunk.near.net (8.7.1/8.7.1) id PAA15376; Thu, 12 Oct 1995 15:17:41 -0400 (EDT) Date: Thu, 12 Oct 1995 15:17:41 -0400 (EDT) Message-Id: <199510121917.PAA15376@all-purpose-gunk.near.net> To: mbone-na Subject: DVMRP advertisement in net 90? Cc: Ron.Hutchins@OIT.GATECH.EDU, nick.pope@OIT.GATECH.EDU, root@houdini.oit.gatech.edu From: John Hawkinson <jhawk@bbnplanet.com> At least since the 10th, and probably earlier, I see the following nets: Origin-Subnet From-Gateway Metric Tmr In-Vif Out-Vifs 90.13.60/22 199.94.207.2 11 20 1 0* 90.10.104/22 199.94.207.2 9 20 1 0* 90.4.48/22 199.94.207.2 10 20 1 0* (net 90 is part of IANA RESERVED-7). Could someone at gatech try and figure out where they're coming from? Attached is an mtrace. The closest source is presumably only two hops away from houdini-fddi.gatech.edu... 130.207.244/24 199.94.207.2 7 20 1 0* Thanks! --jhawk@bbnplanet.com John Hawkinson [all-purpose-gunk!jhawk] ~> mtrace 90.10.104.9 Mtrace from 90.10.104.9 to 198.114.157.114 via group 224.2.0.1 Querying full reverse path... * switching to hop-by-hop: 0 all-purpose-gunk.near.net (198.114.157.114) -1 all-purpose-gunk.near.net (198.114.157.114) DVMRP thresh^ 1 -16 ms -2 mbone1.ner.bbnplanet.net (199.94.207.2) DVMRP thresh^ 16 246680 ms -3 MBONE3.UU.NET (137.39.229.98) DVMRP thresh^ 64 -89 ms -4 MBONE1.UU.NET (137.39.43.34) DVMRP thresh^ 64 -61 ms -5 * mae-bone.psi.net (192.41.177.247) DVMRP thresh^ 64 -62498 ms -6 wtn-ms1.sura.net (192.41.177.197) DVMRP thresh^ 32 33909 ms -7 * * * * houdini-fddi.gatech.edu (130.207.244.27) didn't respond Round trip time 208 ms Results after 20 seconds: Source Response Dest Packet Statistics For Only For Traffic * * * 198.114.157.114 All Multicast Traffic From 90.10.104.9 | __/ rtt 273 ms Lost/Sent = Pct Rate To 224.2.0.1 v / hop -33 s --------------------- -------------------- 192.41.177.197 wtn-ms1.sura.net | ^ ttl 32 v | hop 96 s 357/396 = 90% 19 pps 0/0 = --% 0 pps 192.41.177.247 mae-bone.psi.net | ^ ttl 64 v | hop -62 s -1/217 = 0% 10 pps 0/0 = --% 0 pps 137.39.43.34 MBONE1.UU.NET | ^ ttl 65 v | hop 53 ms 21/1237 = 2% 61 pps 0/0 = --% 0 pps 137.39.229.98 MBONE3.UU.NET | ^ ttl 66 v | hop -246 s 1188/1188 =100% 59 pps 0/0 = --% 0 pps 199.94.207.2 mbone1.ner.bbnplanet.net | ^ ttl 67 v | hop 246 s -2008/0 = --% 0 pps 0/0 = --% 0 pps 198.114.157.114 all-purpose-gunk.near.net | \__ ttl 68 v \ hop -33 ms 1462 73 pps 0 0 pps 198.114.157.114 198.114.157.114 Receiver Query Source From list-mgr@ISI.EDU Thu Oct 12 11:53:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09906>; Thu, 12 Oct 1995 14:48:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09894>; Thu, 12 Oct 1995 14:48:05 -0700 Received: from gold.mv.net by venera.isi.edu (5.65c/5.61+local-22) id <AA09887>; Thu, 12 Oct 1995 14:48:04 -0700 Received: from [199.125.78.103] by gold.mv.net (8.6.10/mv(b)/mem-941101) id RAA14881 for <mbone@ISI.EDU>; Thu, 12 Oct 1995 17:47:59 -0400 Message-Id: <199510122147.RAA14881@gold.mv.net> X-Sender: pcmn-kr@gold.mv.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Oct 1995 16:53:08 -0500 To: mbone From: kris@pcmn.mv.com (Kris Marciniak) Subject: unsubscribe unsubscribe unsubscribe unsubscribe unsubscribe Please! From list-mgr@ISI.EDU Thu Oct 12 12:48:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15305>; Thu, 12 Oct 1995 16:39:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15201>; Thu, 12 Oct 1995 16:38:46 -0700 Received: from piglet.coe.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA15169>; Thu, 12 Oct 1995 16:38:43 -0700 Received: from most.coe.missouri.edu (most.coe.missouri.edu [128.206.59.186]) by piglet.coe.missouri.edu (8.7.1/8.7.1) with SMTP id RAA13937 for <mbone@isi.edu>; Thu, 12 Oct 1995 17:48:23 -0500 (CDT) Date: Thu, 12 Oct 1995 17:48:22 -0500 (CDT) From: Mark Donnelly <mark@coe.missouri.edu> To: mbone Subject: List of protocols? Message-Id: <Pine.SGI.3.91.951012173800.1440A-100000@most.coe.missouri.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, all: I've been looking around in the FAQs and such, and I can't find any lists of protocols for any of the applications. I've found locations for pre-compiled apps, I've found lists of protocols for multicast packets, I'v found kernel extensions to give multicast suppourt, but I can't find any protocols for any apps, except for a postscript version of an SD draft. Any help would be appreciated! I'm especially on the lookout for: --SD (update?) --VAT --NV --WB Thanks, all. --Mark Donnelly From list-mgr@ISI.EDU Thu Oct 12 14:22:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17146>; Thu, 12 Oct 1995 17:23:12 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17105>; Thu, 12 Oct 1995 17:22:38 -0700 Received: from cis.usouthal.edu (baltic.cis.usouthal.edu) by venera.isi.edu (5.65c/5.61+local-22) id <AA17098>; Thu, 12 Oct 1995 17:22:34 -0700 Received: by cis.usouthal.edu (5.x/SMI-SVR4) id AA00745; Thu, 12 Oct 1995 19:22:27 -0500 Date: Thu, 12 Oct 1995 19:22:27 -0500 From: mcmillan@cis.usouthal.edu (Barry McMillan) Message-Id: <9510130022.AA00745@cis.usouthal.edu> To: mbone Subject: Unsubscribe X-Sun-Charset: US-ASCII unsubscribe From list-mgr@ISI.EDU Fri Oct 13 11:55:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02982>; Fri, 13 Oct 1995 02:59:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02969>; Fri, 13 Oct 1995 02:58:24 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA02962>; Fri, 13 Oct 1995 02:58:22 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA21201>; Fri, 13 Oct 1995 02:56:49 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.10837-0@bells.cs.ucl.ac.uk>; Fri, 13 Oct 1995 10:55:12 +0100 From: Mark Handley <M.Handley@cs.ucl.ac.uk> Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: Mark Donnelly <mark@coe.missouri.edu> Cc: mbone Subject: Re: List of protocols? In-Reply-To: Your message of "Thu, 12 Oct 95 17:48:22 CDT." <Pine.SGI.3.91.951012173800.1440A-100000@most.coe.missouri.edu> Date: Fri, 13 Oct 95 10:55:02 +0100 Message-Id: <3226.813578102@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >I've been looking around in the FAQs and such, and I can't find any lists >of protocols for any of the applications. I've found locations for >pre-compiled apps, I've found lists of protocols for multicast packets, >I'v found kernel extensions to give multicast suppourt, but I can't find >any protocols for any apps, except for a postscript version of an SD >draft. > >Any help would be appreciated! I'm especially on the lookout for: >--SD (update?) The latest draft is still http://www.cs.ucl.ac.uk/staff/mhandley/sdp.01.ps I will get a new draft out very soon. >--VAT You probably don't want to use the vat protocol. I believe an RTPv2 (see draft-ietf-avt-rtp.07.ps) vat will be available in the not too distant future. >--NV nv still uses RTPv1. I don't know what the upgrade plans are, but you can get NV encoding with RTPv2 from vic. >--WB There's a paper in Sigcomm '95 proceedings describing the general principles of Scalable Reliable Multicast. I don't know of anything describing the bits on the wire. Mark From list-mgr@ISI.EDU Fri Oct 13 14:55:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05175>; Fri, 13 Oct 1995 05:57:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05142>; Fri, 13 Oct 1995 05:55:54 -0700 Received: from amber.kulnet.kuleuven.ac.be by venera.isi.edu (5.65c/5.61+local-22) id <AA05135>; Fri, 13 Oct 1995 05:55:50 -0700 Received: (from xtof@localhost) by amber.kulnet.kuleuven.ac.be (8.6.10/8.6.9) id NAA09568 for mbone@ISI.EDU; Fri, 13 Oct 1995 13:55:49 +0100 From: Christophe Huygens <Christophe.Huygens@kulnet.KULeuven.ac.be> Message-Id: <199510131255.NAA09568@amber.kulnet.kuleuven.ac.be> Subject: Cisco IOS 11.0 and mrouted compatibility To: mbone Date: Fri, 13 Oct 1995 13:55:49 +0100 (MET) X-Mailer: ELM [version 2.4 PL0] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 1157 Hi, I am quite sure someone must have the following setup operational: --- Mbone Feed --- --------------- cisco IOS 11.0 ----- mrouted machines (3.x) Both the mbone feed and the mrouted machines are on the same unicast side of the cisco. Basically, I would like to have the cisco fan out into several mrouted's. Some observed problems with what I thought was straightforward: 1. Enabling PIM on any dvmrp tunnel (as described in the manual) seems to eat away all memory 2. If pim is disabled on the tunnels nothing seems to work 3. If pim is enabled, there is no "downstream flow" of info, possibly since there is an RPF violation involved. Any workarounds, ideas or (even better) configuration examples? PS: we would enable pim, eliminating a lot of internal mrouteds if we did not run into this memory leaking problem... Dino? Thanks in advance, Christophe Huygens -- K.U. Leuven Network - K.U. Leuven Campus Wide Information System - TC Christophe Huygens email: Christophe.Huygens@kulnet.kuleuven.ac.be DeCroylaan 52a tel : +32 (0) 16 32 21 66 B-3001 Heverlee fax : +32 (0) 16 32 29 99 From list-mgr@ISI.EDU Fri Oct 13 20:18:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11948>; Fri, 13 Oct 1995 09:21:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AB11883>; Fri, 13 Oct 1995 09:20:02 -0700 Received: from mits.mdata.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA11821>; Fri, 13 Oct 1995 09:19:34 -0700 Received: (setala@localhost) by mits.mdata.fi (8.6.12/8.6.5) id SAA00238 for mbone@isi.edu; Fri, 13 Oct 1995 18:18:21 +0200 From: Saku Setala <setala@mits.mdata.fi> Message-Id: <199510131618.SAA00238@mits.mdata.fi> Subject: Any video transmission hardware available for pc-unix? To: mbone Date: Fri, 13 Oct 1995 18:18:21 +0200 (EET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 380 Hi, is there any hardware available to do multicast video transmissions from a pc using some of the Free Unixes (Linux, FreeBSD, NetBSD or similar), or is the only possibility to have a Sun or SGI to do the transmission? How about connecting multiple cameras with remote switching of the input source? Thanks for the information. --Saku Setala Microdata Oy Helsinki, Finland From list-mgr@ISI.EDU Fri Oct 13 03:27:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15298>; Fri, 13 Oct 1995 10:29:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15262>; Fri, 13 Oct 1995 10:29:09 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA15255>; Fri, 13 Oct 1995 10:29:07 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id KAA04396; Fri, 13 Oct 1995 10:27:11 -0700 Message-Id: <199510131727.KAA04396@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Saku Setala <setala@mits.mdata.fi> Cc: mbone Subject: Re: Any video transmission hardware available for pc-unix? In-Reply-To: Your message of "Fri, 13 Oct 1995 18:18:21 +0200." <199510131618.SAA00238@mits.mdata.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Oct 1995 10:27:07 -0700 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> For FreeBSD there is a Matrox Meteor PCI capture board and one of the authors, Jim Lowe, modified nv to work with the matrox capture board. His setup works rather well. If you like to hear more details about the Matrox video capture driver, mail to Jim Lowe <james@miller.cs.uwm.edu>. Mark Tinguely <tinguely@plains.nodak.edu>, wrote a device driver for the Media Vision ProMovie Studio ISA board and wrote an nv interface module. These boards are cheap and are no longer supported by Media Vision however people seem to be able to find them. If you are interested in the PMS solution just mail to Mark for details. Enjoy, Amancio >>> Saku Setala said: > Hi, > > is there any hardware available to do multicast video transmissions > from a pc using some of the Free Unixes (Linux, FreeBSD, NetBSD or similar), > or is the only possibility to have a Sun or SGI to do the transmission? > > How about connecting multiple cameras with remote switching of the > input source? > > Thanks for the information. > > --Saku Setala > Microdata Oy > Helsinki, Finland > From list-mgr@ISI.EDU Fri Oct 13 21:29:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21173>; Fri, 13 Oct 1995 12:30:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21131>; Fri, 13 Oct 1995 12:29:55 -0700 Received: from zaphod.axion.bt.co.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA21122>; Fri, 13 Oct 1995 12:29:53 -0700 Message-Id: <199510131929.AA21122@venera.isi.edu> Received: from bt-web.bt.co.uk by zaphod.axion.bt.co.uk via DECnet inbound channel id <sg.05931-0@zaphod.axion.bt.co.uk>; Fri, 13 Oct 1995 20:29:36 +0100 X-Vms-To: R11F::ISI.EDU::MBONE To: mbone From: courtenay_j_m <courtenay_j_m@bt-web.bt.co.uk> Subject: Re: mrouted under Solaris - please help (now) Date: Fri, 13 Oct 1995 20:29:36 +0100 Remember this? > debug level 2 > mrouted version 3.4a > installing le0 (132.146.196.183 on subnet 132.146.196) as vif #0 - rate=0 > installing tunnel from 132.146.196.183 to 128.4.0.8 as vif #1 - rate=500 > setsockopt DVMRP_ADD_VIF: Option not supported by protocol This error appears to be caused by having the Solaris RSVP/CBQ package over the top of the multicast distribution. I can switch between mrouted and RSVP operation with a re-install and a reboot but can't do both at the same time. -- J Mark Courtenay tel. +44 1473 645423/640871 MLB 4 15/ADMIN 2 OP4 fax. +44 1473 620101/640709 BT Labs, Martlesham Heath Ipswich, UK IP5 7RE courtejm@boat.bt.co.uk From list-mgr@ISI.EDU Mon Oct 16 11:38:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22827>; Mon, 16 Oct 1995 02:49:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22819>; Mon, 16 Oct 1995 02:47:50 -0700 Received: from amber.kulnet.kuleuven.ac.be by venera.isi.edu (5.65c/5.61+local-22) id <AA22776>; Mon, 16 Oct 1995 02:38:50 -0700 Received: (from xtof@localhost) by amber.kulnet.kuleuven.ac.be (8.6.10/8.6.9) id KAA25673 for mbone@ISI.EDU; Mon, 16 Oct 1995 10:38:39 +0100 From: Christophe Huygens <Christophe.Huygens@kulnet.KULeuven.ac.be> Message-Id: <199510160938.KAA25673@amber.kulnet.kuleuven.ac.be> Subject: RE: Cisco IOS 11.0 and mrouted compatibility To: mbone Date: Mon, 16 Oct 1995 10:38:38 +0100 (MET) X-Mailer: ELM [version 2.4 PL0] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 758 Christophe Huygens wrote : > Hi, > > I am quite sure someone must have the following setup operational: > > > > --- Mbone Feed --- --------------- cisco IOS 11.0 ----- mrouted machines (3.x) > > Both the mbone feed and the mrouted machines are on the same unicast side > of the cisco. > > Basically, I would like to have the cisco fan out into several mrouted's. > Good support from cisco and an upgrade from 11.0(1) to 11.0(2) solved all problems. Thank you! Christophe Huygens -- K.U. Leuven Network - K.U. Leuven Campus Wide Information System - TC Christophe Huygens email: Christophe.Huygens@kulnet.kuleuven.ac.be DeCroylaan 52a tel : +32 (0) 16 32 21 66 B-3001 Heverlee fax : +32 (0) 16 32 29 99 From list-mgr@ISI.EDU Mon Oct 16 08:43:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01097>; Mon, 16 Oct 1995 08:42:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00937>; Mon, 16 Oct 1995 08:41:01 -0700 Received: from unb.ca (hermes.csd.unb.ca) by venera.isi.edu (5.65c/5.61+local-22) id <AA00930>; Mon, 16 Oct 1995 08:40:59 -0700 Received: from [131.202.45.24] by unb.ca (8.6.12/950414-15:35) id MAA23484; Mon, 16 Oct 1995 12:40:54 -0300 Message-Id: <199510161540.MAA23484@unb.ca> X-Sender: burk@pop.unb.ca Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Oct 1995 12:43:22 -0400 To: mbone, rem-conf@es.net, ASIS-L@uvmvm.uvm.edu, PACS-L@uhupvm1.uh.edu, WEB4LIB@library.berkeley.edu, LEX-L@unb.ca From: burk@unb.ca (Alan Burk) Subject: m-bone announcement Cc: sloan@unb.ca, spencer@unb.ca, DAVID@BIBLIO.CURTIN.EDU.AU, clifford.lynch@ucop.edu Access '95 is a Conference being held at the University of New Brunswick in Fredericton, NB, Canada. The conference focus is on libraries and the World Wide Web - particularly on gateways and Web publishing. The conference organizers wish to announce that two sessions will be broadcast using m-bone technology. The first session will be the keynote address by Clifford Lynch. Clifford is planning to discuss implications of web browsers for the design of online catalogs and related information retrieval systems, and architectural issues involved in Z39.50 "clients" and web browsers. This broadcast will take place on Monday, October 23rd at 8 AM EDT. The second broadcast will be at 6 PM EDT, Tuesday October 24th. David Seaman, Coordinator of Electronic Texts, University of Virginia, will be speaking on the future of Electronic Publishing. Technical notes: The technical contact for these broadcasts is Dwight Spencer (spencer@unb.ca). He sends us the following technical information: We will be using NV and vat, with a ttl of 127, with nv possibly sending cusm encoding if we get our cusm reflector and vat working. nv will be using a bandwidth of ~70kbps, and audio (vat) format may be idvi. Rebroadcasts are possible and will be announced at a later date. Also possible are CuSeeMe broadcasts at the times mentioned. If we can get the audio working properly, the reflector will be irc.unb.ca. Thanks to Clifford Lynch, David Seaman, Dwight Spencer, Steve Sloan and UNB's Computing Services for making this possible. Alan ************** Alan Burk, Associate Director of Libraries University of New Brunswick / Box 7500 / Fredericton, N.B./ E3B 5H5 Voice 506-453-4740 Fax 506-453-4595 From list-mgr@ISI.EDU Mon Oct 16 03:44:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07269>; Mon, 16 Oct 1995 10:44:53 -0700 Received: from microplex.com (ludwig.microplex.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA07262>; Mon, 16 Oct 1995 10:44:48 -0700 Received: by microplex.com (4.1/SMI-4.1/920826) id AA05411; Mon, 16 Oct 95 10:44:46 PDT From: csd@microplex.com (Christian Daudt) Message-Id: <9510161744.AA05411@microplex.com> Subject: repost:Tunnel request for Burnaby - Canada To: mbone-na Date: Mon, 16 Oct 1995 10:44:45 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1001 Hi, I'm reposting a request for a MBONE tunnel. I do not work for a network provider, but our provider is not interested in setting up a MBONE tunnel now so we will have to connect ourselves. Our connectivity to the outside world is: - MCI in Seattle - ANS in Seattle - iSTAR in Ottawa (which is being upgraded to a full T1 these days). From Ottawa, there are direct connections to Toronto, CA*net and New York. These are all full T1 links. So I would like to request a tunnel to people directly connected to those networks (iSTAR also told me that the 2 links to Seattle are much less likely to be congested so they would be a better choice). thanks in advance, Christian -- ---------------------------------------------------------------- Christian Daudt (csd@microplex.com) Software Engineer Microplex Systems Ltd. URL: http://www.microplex.com/ "You can tell how far we have to go, when FORTRAN is the language of supercomputers." -- Steven Feiner From list-mgr@ISI.EDU Mon Oct 16 09:51:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08049>; Mon, 16 Oct 1995 11:01:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07971>; Mon, 16 Oct 1995 10:59:50 -0700 Received: from maelstrom.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA07949>; Mon, 16 Oct 1995 10:59:27 -0700 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.6.10/8.6.6) id NAA11379 for mbone@isi.edu; Mon, 16 Oct 1995 13:51:43 -0400 Message-Id: <199510161751.NAA11379@maelstrom.cc.mcgill.ca> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Yves Lepage <yves@CC.McGill.CA> Date: Mon, 16 Oct 95 13:51:41 -0400 To: mbone Subject: The cursed cisco Reply-To: yves@cc.mcgill.ca Hi all, Is that cursed cisco still killing the MBONE? my mrouted is still sick about something... 126% cpu ... Thanks. Yves Lepage yves@cc.mcgill.ca From list-mgr@ISI.EDU Mon Oct 16 12:19:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12160>; Mon, 16 Oct 1995 12:22:31 -0700 Received: from hub.ubc.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA12145>; Mon, 16 Oct 1995 12:22:25 -0700 Received: (from ean@localhost) by hub.ubc.ca (8.6.12/1.14) id MAA26245; Mon, 16 Oct 1995 12:22:23 -0700 X400-Received: by /PRMD=ca/ADMD=/C=/; Relayed; Mon, 16 Oct 1995 12:22:17 UTC-0700 X400-Received: by /PRMD=ca/ADMD=/C=/; Relayed; Mon, 16 Oct 1995 12:19:15 UTC-0700 Date: Mon, 16 Oct 1995 12:19:15 UTC-0700 X400-Originator: hay@ucs.ubc.ca X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=ca/ADMD=/C=/;951016121915] Content-Identifier: 40221 From: Marilyn Hay <hay@ucs.ubc.ca> To: mbone-na Cc: Christian Daudt <csd@microplex.com> In-Reply-To: <9510161744.AA05411@microplex.com> Message-Id: <"40221*hay@ucs.ubc.ca"@MHS> Subject: Re: repost:Tunnel request for Burnaby - Canada Mime-Version: 1.0 (Generated by Ean X.400 to MIME gateway) Hi Christian, I don't believe that our mbone router is a good place for your connection request. An example traceroute goes from the (soon to be installed) mbone.bc.net host to you as: traceroute to microplex.com (204.191.175.7), 30 hops max, 40 byte packets 1 c7010.hc.bc.net (128.189.4.254) 3 ms 2 ms 2 ms 2 psp.bc.canet.ca (192.68.61.1) 21 ms 60 ms 22 ms 3 205.207.238.102 (205.207.238.102) 66 ms 71 ms 71 ms 4 ix-canet.on.canet.ca (204.138.26.13) 77 ms * 67 ms 5 border1.toronto.fonorola.net (204.138.26.42) 77 ms 74 ms 83 ms 6 border2.toronto.fONOROLA.net (198.53.252.2) 124 ms 169 ms 246 ms 7 border1.ottawa.fONOROLA.net (198.53.254.10) 155 ms * 99 ms 8 border1.vancouver.fONOROLA.net (198.53.254.18) 345 ms 241 ms 261 ms 9 Wimsey-GW.vancouver.fONOROLA.net (198.53.80.242) 167 ms 255 ms 233 ms 10 mplex.bby.wis.net (204.191.160.250) 331 ms 275 ms 197 ms 11 ludwig.microplex.com (204.191.175.7) 152 ms 164 ms 163 ms This is across Canada via CA*net and back again via fONOROLA. An mbone router at Seattle would be better suited for you. Take care, Marilyn Hay voice mail: 604-822-1348 BCnet, Network Management Centre 1-800-255-8588 515 West Hastings Street fax mail: 604-291-5022 Vancouver, B.C. Canada V6B 5K3 e-mail: Marilyn.Hay@bc.net From list-mgr@ISI.EDU Mon Oct 16 05:51:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13487>; Mon, 16 Oct 1995 12:52:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13467>; Mon, 16 Oct 1995 12:51:59 -0700 Received: from anduin.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA13460>; Mon, 16 Oct 1995 12:51:58 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by anduin.ocf.llnl.gov (4.1/SMI-4.0) id AA00257; Mon, 16 Oct 95 12:51:54 PDT Message-Id: <9510161951.AA00257@anduin.ocf.llnl.gov> X-Sender: jed@anduin.ocf.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Oct 1995 12:51:57 -0700 To: mbone From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Multicasting with ATM - a concern Cc: rem-conf@es.net I would like to raise a concern I have about approaches and progress on multicast over Asychronous Transfer Mode (ATM) technology (adapters, switches, etc.). I will admit upfront that I do not have complete knowledge of where progress is being made in this area. It is an area that I dabble in but am not actively involved in. I could just let my concern go, but decided to try to clarify it with this message. I'm ready to be blasted, but I hope I'm blasted with some pointers to some new information on multicast over ATM. Having read the Internet-Draft "Support for Multicast over UNI3.1 b ased ATM Networks" - draft-ieft-ipatm-07.txt, I am concerned about the direction that seems to be being taken. In that document there are two approaches described for routing multicast packets (independent of how multicast groups are set up): 1. Meshes of point to multipoint Virtual Circuits (VCs), or 2. routing multicast packets through a multicast server (MCS) that has a single point to multipoint VC to all the leaf notes of a multicast group. Both of these approaches seem quite poor to me. They are both serious steps backwards from the sort of mechanisms that are currently available for IP multicast (either on MBone or in multicast capable routers). It seems to me that what is needed is some sort of multicast virtual circuit. With such a circuit, nodes could join locally and have their cells routed (through a table in the ATM switches much like with unicast or point to multipoint VCs) to the appropriate next switches (much like as now happens with IP multicast). Specifically cells would not be routed back to where they came from (e.g. as happens with the MCS approach). Also, only one such structure would exist in any switch for a multicast group (unlike with the mesh of VCs approach which has one point to multipoint VC for every leaf node transmitter in a multicast group). Can anyone give me a pointer to work on ATM multicast beyond that described in the draft-ieft-ipatm-07.txt? It would seem that such work would require a UNI beyond 3.1 with perhaps some support for direct multicast VSs? Any pointers and/or suggestions are welcome. Thanks! --Jed http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Mon Oct 16 05:57:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13676>; Mon, 16 Oct 1995 12:57:48 -0700 Received: from starfleet (starfleet.internex.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA13638>; Mon, 16 Oct 1995 12:57:45 -0700 Received: from farragut.InterNex.Net by starfleet (SMI-8.6.9/SMI-SVR4) id MAA08458; Mon, 16 Oct 1995 12:57:43 -0700 Received: by farragut.InterNex.Net (5.x/SMI-SVR4) id AA10775; Mon, 16 Oct 1995 12:57:36 -0700 From: "Marcos Della" <mdella@farragut.InterNex.Net> Message-Id: <9510161257.ZM10773@farragut> Date: Mon, 16 Oct 1995 12:57:35 -0700 X-Mailer: Z-Mail (3.2.1 10apr95) To: mbone-na Subject: Still looking for an MBONE tunnel for our ISP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi there... Still no response from anyone on getting a tunnel set up to our site. We would prefer through Mae-West, however as things are going, Its starting to look like we'll even take an mbone feed from anyone including overseas since no one is stepping up to the plate. I assume no one is bothering to manage how all the interconnects are going since I have been requesting for a few months now with zero response. I suppose it really doesn't matter who's lines this all goes across. If there is someone attempting to manage the connections, please let me know as I do not want to do things outside of standards, but am ready to do anything since I really need a connection from somewhere... Marcos -- ''' (- -) --------------------------oOO--(_)--OOo-------------------------- Marcos R. Della Email: mdella@InterNex.Net Director, Network Engineering InterNex Information Services Phone: 408/496-5466 http://www.internex.net/~mdella From list-mgr@ISI.EDU Mon Oct 16 12:08:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14632>; Mon, 16 Oct 1995 13:16:15 -0700 Received: from maelstrom.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA14624>; Mon, 16 Oct 1995 13:16:11 -0700 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.6.10/8.6.6) id QAA11771; Mon, 16 Oct 1995 16:08:17 -0400 Message-Id: <199510162008.QAA11771@maelstrom.cc.mcgill.ca> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Yves Lepage <yves@CC.McGill.CA> Date: Mon, 16 Oct 95 16:08:15 -0400 To: Marilyn Hay <hay@ucs.ubc.ca> Subject: Re: repost:Tunnel request for Burnaby - Canada Cc: mbone-na, Christian Daudt <csd@microplex.com> Reply-To: yves@cc.mcgill.ca References: <"40221*hay@ucs.ubc.ca"@MHS> Hello, >This is across Canada via CA*net and back again via fONOROLA. An >mbone router at Seattle would be better suited for you. Or if FONOROLA doesn't mind, a link from onet or canet (mbone.canet.on.ca). Marylin, by the way, where do you get your feed these days? From the US? Regards, Yves From list-mgr@ISI.EDU Tue Oct 17 00:39:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22059>; Mon, 16 Oct 1995 15:40:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22023>; Mon, 16 Oct 1995 15:39:51 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA22012>; Mon, 16 Oct 1995 15:39:48 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id XAA22346; Mon, 16 Oct 1995 23:36:08 +0100 Message-Id: <199510162236.XAA22346@piraya.electrum.kth.se> To: jed@llnl.gov (James E. [Jed] Donnelley) Cc: mbone, rem-conf@es.net, e93_mda@it.kth.se Subject: Re: Multicasting with ATM - a concern In-Reply-To: Your message of "Mon, 16 Oct 1995 12:51:57 MST." <9510161951.AA00257@anduin.ocf.llnl.gov> Date: Mon, 16 Oct 1995 23:39:52 +0100 From: Magnus <e93_mda@it.kth.se> Hi! There is actually a working solution to multicast on ATM, it's available and working (beleive it or not). Fore has an nice form of multicast support in their geirs, they use their propritary SPANS and Fore IP to have a propper multicast. They have the switches makeing the forwarding in the same fashion as ordinary multicast routers but they do it with the ATM cells. SPANS and Fore IP actually performs the routing and forwarding mechanism in the same fashion as DVMRP does. So I guess that such support could be implemented into any switch that do propper point-to-multipoint forwarding in hardware. With propper I mean that it also could do things like changeing VP and VC of the header. I have some Fore documents describeing this, but I dont now if I can spread them, so ask some Fore people. They have a www server which should give some info. Magnus From list-mgr@ISI.EDU Mon Oct 16 11:08:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29672>; Mon, 16 Oct 1995 18:11:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29529>; Mon, 16 Oct 1995 18:08:20 -0700 Received: from anduin.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA29522>; Mon, 16 Oct 1995 18:08:19 -0700 Received: from by anduin.ocf.llnl.gov (4.1/SMI-4.0) id AB05826; Mon, 16 Oct 95 18:08:13 PDT Message-Id: <9510170108.AB05826@anduin.ocf.llnl.gov> X-Sender: jed@anduin.ocf.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Oct 1995 18:08:15 -0700 To: Magnus <e93_mda@it.kth.se> From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: Multicasting with ATM - a concern Cc: mbone >There is actually a working solution to multicast on ATM, it's available and >working (beleive it or not). Fore has a nice form of multicast support in >their gear, they use their propritary SPANS and Fore IP to have a propper >multicast. They have the switches makeing the forwarding in the same fashion as >ordinary multicast routers but they do it with the ATM cells. >SPANS and Fore IP actually performs the routing and forwarding mechanism in the >same fashion as DVMRP does. Interesting. Do you happen to know how cells from multiple sources are distinguished at receivers and broken into separate "streams" (i.e. "VC" endports)? From the receivers viewpoint are there "N" VCs, one for each sender? Do you know how requests to join and/or leave a multicast group are handled (most importantly, is it done locally or remotely/globally)? >So I guess that such support could be implemented into any switch that does >propper point-to-multipoint forwarding in hardware. With proper I mean that >it also could do things like changeing VP and VC of the header. I am interested in learning a bit more about the details, just to convince myself that 1. it can work, and that 2. people are on the path (sic) to make it work. >I have some Fore documents describing this, but I don't know if I can spread >them, so ask some Fore people. They have a www server which should give some >info. I'll take a crack at it. I have also probed on the ip-atm@matmos.hpl.hp.com e-mail list to see what I can dig up there. Thanks for the lead! --Jed http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Tue Oct 17 15:24:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06253>; Mon, 16 Oct 1995 22:01:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06154>; Mon, 16 Oct 1995 21:59:12 -0700 Received: from s.wipinfo.soft.net by venera.isi.edu (5.65c/5.61+local-22) id <AA06145>; Mon, 16 Oct 1995 21:59:06 -0700 Received: by s.wipinfo.soft.net (4.1/SMI-4.1) id AA18927; Tue, 17 Oct 95 10:32:25 IST Received: by tambora (4.1/SMI-4.1) id AA09367; Tue, 17 Oct 95 10:10:51 IST Received: by santoor.noname (4.1/SMI-4.1) id AA14717; Tue, 17 Oct 95 10:24:58+050 From: milton@wipinfo.soft.net (Milton Fernandes) Message-Id: <9510170524.AA14717@santoor.noname> Subject: To: mbone Date: Tue, 17 Oct 1995 10:24:57 +0500 (GMT+0500) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 21 subscribe cell-relay From list-mgr@ISI.EDU Mon Oct 16 20:06:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06625>; Mon, 16 Oct 1995 22:12:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06592>; Mon, 16 Oct 1995 22:08:31 -0700 Received: from gold.mv.net by venera.isi.edu (5.65c/5.61+local-22) id <AA06585>; Mon, 16 Oct 1995 22:08:30 -0700 Received: from [199.125.78.103] by gold.mv.net (8.6.10/mv(b)/mem-941101) id BAA03159 for <mbone@ISI.EDU>; Tue, 17 Oct 1995 01:08:27 -0400 Message-Id: <199510170508.BAA03159@gold.mv.net> X-Sender: pcmn-kr@gold.mv.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Oct 1995 01:06:58 -0500 To: mbone From: kris@pcmn.mv.com (Kris Marciniak) Subject: Unsubscribe Unsubscribe From list-mgr@ISI.EDU Mon Oct 16 20:06:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06721>; Mon, 16 Oct 1995 22:12:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06581>; Mon, 16 Oct 1995 22:08:27 -0700 Received: from gold.mv.net by venera.isi.edu (5.65c/5.61+local-22) id <AA06574>; Mon, 16 Oct 1995 22:08:26 -0700 Received: from [199.125.78.103] by gold.mv.net (8.6.10/mv(b)/mem-941101) id BAA03155 for <mbone@ISI.EDU>; Tue, 17 Oct 1995 01:08:22 -0400 Message-Id: <199510170508.BAA03155@gold.mv.net> X-Sender: pcmn-kr@gold.mv.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Oct 1995 01:06:53 -0500 To: mbone From: kris@pcmn.mv.com (Kris Marciniak) Subject: Unsubscribe Unsubscribe From list-mgr@ISI.EDU Tue Oct 17 12:37:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14265>; Tue, 17 Oct 1995 03:39:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14250>; Tue, 17 Oct 1995 03:38:02 -0700 Received: from kathy.ese-metz.fr by venera.isi.edu (5.65c/5.61+local-22) id <AA14243>; Tue, 17 Oct 1995 03:37:50 -0700 Received: (from mercier@localhost) by kathy.ese-metz.fr (8.7.1/8.7.1) id LAA00287 for mbone@ISI.EDU; Tue, 17 Oct 1995 11:37:37 +0100 Date: Tue, 17 Oct 1995 11:37:37 +0100 Message-Id: <199510171037.LAA00287@kathy.ese-metz.fr> From: mercier@esemetz.ese-metz.fr (Patrick.Mercier) To: mbone Subject: Unsubscribe Unsubscribe From list-mgr@ISI.EDU Tue Oct 17 03:47:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15388>; Tue, 17 Oct 1995 04:49:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15377>; Tue, 17 Oct 1995 04:48:18 -0700 Received: from portal (portal.netedge.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA15370>; Tue, 17 Oct 1995 04:48:15 -0700 Received: from NetEdge.COM by portal id AA17537; Tue, 17 Oct 95 07:47:06 EDT Received: from suicidesix.NetEdge.COM by NetEdge.COM id AA10811; Tue, 17 Oct 95 07:48:08 EDT Return-Path: <Tom_Pusateri@NetEdge.COM> Received: from localhost by suicidesix.NetEdge.COM (4.1/NECL-6.14) id AA01926; Tue, 17 Oct 95 07:47:04 EDT Message-Id: <9510171147.AA01926@NetEdge.COM> To: Magnus <e93_mda@it.kth.se> Cc: jed@llnl.gov (James E. [Jed] Donnelley), mbone Subject: Re: Multicasting with ATM - a concern In-Reply-To: Your message of "Mon, 16 Oct 1995 23:39:52 BST." <199510162236.XAA22346@piraya.electrum.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <1923.813930423.1@suicidesix.netedge.com> Date: Tue, 17 Oct 1995 07:47:03 -0400 From: Thomas Pusateri <pusateri@NetEdge.COM> In message <199510162236.XAA22346@piraya.electrum.kth.se> you write: >Hi! > >There is actually a working solution to multicast on ATM, it's available and >working (beleive it or not). Fore has an nice form of multicast support in >their geirs, they use their propritary SPANS and Fore IP to have a propper >multicast. Although this is a convenient method for control traffic, it does not provide a scalable solution for multicast datagram traffic since it is based on a single well known broadcast VC. Tom P.S. This shouldn't be on the rem-conf list and the mbone list both. In fact, future discussions should probably be moved to the IP over ATM list which is currently discussing the IP Multicast over ATM draft. [Un]Subscribe requests to majordomo@matmos.hpl.hp.com. Although, I do understand the goal of wanting to include more MBONE people in those discussions by posting here. From list-mgr@ISI.EDU Tue Oct 17 03:59:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15546>; Tue, 17 Oct 1995 05:02:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15511>; Tue, 17 Oct 1995 04:59:32 -0700 Received: from r02n07 (r02s07.cac.psu.edu) by venera.isi.edu (5.65c/5.61+local-22) id <AA15504>; Tue, 17 Oct 1995 04:59:31 -0700 Received: from pindarus (pindarus.ed.psu.edu [128.118.45.162]) by r02n07 (8.6.12/8.6.12) with SMTP id HAA20992 for <mbone@ISI.EDU>; Tue, 17 Oct 1995 07:59:16 -0400 Date: Tue, 17 Oct 1995 07:59:16 -0400 Message-Id: <199510171159.HAA20992@r02n07> X-Sender: kjh6@email.psu.edu X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: Ken Hoover <kjh6@psu.edu> Subject: bandwidth questions Greetings all. I would like to pose a question to this list that has been brought up by faculty members here who are interested in potentially using MBONE technology to deliver classroom instruction to public schools. Is a dedicated ISDN connection enough bandwith to carry on a conference via the MBONE? (an ISDN dialup is within the budget range of many school systems, a T1 or 56k link is not) Please e-mail responses. Thanks! - Ken Hoover -- Kenneth J. Hoover | "There is not one shred of evidence Network Coordinator | that life is serious." Penn State College of Education | - Joseph Campbell --== kjh6@psu.edu ** http://www.ed.psu.edu/people/kenh/kenh.htm ==-- From list-mgr@ISI.EDU Tue Oct 17 15:28:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17108>; Tue, 17 Oct 1995 06:29:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17052>; Tue, 17 Oct 1995 06:28:04 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA17045>; Tue, 17 Oct 1995 06:28:02 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id OAA15135; Tue, 17 Oct 1995 14:24:14 +0100 Message-Id: <199510171324.OAA15135@piraya.electrum.kth.se> To: Ken Hoover <kjh6@psu.edu> Cc: mbone, e93_mda@it.kth.se Subject: Re: bandwidth questions In-Reply-To: Your message of "Tue, 17 Oct 1995 07:59:16 -0400." <199510171159.HAA20992@r02n07> Date: Tue, 17 Oct 1995 14:28:06 +0100 From: Magnus <e93_mda@it.kth.se> Hi! If you want to run video, then I would say that the 128k ISDN is really not enough bandwidth. However, run your favorit apps and judge yourself if you think the kids would enjoy it. Magnus From list-mgr@ISI.EDU Tue Oct 17 15:31:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17204>; Tue, 17 Oct 1995 06:33:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17163>; Tue, 17 Oct 1995 06:31:42 -0700 Received: from danpost.uni-c.dk by venera.isi.edu (5.65c/5.61+local-22) id <AA17156>; Tue, 17 Oct 1995 06:31:39 -0700 Received: from mediator.uni-c.dk (recnba@mediator.uni-c.dk [130.225.243.33]) by danpost.uni-c.dk (8.6.4/8.6) with SMTP id OAA12137; Tue, 17 Oct 1995 14:31:37 +0100 Received: by mediator.uni-c.dk (5.0/SMI-SVR4) id AA00386; Tue, 17 Oct 1995 14:31:28 +0100 Date: Tue, 17 Oct 1995 14:31:28 +0100 (MET) From: Niels Baggesen <recnba@mediator.uni-c.dk> Reply-To: Niels.Baggesen@uni-c.dk To: Ken Hoover <kjh6@psu.edu> Cc: mbone Subject: Re: bandwidth questions In-Reply-To: <199510171159.HAA20992@r02n07> Message-Id: <Pine.SOL.3.91.951017142903.247A-100000@mediator.uni-c.dk> Return-Receipt-To: Niels.Baggesen@uni-c.dk Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 545 On Tue, 17 Oct 1995, Ken Hoover wrote: > Is a dedicated ISDN connection enough bandwith to carry on a conference > via the MBONE? (an ISDN dialup is within the budget range of many school > systems, a T1 or 56k link is not) Well, ISDN is not T1, but ISDN IS 56K (112K if you use both B-channels). Here in Europe it is even 64K or 128K. And yes, you can run a tunnel or two across that. Niels Baggesen, UNI-C, Olof Palmes Alle 38, DK-8200 Aarhus N, Denmark Email: Niels.Baggesen@uni-c.dk Tel: +45 86 78 44 44 Fax: +45 86 78 44 55 From list-mgr@ISI.EDU Tue Oct 17 15:19:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17007>; Tue, 17 Oct 1995 06:27:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16946>; Tue, 17 Oct 1995 06:23:22 -0700 Received: from mailsun.aber.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA16915>; Tue, 17 Oct 1995 06:21:39 -0700 Received: from mailhost.aber.ac.uk (actually host saturnbb.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Tue, 17 Oct 1995 14:20:24 +0100 To: Ken Hoover <kjh6@psu.edu> Cc: mbone, dap@aber.ac.uk, mice-nsc-wales@aber.ac.uk Subject: Re: bandwidth questions In-Reply-To: Your message of Tue, 17 Oct 1995 07:59:16 -0400. <199510171159.HAA20992@r02n07> Date: Tue, 17 Oct 1995 14:19:32 +0100 Message-Id: <25828.813935972@mailhost.aber.ac.uk> From: D E PRICE <dap@aber.ac.uk> Dear ken and All, Ken asks " Is a dedicated ISDN connection enough bandwith to carry on a conference via the MBONE?" The answer depends...... This summer we have, for demonstration purposes used ISDN (actually both channels and with compression switched on using non-multicast kit from SPIDER Systems) extended the Internet to several locations. We have then set up an extra mbone tunnel from our normal multicast router to run over the ISDN link and terminate in a SUN also running mrouted. From that machine we then dropped the true multicast onto the ether. We used both the mrouted machine and another as client machines in mbone connections. At one point we had around 6 sites connected with several issuing incoming video streams + audio (on ptt basis). Of course, we stuck to small(ish) windows, and kept the bit rate down to around 60 kbit/sec as the settings and had around 1 frame per second..... We intend to stage some `lab conditions' versions of this rig over the next few weeks and we will run more demos at the end of November from a multimedia event in Cardiff, wales, U.K. I am not saying, by the way, that the above configuration is the best. It has been suggested, and I certainly see merit in the suggestions, that one might run `mixers' on the audio streams for instance, on your ``main'' site before feeding onwards over the ISDN link. In my case, I have control of the Mbone at both ends of my ISDN link. Your attitude (and your providers attitude) to MBONE being fed from a commercial part of the Internet into your site via ISDN might be different..... Dave Price. MICE NSC for Wales, Telematics Group, Computer Science, University of Wales, Aberystwyth From list-mgr@ISI.EDU Mon Oct 16 23:57:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17800>; Tue, 17 Oct 1995 06:57:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17775>; Tue, 17 Oct 1995 06:57:27 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA17768>; Tue, 17 Oct 1995 06:57:26 -0700 Received: from [171.69.126.182] (sl-chagrin-12.cisco.com [171.69.126.198]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id GAA05658; Tue, 17 Oct 1995 06:57:17 -0700 X-Sender: fred@stilton.cisco.com Message-Id: <v02130508aca9657f016d@[171.69.126.182]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Oct 1995 06:57:22 -0700 To: Ken Hoover <kjh6@psu.edu> From: fred@cisco.com (Fred Baker) Subject: Re: bandwidth questions Cc: mbone At 7:59 AM 10/17/95, Ken Hoover wrote: >Is a dedicated ISDN connection enough bandwith to carry on a conference >via the MBONE? (an ISDN dialup is within the budget range of many school >systems, a T1 or 56k link is not) Audio and Whiteboard is fine. Don't even try video. But I'm of the opinion that you don't particularly need video for most conferencing. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "I know they'll sell it to me, I saw it at Networld+Interop" From list-mgr@ISI.EDU Tue Oct 17 06:40:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19555>; Tue, 17 Oct 1995 07:44:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19496>; Tue, 17 Oct 1995 07:41:52 -0700 Received: from VAX.HEC.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA19488>; Tue, 17 Oct 1995 07:41:49 -0700 Received: from @mailer.hec.ca (gingras_rolland_549) by VAX.HEC.CA (PMDF V5.0-5 #10107) id <01HWJLC19FKW0000ZZ@VAX.HEC.CA> for mbone@ISI.EDU; Tue, 17 Oct 1995 10:40:18 -0400 (EDT) Date: Tue, 17 Oct 1995 10:40:18 -0400 (EDT) Date-Warning: Date header was inserted by VAX.HEC.CA From: =?iso-8859-1?Q?Herv=E9?= Goyette <herve.goyette@hec.ca> Subject: unsubscribe X-Sender: p440@mailer.hec.ca To: mbone Message-Id: <01HWJLC1OYZM0000ZZ@VAX.HEC.CA> Mime-Version: 1.0 X-Mailer: Windows Eudora Light Version 1.5.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT unsubscribe From list-mgr@ISI.EDU Tue Oct 17 01:06:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20447>; Tue, 17 Oct 1995 08:09:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20353>; Tue, 17 Oct 1995 08:06:39 -0700 Received: from puli.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA20346>; Tue, 17 Oct 1995 08:06:38 -0700 Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with ESMTP id IAA23187; Tue, 17 Oct 1995 08:06:36 -0700 Message-Id: <199510171506.IAA23187@puli.cisco.com> To: Ken Hoover <kjh6@psu.edu> Cc: mbone Subject: bandwidth questions Date: Tue, 17 Oct 1995 08:06:36 -0700 From: "John M. Zwiebel" <jzwiebel@cisco.com> Fred should have mentioned that he is at the end of an ISDN link in Santa Barbara that connects to Cisco in San Jose. There are several other folks connected via ISDN through out the Bay area. We, of course, use PIM and so can avoid having to set up tunnels to forward the multicast packets to their destination. Audio and whiteboard work very well. Video works but it is necessary to restrict the video bandwidth usage considerably, especially when you have several folks transmitting video. If you would be happy with very slow changes in the picture, it could work, two channels are required. If it was a "slide show" presentation, then you may even be happy with the results. z > > At 7:59 AM 10/17/95, Ken Hoover wrote: > >Is a dedicated ISDN connection enough bandwith to carry on a conference > >via the MBONE? (an ISDN dialup is within the budget range of many school > >systems, a T1 or 56k link is not) > > Audio and Whiteboard is fine. Don't even try video. But I'm of the opinion > that you don't particularly need video for most conferencing. From list-mgr@ISI.EDU Tue Oct 17 01:49:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22516>; Tue, 17 Oct 1995 08:53:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22226>; Tue, 17 Oct 1995 08:49:51 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA22219>; Tue, 17 Oct 1995 08:49:50 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14835(2)>; Tue, 17 Oct 1995 08:49:37 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 17 Oct 1995 08:49:24 -0700 To: "John M. Zwiebel" <jzwiebel@cisco.com> Cc: mbone, deering@parc.xerox.com Subject: Re: bandwidth questions In-Reply-To: jzwiebel's message of Tue, 17 Oct 95 08:06:36 -0800. <199510171506.IAA23187@puli.cisco.com> Date: Tue, 17 Oct 1995 08:49:15 PDT Sender: Steve Deering <deering@parc.xerox.com> From: Steve Deering <deering@parc.xerox.com> Message-Id: <95Oct17.084924pdt.75270@digit.parc.xerox.com> > We, of course, use PIM and so can avoid having to set up tunnels... Brilliant! You've managed to turn a weakness of cisco's PIM (its inability to support multicast tunneling) into a benefit. You have a great future in marketing. Please note that DVMRP, MOSPF, and CBT do not require the setting up of tunnels either. Some of them *allow* you to set up tunnels as an alternative to waiting till all routers along a path support multicast routing. Steve From list-mgr@ISI.EDU Tue Oct 17 04:31:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01449>; Tue, 17 Oct 1995 11:33:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01401>; Tue, 17 Oct 1995 11:32:05 -0700 Received: from puli.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA01394>; Tue, 17 Oct 1995 11:32:04 -0700 Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with ESMTP id LAA03578; Tue, 17 Oct 1995 11:31:33 -0700 Message-Id: <199510171831.LAA03578@puli.cisco.com> To: Steve Deering <deering@parc.xerox.com> Cc: mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Tue, 17 Oct 1995 08:49:15 PDT." <95Oct17.084924pdt.75270@digit.parc.xerox.com> Date: Tue, 17 Oct 1995 11:31:33 -0700 From: "John M. Zwiebel" <jzwiebel@cisco.com> > > We, of course, use PIM and so can avoid having to set up tunnels... > > Brilliant! You've managed to turn a weakness of cisco's PIM (its inability > to support multicast tunneling) into a benefit. You have a great future in > marketing. Thank you. In another life I did do marketing, what do you want to know about linear encoders? > > Please note that DVMRP, MOSPF, and CBT do not require the setting up of > tunnels either. Some of them *allow* you to set up tunnels as an alternative > to waiting till all routers along a path support multicast routing. Correct, I thought we were discussing only an ISDN link and my purpose was to provide an example of my experience. I would like to point out that it is possible to run PIM over a GRE tunnel although it is true that there is no specific thing called a PIM tunnel. GRE tunnels then provide the same alternative, not all the routers along a path have to support multicast routing. I guess it is also necessary to say that cisco does support DVMRP tunnels just so there's no misunderstanding. z From list-mgr@ISI.EDU Tue Oct 17 20:59:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03013>; Tue, 17 Oct 1995 12:02:19 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02991>; Tue, 17 Oct 1995 12:01:02 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-22) id <AA02976>; Tue, 17 Oct 1995 12:00:44 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id TAA22058 (8.6.12/7.4g-FAU);; Tue, 17 Oct 1995 19:59:48 +0100 From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de> Message-Id: <199510171859.TAA22058@faui40.informatik.uni-erlangen.de> Subject: Re: bandwidth questions To: deering@parc.xerox.com (Steve Deering) Date: Tue, 17 Oct 1995 19:59:45 +0100 (MET) Cc: jzwiebel@cisco.com, mbone, deering@parc.xerox.com In-Reply-To: <95Oct17.084924pdt.75270@digit.parc.xerox.com> from "Steve Deering" at Oct 17, 95 08:49:15 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 628 > > We, of course, use PIM and so can avoid having to set up tunnels... > > Brilliant! You've managed to turn a weakness of cisco's PIM (its inability > to support multicast tunneling) into a benefit. You have a great future in > marketing. > > Please note that DVMRP, MOSPF, and CBT do not require the setting up of > tunnels either. Some of them *allow* you to set up tunnels as an alternative > to waiting till all routers along a path support multicast routing. I don't get the point ? What's PIM got to do with tunnels ? Surely you can run PIM over tunnels too, as you can run any other routing protocl over tunnels. From list-mgr@ISI.EDU Tue Oct 17 23:35:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05451>; Tue, 17 Oct 1995 12:37:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05272>; Tue, 17 Oct 1995 12:35:21 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA05261>; Tue, 17 Oct 1995 12:35:16 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id VAA02746; Tue, 17 Oct 1995 21:35:01 +0200 Date: Tue, 17 Oct 1995 21:35:01 +0200 Message-Id: <199510171935.VAA02746@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de> Cc: deering@parc.xerox.com (Steve Deering), jzwiebel@cisco.com, mbone Subject: Re: bandwidth questions In-Reply-To: <199510171859.TAA22058@faui40.informatik.uni-erlangen.de> References: <95Oct17.084924pdt.75270@digit.parc.xerox.com> <199510171859.TAA22058@faui40.informatik.uni-erlangen.de> Toerless Eckert writes: > > > > Please note that DVMRP, MOSPF, and CBT do not require the setting up of > > tunnels either. Some of them *allow* you to set up tunnels as an alternative > > to waiting till all routers along a path support multicast routing. > > I don't get the point ? What's PIM got to do with tunnels ? Surely you > can run PIM over tunnels too, as you can run any other routing protocl > over tunnels. > More than anything this is religious. People is likely to 1) blame you for trying 2) blame you for not doing things the way you would like 3) blame you for your faults one year after the issue has been resolved 4) blame you for your faults two years after the issue has been resolved 5) ignore you telling them that the issue has been resolved 6) be reluctant to find out themselves 7) be non-co-operative on working towards mutual benefit ...but that's what keeps life so interesting. Pete From list-mgr@ISI.EDU Tue Oct 17 23:38:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05607>; Tue, 17 Oct 1995 12:40:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05528>; Tue, 17 Oct 1995 12:38:33 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA05519>; Tue, 17 Oct 1995 12:38:31 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id VAA02749; Tue, 17 Oct 1995 21:38:22 +0200 Date: Tue, 17 Oct 1995 21:38:22 +0200 Message-Id: <199510171938.VAA02749@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: "John M. Zwiebel" <jzwiebel@cisco.com> Cc: Steve Deering <deering@parc.xerox.com>, mbone Subject: Re: bandwidth questions In-Reply-To: <199510171831.LAA03578@puli.cisco.com> References: <95Oct17.084924pdt.75270@digit.parc.xerox.com> <199510171831.LAA03578@puli.cisco.com> John M. Zwiebel writes: > > Thank you. In another life I did do marketing, what do you want to know > about linear encoders? > Ah, er, um. Do they make coffee? :-) > I would like to point out that it is possible to run PIM over a GRE tunnel > although it is true that there is no specific thing called a PIM tunnel. > GRE tunnels then provide the same alternative, not all the routers along a > path have to support multicast routing. I guess it is also necessary to say > that cisco does support DVMRP tunnels just so there's no misunderstanding. > I can report that our multicast traffic has been flowing with dense-mode PIM, over GRE/IP tunnel for months (almost a year now). I don't see a problem here, so would you (Steve) please be so kind and point me what cannot be done and what operational concerns it's likely to cause? Pete From list-mgr@ISI.EDU Tue Oct 17 22:07:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07117>; Tue, 17 Oct 1995 13:08:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06944>; Tue, 17 Oct 1995 13:07:22 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-22) id <AA06931>; Tue, 17 Oct 1995 13:07:15 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id VAA22418 (8.6.12/7.4g-FAU);; Tue, 17 Oct 1995 21:07:05 +0100 From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de> Message-Id: <199510172007.VAA22418@faui40.informatik.uni-erlangen.de> Subject: Re: bandwidth questions To: pete@sms.fi (Petri Helenius) Date: Tue, 17 Oct 1995 21:07:04 +0100 (MET) Cc: jzwiebel@cisco.com, deering@parc.xerox.com, mbone In-Reply-To: <199510171938.VAA02749@silver.sms.fi> from "Petri Helenius" at Oct 17, 95 09:38:22 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 510 > I can report that our multicast traffic has been flowing with dense-mode > PIM, over GRE/IP tunnel for months (almost a year now). I don't see a > problem here, so would you (Steve) please be so kind and point me what > cannot be done and what operational concerns it's likely to cause? Yes, actually, there is a big problem with GRE/IP tunnels. mrouted does not support them. I strongly suggest the maintainers of mrouted to implement them *grin* (is this a correct form of counterfeit attack ?) Toerless From list-mgr@ISI.EDU Tue Oct 17 06:52:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10015>; Tue, 17 Oct 1995 13:54:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09941>; Tue, 17 Oct 1995 13:53:33 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA09934>; Tue, 17 Oct 1995 13:53:32 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14916(4)>; Tue, 17 Oct 1995 13:53:01 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 17 Oct 1995 13:52:46 -0700 To: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de> Cc: jzwiebel@cisco.com, mbone, deering@parc.xerox.com Subject: Re: bandwidth questions In-Reply-To: Toerless.Eckert's message of Tue, 17 Oct 95 11:59:45 -0800. <199510171859.TAA22058@faui40.informatik.uni-erlangen.de> Date: Tue, 17 Oct 1995 13:52:37 PDT Sender: Steve Deering <deering@parc.xerox.com> From: Steve Deering <deering@parc.xerox.com> Message-Id: <95Oct17.135246pdt.75270@digit.parc.xerox.com> Toerless, > I don't get the point ? What's PIM got to do with tunnels ? Nothing. That's the point. John's statement ("We, of course, use PIM and so can avoid having to set up tunnels...") implies that there is something special about PIM that eliminates the need to set up tunnels. The need for tunnels has nothing at all to do with what multicast routing protocol you are running. If the routers on each end of an ISDN link speak DVMRP or MOSPF or CBT, they should not require the setting up of a tunnel to route across that link, any more than PIM does. > Surely you can run PIM over tunnels too, as you can run any other routing > protocol over tunnels. Of course, but it is difficult/unnatural to run PIM over tunnels that are intended to carry *multicast traffic only* -- my statement was that cisco's PIM doesn't support *multicast* tunneling (i.e., multicast only) -- since PIM does not run its own topology-discovery protocol but rather relies on information that the unicast routing protocol(s) provide. That is, for PIM to be able to use the tunnel, unicast routing has to see the tunnel, and therefore unicast traffic can/will also flow over the tunnel. With PIM, the unicast and multicast topologies are assumed/required to be identical. With DVMRP, they may be different. That ability for the two topologies to differ has been essential for incremental deployment of multicast routing. The loss of that ability in PIM is at the root of most of the routing meltdowns suffered by the MBone. Note that I qualified the above paragraph by saying that it is "difficult/ unnatural", rather than "impossible" to do multicast-only tunneling with PIM. In theory (and possibly in practice in cisco's implementation -- you'll have to ask cisco), you could run a separate instance of a unicast routing protocol for the purpose of producing a routing table for the use of PIM and multicast traffic only, independent of the regular unicast routing table. You would configure the tunnels to be visible to the "multicast-only" instance of the unicast routing protocol. I say this is unnatural, because the main (only?) selling point of Dense-Mode PIM is that it *doesn't* maintain a separate routing table or run a separate topology-discovery protocol. (Sparse-Mode PIM has the same property, but has value beyond that, in the area of scalability of multicast routing over very large-scale global internets.) Steve From list-mgr@ISI.EDU Tue Oct 17 23:28:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11865>; Tue, 17 Oct 1995 14:30:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11674>; Tue, 17 Oct 1995 14:28:58 -0700 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-22) id <AA11650>; Tue, 17 Oct 1995 14:28:50 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id WAA22868 (8.6.12/7.4g-FAU);; Tue, 17 Oct 1995 22:28:37 +0100 From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de> Message-Id: <199510172128.WAA22868@faui40.informatik.uni-erlangen.de> Subject: Re: bandwidth questions To: deering@parc.xerox.com (Steve Deering) Date: Tue, 17 Oct 1995 22:28:33 +0100 (MET) Cc: Toerless.Eckert@informatik.uni-erlangen.de, jzwiebel@cisco.com, mbone, deering@parc.xerox.com In-Reply-To: <95Oct17.135246pdt.75270@digit.parc.xerox.com> from "Steve Deering" at Oct 17, 95 01:52:37 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1160 > Nothing. That's the point.... Point taken. Thanks for the explanation. As what is unnatural for PIM is a good question. I understand that dense-mode pim is basically nothing more than DVMRP without the routing protocol and as such it offers the implicit advantage of freedom in choosing an appropriate routing protocol. This only implies an aligned unicast and multicast routing if you take the implementors reality into account which makes it much easier to use the unicast routing table instead of running a separate routing process for multicast traffic. [ I guess i like aligned multicast/unicast routing unless my network topology demands otherwise (for fully meshed NBMA networks for example). ] And as for the primary reason for all these breakdowns: The main reason is that one should first try to understand multicasting before administrating it. And i fear that this is not always the case. Mrouted is just simpler than a cisco router so it's not that prune to operational errors. On the other hand mrouted is the main reason why the mbone routing table is full of subnet multicast routing entries, of which many could well be summarized. From list-mgr@ISI.EDU Wed Oct 18 01:53:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13602>; Tue, 17 Oct 1995 14:54:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13524>; Tue, 17 Oct 1995 14:53:27 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA13513>; Tue, 17 Oct 1995 14:53:24 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id XAA03215; Tue, 17 Oct 1995 23:53:14 +0200 Date: Tue, 17 Oct 1995 23:53:14 +0200 Message-Id: <199510172153.XAA03215@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Steve Deering <deering@parc.xerox.com> Cc: mbone Subject: Re: bandwidth questions In-Reply-To: <95Oct17.135246pdt.75270@digit.parc.xerox.com> References: <199510171859.TAA22058@faui40.informatik.uni-erlangen.de> <95Oct17.135246pdt.75270@digit.parc.xerox.com> Steve Deering writes: > > Of course, but it is difficult/unnatural to run PIM over tunnels that are > intended to carry *multicast traffic only* -- my statement was that cisco's > PIM doesn't support *multicast* tunneling (i.e., multicast only) -- since > PIM does not run its own topology-discovery protocol but rather relies on > information that the unicast routing protocol(s) provide. That is, for PIM > to be able to use the tunnel, unicast routing has to see the tunnel, and > therefore unicast traffic can/will also flow over the tunnel. With PIM, the > unicast and multicast topologies are assumed/required to be identical. With > DVMRP, they may be different. That ability for the two topologies to differ > has been essential for incremental deployment of multicast routing. The loss > of that ability in PIM is at the root of most of the routing meltdowns > suffered by the MBone. > I think the meltdowns are because somebody put in an access-list permitting everything in unicast routing to be distributed to DVMRP for which there is the most widespread implementation in mrouted which cannot handle the load in most cases and cannot generate default-routes to leaf sites so that the load wouldn't spread all over. > Note that I qualified the above paragraph by saying that it is "difficult/ > unnatural", rather than "impossible" to do multicast-only tunneling with > PIM. In theory (and possibly in practice in cisco's implementation -- you'll > have to ask cisco), you could run a separate instance of a unicast routing > protocol for the purpose of producing a routing table for the use of PIM > and multicast traffic only, independent of the regular unicast routing table. Or you could just configure a static multicast route to override the unicast topology at the point it differs (most likely your boundary router) and another at the other endpoint of the tunnel. Doesn't sound too complicated to me. I've been a happy camper ever since. Of course, Cisco didn't figure this out in the first run. Nobody does. Cisco's presently at their third release with multicast code and it's steadily becoming more and more feature-rich and more useful. For mrouted it took more than three times to get it even to prune with another mrouted. And it took a lot more to do classless, default-routing, etc. Of course you do have the _OPTION_ of running DVMRP for your unicast routing protocol for multicast, again, if you want to. With mrouted you are stuck with a single-no-options-track. > You would configure the tunnels to be visible to the "multicast-only" > instance of the unicast routing protocol. I say this is unnatural, because > the main (only?) selling point of Dense-Mode PIM is that it *doesn't* Dense-mode PIM generates state only at the time there is a sender. It does not keep states for nothing like DVMRP. (routing table) > maintain a separate routing table or run a separate topology-discovery > protocol. (Sparse-Mode PIM has the same property, but has value beyond that, > in the area of scalability of multicast routing over very large-scale global > internets.) > Exept that the issues on sparse-mode RP selection aren't too clear just of yet. Pete From list-mgr@ISI.EDU Tue Oct 17 10:18:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21046>; Tue, 17 Oct 1995 17:24:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20885>; Tue, 17 Oct 1995 17:22:52 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA20876>; Tue, 17 Oct 1995 17:22:50 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15389(4)>; Tue, 17 Oct 1995 17:19:38 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 17 Oct 1995 17:18:59 -0700 To: mbone Cc: deering@parc.xerox.com Subject: Re: bandwidth questions Date: Tue, 17 Oct 1995 17:18:58 PDT Sender: Steve Deering <deering@parc.xerox.com> From: Steve Deering <deering@parc.xerox.com> Message-Id: <95Oct17.171859pdt.75270@digit.parc.xerox.com> Pete, > I think the meltdowns are because somebody put in an access-list permitting > everything in unicast routing to be distributed to DVMRP for which there is > the most widespread implementation in mrouted which cannot handle the load > in most cases and cannot generate default-routes to leaf sites so that the > load wouldn't spread all over. There are few routers in the world, unicast or multicast, that can handle routing tables with 30,000 entries. The injection of tens of thousands of non-multicast routes into the MBone DVMRP routing is wrong, and evidently far too easily accomplished by accident with cisco's PIM implementation. Support for default routes in the MBone backbone would not have alleviated the problem -- default helps *in* the leaf domains themselves, *not* in the backbone that routes between the leaf domains. > Or you could just configure a static multicast route to override the unicast > topology at the point it differs (most likely your boundary router) and > another at the other endpoint of the tunnel. Doesn't sound too complicated > to me. Sure, if you're content to use static routes and restricted topologies, you can make anything work. > I've been a happy camper ever since. Of course, Cisco didn't figure > this out in the first run. Nobody does. Cisco's presently at their third > release with multicast code and it's steadily becoming more and more > feature-rich and more useful. For mrouted it took more than three times to > get it even to prune with another mrouted. And it took a lot more to > do classless, default-routing, etc. We were talking about tunneling capability. I am well aware of the many weaknesses and shortcomings of mrouted -- it is a piece of software written in a short period of time by a graduate student who didn't know nearly as much about routing as he does now, and until recently it has been maintained and evolved by volunteers in their spare time and by summer interns whose jobs came to an end not long after they got up to speed on the code base. MRouted is being used in an environment that is far larger and more volatile than what it was designed for, as a stop-gap until the commercial alternatives can take over the job. I am delighted that cisco is finally catching up to where Proteon and Alantec were a couple years ago, and that Bay and 3Com are also shipping or about to ship multicast routing code. I am not surprised, nor am I embarassed, that cisco's implementation has evolved faster or become more "feature-rich" than mrouted -- after all, that's what that organization specializes in. Also, whatever they happen to be learning as they go along, they did understand the consequences of the interaction of their PIM implementation with the DVMRP MBone long before they shipped PIM product (this includes not just the leaking-non- multicast-routes problem, but also their failure to sort their DVMRP route report messages into the order required by mrouted, an earlier cause of cisco-induced MBone failure), and they basically chose to dismiss those consequences as unimportant, as far as I can tell. But all of that has nothing to do with the relative merits of ways of doing tunneling. > Dense-mode PIM generates state only at the time there is a sender. > It does not keep states for nothing like DVMRP. (routing table) Since DVMRP is being used predominantly over topologies that include multicast-only tunnels, the routing state it keeps is not for nothing; it is so that it can do correct, dynamic routing. If you don't need multicast tunnels, by all means go ahead and use PIM -- just don't inject bogus routes into the MBone, and don't claim that PIM's lack of support for multicast tunnels is a feature. > Exept that the issues on sparse-mode RP selection aren't too clear just of > yet. Yep. There is still work to be done on Sparse-Mode PIM. That's OK, because the scaling aspects that Sparse-Mode PIM addresses are not those that are the most urgent to solve. Steve From list-mgr@ISI.EDU Wed Oct 18 13:22:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02451>; Tue, 17 Oct 1995 23:42:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02309>; Tue, 17 Oct 1995 23:41:11 -0700 Received: from vx23.cc.monash.edu.au by venera.isi.edu (5.65c/5.61+local-22) id <AA02302>; Tue, 17 Oct 1995 23:41:01 -0700 Received: from basil.eng.monash.edu.au ("port 4768"@basil.eng.monash.edu.au) by vaxc.cc.monash.edu.au (PMDF V5.0-4 #8933) id <01HWL5AFS65SI234AP@vaxc.cc.monash.edu.au> for mbone@isi.edu; Wed, 18 Oct 1995 13:22:26 +1000 Received: from BASIL/SpoolDir by basil.eng.monash.edu.au (Mercury 1.20); Wed, 18 Oct 1995 13:22:31 -1000 Received: from SpoolDir by BASIL (Mercury 1.20); Wed, 18 Oct 1995 13:22:27 -1000 Date: Wed, 18 Oct 1995 13:22:20 GMT+1100 From: JOHN PSALLIDAS <YANNIS@basil.eng.monash.edu.au> Subject: PIM question.. To: mbone Message-Id: <22CAC180343@basil.eng.monash.edu.au> X-Mailer: Pegasus Mail v3.22 Content-Transfer-Encoding: 7BIT Priority: normal Hello :-) I have a query regarding PIM/DVMRP inter-operation. It is based on a simple, hypothetical networking scenario. Assumption 1/4 Assume that a campus network uses a 100 Mbps FDDI backbone. A number of PIM capable Cisco routers are attached to it and are used to distribute the data to the various departments. One of the routers (router A) is dedicated to accessing the rest of the world ie. the Internet. Assumption 2/4 Assume, for making things simple, that behind each router (except router A) there is an Ethernet type LAN segment which has multicast capable hosts attached to it. This LAN segment is not connected to any other networks. Assumption 3/4 Assume that there is an MBONE tunnel provided by an mrouted machine running DVMRP outside the campus. Assumption 4/4 Assume that PIM-Dense-Mode is to be used amongst the Cisco campus routers to route multicast packets and that the external to the campus network mrouted is feeding router A. The following describes the network scenario. (hope it comes out ok on your mail reader) Ethernet ----------- | +-----+ |Cisco| +-----+ router A | +---- --+ +-------+ +----+ +-----+ | |mrouted|---| Cisco |----|FDDI|---- |Cisco|---| +-------+ +-------+ +----+ +-----+ | | +-----+ |Cisco| +-----+ | --------- Ethernet I would like to know if the following is currently possible : Router A de-encapsulates the tunnelled multicast packets before it releases them onto the FDDI ring. In other words there is only one copy of the multicast packets on the FDDI ring. (Question -in tune with this networking example- : is there support for multicasting over FDDI simmilar to Ethernet ?) The other routers pick the de-encapsulated multicast packets from the FDDI ring and "RPF" them to the adjacent networks if there are workstations attached to these networks and have joined the multicast group to which the multicast data is addressed to. If a workstation attached to one of the Ethernet based LAN segment located behind one of the routers (excluding router A) is sending multicast packets to address G, its adjacent router will deliver one copy only of these packets on the FDDI ring and the other routers in turn will "RPF" them to their adjacent LAN segments (assuming that are host listening to the same multicast address G). Router A will perform the PIM/DVMRP translation and will tunnel the multicast packets to the external mrouted. I hope this is not to much. :-) Thanks in advance. --------------------------------------------------- John Psallidas Postgraduate student. Monash Uni., Melbourne, Australia. E-mail : yannis@basil.eng.monash.edu.au Phone : (03) 9055350 /-\_/-\ / \ \_/---\*_/ \/ From list-mgr@ISI.EDU Tue Oct 17 19:09:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03217>; Wed, 18 Oct 1995 00:15:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03176>; Wed, 18 Oct 1995 00:13:59 -0700 Received: from labrim.mty.itesm.mx by venera.isi.edu (5.65c/5.61+local-22) id <AA03169>; Wed, 18 Oct 1995 00:13:56 -0700 Received: from klee.mty.itesm.mx by labrim.mty.itesm.mx (5.x/SMI-SVR4) id AA06736; Wed, 18 Oct 1995 01:12:32 -0600 Received: by klee.mty.itesm.mx (5.x/SMI-SVR4) id AA01497; Wed, 18 Oct 1995 01:09:19 -0600 Date: Wed, 18 Oct 1995 01:09:19 -0600 From: morona@labrim.mty.itesm.mx (Monica Yolanda Orona Gonzalez) Message-Id: <9510180709.AA01497@klee.mty.itesm.mx> To: mbone X-Sun-Charset: US-ASCII Hi!.. I would like have more iformation abour IP Multicast... I am working with digital video's compession and transmision. In real time. Greetings Thanks From list-mgr@ISI.EDU Tue Oct 17 22:57:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08694>; Wed, 18 Oct 1995 06:02:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08634>; Wed, 18 Oct 1995 05:57:58 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA08626>; Wed, 18 Oct 1995 05:57:56 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14615(1)>; Wed, 18 Oct 1995 05:57:48 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 18 Oct 1995 05:57:39 -0700 To: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de> Cc: mbone, deering@parc.xerox.com Subject: Re: bandwidth questions In-Reply-To: Toerless.Eckert's message of Tue, 17 Oct 95 14:28:33 -0800. <199510172128.WAA22868@faui40.informatik.uni-erlangen.de> Date: Wed, 18 Oct 1995 05:57:29 PDT Sender: Steve Deering <deering@parc.xerox.com> From: Steve Deering <deering@parc.xerox.com> Message-Id: <95Oct18.055739pdt.75270@digit.parc.xerox.com> Toerless, One more thing. You said: > ...mrouted is the main reason why the mbone routing table is full > of subnet multicast routing entries, of which many could well be summarized. We looked at that a year ago and computed that, at that time, collapsing all the MBone-advertised subnets into their enclosing network numbers only reduced the table size to about 75% of its unaggregated size. That wasn't too surprising, since the nature of the MBone has mostly been a small number of subnets at a large number of sites. (We didn't look at aggregating the routes into their enclosing CIDR supernets, but I don't think that would have changed the result significantly.) Obviously, that nature is changing as sites deploy multicast routing to more of their internal subnets. Some sites are doing that by using PIM or MOSPF internally, which do aggregate their subnets when passing them to DVMRP, which is Good. We hope to have multiple-domain support in mrouted soon too. But note that there is the basic problem in the current Internet that maximally aggregating subnets into longer prefixes still leaves you with a backbone routing table size of 30,000 entries. So, aggregating subnets into CIDR prefixes does not solve the backbone routing table size problem. (We are working on support in mrouted for aggregating into domain IDs which are a separate numbering space from IP address prefixes, which should allow us to cope with that problem.) Steve From list-mgr@ISI.EDU Tue Oct 17 23:29:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09187>; Wed, 18 Oct 1995 06:32:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09118>; Wed, 18 Oct 1995 06:29:37 -0700 Received: from puli.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA09111>; Wed, 18 Oct 1995 06:29:34 -0700 Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with ESMTP id GAA27686; Wed, 18 Oct 1995 06:29:22 -0700 Message-Id: <199510181329.GAA27686@puli.cisco.com> To: JOHN PSALLIDAS <YANNIS@basil.eng.monash.edu.au> Cc: mbone Subject: Re: PIM question.. In-Reply-To: Your message of "Wed, 18 Oct 1995 13:22:20 +1100." <22CAC180343@basil.eng.monash.edu.au> Date: Wed, 18 Oct 1995 06:29:22 -0700 From: "John M. Zwiebel" <jzwiebel@cisco.com> John: Your description is correct. z > > Hello :-) > > I have a query regarding PIM/DVMRP inter-operation. It is > based on a simple, hypothetical networking scenario. > > Assumption 1/4 > Assume that a campus network uses a 100 Mbps FDDI backbone. > A number of PIM capable Cisco routers are attached to it > and are used to distribute the data to the various > departments. One of the routers (router A) is dedicated to > accessing the rest of the world ie. the Internet. > > Assumption 2/4 > Assume, for making things simple, that behind each router > (except router A) there is an Ethernet type LAN segment > which has multicast capable hosts attached to it. This LAN > segment is not connected to any other networks. > > Assumption 3/4 > Assume that there is an MBONE tunnel provided by an mrouted > machine running DVMRP outside the campus. > > Assumption 4/4 > Assume that PIM-Dense-Mode is to be used amongst the Cisco > campus routers to route multicast packets and that the > external to the campus network mrouted is feeding router A. > > The following describes the network scenario. (hope it > comes out ok on your mail reader) > > Ethernet > ----------- > | > +-----+ > |Cisco| > +-----+ > router A | > +---- --+ +-------+ +----+ +-----+ | > |mrouted|---| Cisco |----|FDDI|---- |Cisco|---| > +-------+ +-------+ +----+ +-----+ | > | > +-----+ > |Cisco| > +-----+ > | > --------- > Ethernet > > > > I would like to know if the following is currently possible > : > > Router A de-encapsulates the tunnelled multicast packets > before it releases them onto the FDDI ring. In other words > there is only one copy of the multicast packets on the FDDI > ring. (Question -in tune with this networking example- : is > there support for multicasting over FDDI simmilar to > Ethernet ?) The other routers pick the de-encapsulated > multicast packets from the FDDI ring and "RPF" them to the > adjacent networks if there are workstations attached to > these networks and have joined the multicast group to which > the multicast data is addressed to. > If a workstation attached to one of the Ethernet based > LAN segment located behind one of the routers (excluding > router A) is sending multicast packets to address G, its > adjacent router will deliver one copy only of these packets > on the FDDI ring and the other routers in turn will "RPF" > them to their adjacent LAN segments (assuming that are host > listening to the same multicast address G). Router A will > perform the PIM/DVMRP translation and will tunnel the > multicast packets to the external mrouted. > > > I hope this is not to much. :-) > > Thanks in advance. > --------------------------------------------------- > John Psallidas > Postgraduate student. > Monash Uni., Melbourne, Australia. > E-mail : yannis@basil.eng.monash.edu.au > Phone : (03) 9055350 > > > /-\_/-\ > / \ > \_/---\*_/ > \/ From list-mgr@ISI.EDU Tue Oct 17 23:39:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09361>; Wed, 18 Oct 1995 06:41:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09313>; Wed, 18 Oct 1995 06:39:37 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA09303>; Wed, 18 Oct 1995 06:39:35 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14748(3)>; Wed, 18 Oct 1995 06:39:20 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 18 Oct 1995 06:39:11 -0700 To: JOHN PSALLIDAS <YANNIS@basil.eng.monash.edu.au> Cc: mbone, deering@parc.xerox.com Subject: Re: PIM question.. In-Reply-To: YANNIS's message of Wed, 18 Oct 95 06:22:20 -0800. <22CAC180343@basil.eng.monash.edu.au> Date: Wed, 18 Oct 1995 06:39:03 PDT Sender: Steve Deering <deering@parc.xerox.com> From: Steve Deering <deering@parc.xerox.com> Message-Id: <95Oct18.063911pdt.75270@digit.parc.xerox.com> > I have a query regarding PIM/DVMRP inter-operation. It is > based on a simple, hypothetical networking scenario. John, A definitive answer will have to come from cisco, but yes, the scenario as you described it should work fine. Note further that, if there are no group members of G on any of the Ethernets, a packet arriving at router A from the mrouted machine, destined to G, will be suppressed from going over the FDDI, and if you run the latest cisco code, it will result in a prune message back to the mrouted machine, so subsequent packets won't even arrive over the tunnel. Steve From list-mgr@ISI.EDU Wed Oct 18 02:07:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15244>; Wed, 18 Oct 1995 09:07:27 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15210>; Wed, 18 Oct 1995 09:06:36 -0700 Received: from ECE.ORST.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA15203>; Wed, 18 Oct 1995 09:06:34 -0700 Received: from tongu.ECE.ORST.EDU by ECE.ORST.EDU with SMTP (1.38.193.4/16.2) id AA13135; Wed, 18 Oct 1995 09:06:30 -0700 From: Tim Heldt <heldt@ECE.ORST.EDU> Received: by tongu.ece.orst.edu (1.38.193.4/HP-Client) id AA12555; Wed, 18 Oct 1995 09:07:03 -0700 Message-Id: <9510181607.AA12555@tongu.ece.orst.edu> Subject: HPUX question... To: mbone Date: Wed, 18 Oct 1995 09:07:02 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 983 Hi all -- I hate to ask this question but I just couldn't find any information on the net so here it goes... I am looking for kernel patches for HPUX 9.05 or greater for HP 9000/700s to run multicasting on. I am also looking for mrouted binaries. You can either respond to the mbone group or to me. I will broadcast my results to this group. Hopefully this will get added to an FAQ sometime... Thanks in advance, Tim -- +--------------------------------------------------+ | Tim Heldt heldt@ece.orst.edu | | | | Electrical & Computer Engineering | | Oregon State University | | Corvallis, OR 97331 | | | | Voice: (503) 737-2975 | | Fax: (503) 737-1300 | +--------------------------------------------------+ From list-mgr@ISI.EDU Wed Oct 18 02:45:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17305>; Wed, 18 Oct 1995 09:48:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17248>; Wed, 18 Oct 1995 09:46:55 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA17241>; Wed, 18 Oct 1995 09:46:54 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id JAA04573; Wed, 18 Oct 1995 09:45:35 -0700 Date: Wed, 18 Oct 1995 09:45:35 -0700 From: Dino Farinacci <dino@cisco.com> Message-Id: <199510181645.JAA04573@stilton.cisco.com> To: deering@parc.xerox.com Cc: jzwiebel@cisco.com, mbone, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Tue, 17 Oct 1995 08:49:15 PDT <95Oct17.084924pdt.75270@digit.parc.xerox.com> Subject: bandwidth questions >> Brilliant! You've managed to turn a weakness of cisco's PIM (its inability >> to support multicast tunneling) into a benefit. You have a great future in >> marketing. Hey Steve, tell me what you think the weaknesses of cisco's tunneling are. I hope these are informed comments. Dino From list-mgr@ISI.EDU Wed Oct 18 05:55:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27537>; Wed, 18 Oct 1995 13:01:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27472>; Wed, 18 Oct 1995 13:00:07 -0700 Received: from anduin.ocf.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA27463>; Wed, 18 Oct 1995 13:00:06 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by anduin.ocf.llnl.gov (4.1/SMI-4.0) id AA07599; Wed, 18 Oct 95 12:55:24 PDT Message-Id: <9510181955.AA07599@anduin.ocf.llnl.gov> X-Sender: jed@anduin.ocf.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Oct 1995 12:55:28 -0700 To: ip-atm@matmos.hpl.hp.com, mbone From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: Multicasting with ATM - a concern -> meta (long) I started this "Multicasting with ATM - a concern" thread because I was worried about getting too far down the path with the IP over ATM approach discussed in "Support for Multicast over UNI3.1 based ATM Networks" - draft-ieft-ipatm-07.txt without a clear understanding that it would suffice for the sort of multicast applications that are running now (after a fashion) over the Internet MBone. I received many very thoughtful and to me useful replies - mostly on the ip-atm@matmos.hpl.hp.com list. I feel there is a clear conclusion from these replies. Based on this assumption I would like to end that discussion and ask what I hope is a more focused and limited "meta" question. My conclusion from the discussion on this thread is that ATM will not effectively support multipoint to multipoint "circuits." It won't even effectively support bi-directional point to multipoint "circuits." I hope my terminology is clear here. The basic problem is the multiplexing of a single circuit data structure while still separating the multiple transmitters at the destination - e.g. with VCIs within a VPI or whatever. I don't want to fan any embers that may be smoldering on that issue, but rather ask a higher level question. Basically the question is "does it matter?" Namely, are there applications for which the capabilities that ATM does deliver are not adequate? We have numerous examples of multicast applications available on the MBone. These currently work with the IP multicast group mechanism. Do they need to? Would something simpler do? When I think about multicast applications I tend to fall into thinking about something like a distance learning application or a radio or television talk show. Namely, there is one usual "multicaster", but possible sporadic "back" channels that may be distributed to the multicast group. It seems to me that ATM's support for a unidirectional multicast circuit suffices for what is needed for such applications. Namely, a multicaster can set up such a multicast circuit. Any "back" channels can be set up from the back transmitters as unicast circuits directly to the multicaster. The multicaster can then mix these back channels into the multicast. Not quite like current IP multicast group semantics, but is the difference important for applications? All that is needed with this approach is efficient (i.e. scalable, etc.) support for unidirectional point to multipoint multicast. _____________________________ My meta question is: are there applications for which such an approach will not suffice? I.e. are there applications where a true multipoint to multipoint capability is needed? Since both these lists are mostly focused on lower level issues (are there such lists for higher level issues or are such things only supposed to be discussed face to face?), I ask that any responses be sent only privately to me. I would think that potential examples can be discussed off-line and only brought to the list if any seem solid. Since I don't want to come back to the lists unnecessarily, I would like to explore the consequences of the possibility that there are NO such applications. In this case it seems to me that perhaps we have a problem with the semantics of IP multicast groups. Namely they may be more rich than needed and specifically too rich for a reasonable ATM implementation. While I accept Dan Grossman's comment: >Bringing us back full circle to where the ip-atm WG is already at - mpt-mpt >IP communication using overlaid pt-mpt VCs. in the limited sense in which I think he meant it - namely this is where we are in trying to adapt IP multicast to ATM. However, I am unhappy with this conclusion in terms of what it means for multicast applications over ATM. This approach of overlaying pt-mpt VCs to achieve IP multicast will not (IMO) scale. It will not scale and so it effectively WILL NOT WORK. Who are we kidding with this approach? It seems to me that we might be in a situation where we have adopted an overly rich set of semantics for IP multicast because it was available. IF (!) there are no applications that truly require mpt to mpt multicast semantics, might we not be better off defining a new and narrower set of multicast semantics that can effectively used to build applications for IP and "native" ATM and IP over ATM? I still feel my original concern, but thanks to the many thoughtful comments on the lists I think my concern is somewhat more focused. The problem I see is that we are continuing to "blindly" develop multicast applications for the rich IP multicast semantics when a narrower set of semantics would (?) suffice AND would work effectively with ATM if/when it becomes more widely available. Please be kind to the lists and direct all but the most generally relevant comments directly to me (jed@llnl.gov) until they can be filtered some. Naturally I will respond as best I can to requests to take such high level discussions elsewhere - suggestions on where elsewhere might be are solicited. --Jed http://www-atp.llnl.gov/atp/jed-signature.html From list-mgr@ISI.EDU Thu Oct 19 00:29:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28943>; Wed, 18 Oct 1995 13:30:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28932>; Wed, 18 Oct 1995 13:29:48 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA28924>; Wed, 18 Oct 1995 13:29:42 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id WAA05460; Wed, 18 Oct 1995 22:29:21 +0200 Date: Wed, 18 Oct 1995 22:29:21 +0200 Message-Id: <199510182029.WAA05460@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Steve Deering <deering@parc.xerox.com> Cc: mbone Subject: Re: bandwidth questions In-Reply-To: <95Oct17.171859pdt.75270@digit.parc.xerox.com> References: <95Oct17.171859pdt.75270@digit.parc.xerox.com> Steve Deering writes: > > > Or you could just configure a static multicast route to override the unicast > > topology at the point it differs (most likely your boundary router) and > > another at the other endpoint of the tunnel. Doesn't sound too complicated > > to me. > > Sure, if you're content to use static routes and restricted topologies, > you can make anything work. > How would you describe the the current MBone? I would really say it being restricted topology. What I do see in the real world which I daily do, is that most of the sites have 1-3 links to the "outside", mostly depending on their size. Over 80% of them are 1 link, >15% 2 links (multihomed). So a single static routed multicast tunnel addresses 80% of the sites. For the 15% the case I've observed is that they either get the multicast natively from one of their providers or a PIM or a DVMRP tunnel from one of them. For the native case, one multicast static route addresses the problem at the exit point(s) and DVMRP tunnel placed at the exit point(s) does the job for you as does the PIM tunnel also. It's bad design anyway to run the tunnel halfway across your network and then route it back towards the exit point. Most networks I see today have quite hierarchical design. The Internet is one of the notable exeptions though. That's something that justifies why DVMRP shouldn't be thrown out the window in the near future but that might just happen with mrouted. Please note that it's implementations that move packets around, not the protocol specifications. Running a mix of PIM for the leafs, PIM interoperability with DVMRP unicast routing for the backbone seems the most useful and workable solution to me at present. You get the best of both worlds. When Sparse Mode PIM is readily available and robust for backbone use, variables in the previous judgement will most definetly be different. > > I've been a happy camper ever since. Of course, Cisco didn't figure > > this out in the first run. Nobody does. Cisco's presently at their third > > release with multicast code and it's steadily becoming more and more > > feature-rich and more useful. For mrouted it took more than three times to > > get it even to prune with another mrouted. And it took a lot more to > > do classless, default-routing, etc. > > We were talking about tunneling capability. I am well aware of the many As you are well aware, the protocol name stands for "protocol INDEPENDENT multicast". PIM is definetly not a substitute for DVMRP but DVMRP is one of the routing protocols (among RIP, IGRP, OSPF, EIGRP, BGP, EGP, IS-IS, etc.) you could run to RPF your frames. If you are claiming that DVMRP does not have "tunneling capability" then I'll believe you that PIM cannot tunnel. Othervise you must be wrong. I'd also like to emphasize that the caveat and feature of tunneling is that the boxes your tunnel is transiting have no idea whatsoever about the contents of the packets the tunnel is carrying. This means that the boxes along the path are unable to make intelligent decisions on which frames to discard at the time they experience congestion. I'm aware that there are intelligent rate-limiting and queueing mechanisms in mrouted but these are mostly defeated in real world situations where the boxes cannot feed congestive information back to the mrouted flooding the link anyway. What you can do with Cisco's PIM implementation (dense or sparse mode) is to prioritize the traffic so that you can get crystal clear audio at the same time you have to discard 30% of your video frames. Of course this only applies to the case of native non-tunneled multicast traffic. > weaknesses and shortcomings of mrouted -- it is a piece of software [...some text deleted...] > all, that's what that organization specializes in. Also, whatever they > happen to be learning as they go along, they did understand the consequences > of the interaction of their PIM implementation with the DVMRP MBone long > before they shipped PIM product (this includes not just the leaking-non- > multicast-routes problem, but also their failure to sort their DVMRP > route report messages into the order required by mrouted, an earlier cause > of cisco-induced MBone failure), and they basically chose to dismiss those > consequences as unimportant, as far as I can tell. But all of that has > nothing to do with the relative merits of ways of doing tunneling. > The flooding of routes requires explicit configuration commands to do that. It does not happen by default. I can agree with you that the documentation didn't state the consequences clearly enough. As far the sorting goes, I think that it's mrouted implementation specific caveat and as undocumented as the mrouted is, shouldn't really be blamed on nothing else than mrouted. Pete From list-mgr@ISI.EDU Wed Oct 18 03:07:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29509>; Wed, 18 Oct 1995 13:43:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29467>; Wed, 18 Oct 1995 13:42:41 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA29459>; Wed, 18 Oct 1995 13:42:39 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16403(4)>; Wed, 18 Oct 1995 13:25:34 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177482>; Wed, 18 Oct 1995 10:07:28 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de> Cc: multicast-support@cisco.com, mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Tue, 17 Oct 95 13:07:04 PDT." <199510172007.VAA22418@faui40.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 10:07:19 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct18.100728pdt.177482@crevenia.parc.xerox.com> In message <199510172007.VAA22418@faui40.informatik.uni-erlangen.de> Toerless wrote: >Yes, actually, there is a big problem with GRE/IP tunnels. mrouted does >not support them. I strongly suggest the maintainers of mrouted to >implement them Why are GRE/IP tunnels better than mrouted's ip-in-ip tunnels? Where can I find documentation on GRE/IP tunnels? Bill From list-mgr@ISI.EDU Wed Oct 18 06:49:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29926>; Wed, 18 Oct 1995 13:51:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29907>; Wed, 18 Oct 1995 13:51:02 -0700 Received: from hubbub.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA29899>; Wed, 18 Oct 1995 13:51:00 -0700 Received: from rhodes.cisco.com (rhodes.cisco.com [171.69.1.169]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id NAA19478; Wed, 18 Oct 1995 13:49:53 -0700 Message-Id: <199510182049.NAA19478@hubbub.cisco.com> To: Bill Fenner <fenner@parc.xerox.com> Cc: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de>, multicast-support@cisco.com, mbone, agarrett@cisco.com Subject: Re: bandwidth questions In-Reply-To: Your message of "Wed, 18 Oct 95 10:07:19 PDT." <95Oct18.100728pdt.177482@crevenia.parc.xerox.com> Date: Wed, 18 Oct 95 13:49:53 PDT From: Aviva Garrett <agarrett@cisco.com> In message <95Oct18.100728pdt.177482@crevenia.parc.xerox.com> you write: >In message <199510172007.VAA22418@faui40.informatik.uni-erlangen.de> Toerless >wrote: >>Yes, actually, there is a big problem with GRE/IP tunnels. mrouted does >>not support them. I strongly suggest the maintainers of mrouted to >>implement them > >Why are GRE/IP tunnels better than mrouted's ip-in-ip tunnels? > >Where can I find documentation on GRE/IP tunnels? One place to start is in the Cisco router documentation. In the "Router Products Configuration Guide," in the "Configurating Interfaces" chapter, there is a section called "Configure a Tunnel Interface." You might also want to poke around in the "Internetwork Design Guide" and the "Internetwork Technology Overview." You can also try using the search function on UniverCD; I can't get mine to work @:-( ..Aviva From list-mgr@ISI.EDU Wed Oct 18 23:12:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01147>; Wed, 18 Oct 1995 14:13:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01100>; Wed, 18 Oct 1995 14:12:12 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA01092>; Wed, 18 Oct 1995 14:12:07 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id WAA22802; Wed, 18 Oct 1995 22:08:06 +0100 Message-Id: <199510182108.WAA22802@piraya.electrum.kth.se> To: Tim Heldt <heldt@ece.orst.edu> Cc: mbone, e93_mda@it.kth.se Subject: Re: HPUX question... In-Reply-To: Your message of "Wed, 18 Oct 1995 09:07:02 MST." <9510181607.AA12555@tongu.ece.orst.edu> Date: Wed, 18 Oct 1995 22:12:05 +0100 From: Magnus <e93_mda@it.kth.se> Hi Tim! HP has patches for the kernel as well as binaries for mrouted etc. They are up to mrouted 3.6, I run it on one of my HP's (a 725/75) and it keeps ticking. The only real problem seems to be HP's policy for having the files... You migth have it for your own use but do not spread them. You can contact Aled Edwards <aje@hplp.hpl.hp.com> for getting the files. The mrouted sources are only sligthly modified. Magnus From list-mgr@ISI.EDU Thu Oct 19 01:21:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01760>; Wed, 18 Oct 1995 14:22:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01707>; Wed, 18 Oct 1995 14:21:48 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA01694>; Wed, 18 Oct 1995 14:21:44 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id XAA05622; Wed, 18 Oct 1995 23:21:42 +0200 Date: Wed, 18 Oct 1995 23:21:42 +0200 Message-Id: <199510182121.XAA05622@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Bill Fenner <fenner@parc.xerox.com> Cc: multicast-support@cisco.com, mbone Subject: Re: bandwidth questions In-Reply-To: <95Oct18.100728pdt.177482@crevenia.parc.xerox.com> References: <199510172007.VAA22418@faui40.informatik.uni-erlangen.de> <95Oct18.100728pdt.177482@crevenia.parc.xerox.com> Bill Fenner writes: > In message <199510172007.VAA22418@faui40.informatik.uni-erlangen.de> Toerless > wrote: > >Yes, actually, there is a big problem with GRE/IP tunnels. mrouted does > >not support them. I strongly suggest the maintainers of mrouted to > >implement them > > Why are GRE/IP tunnels better than mrouted's ip-in-ip tunnels? > It's protocol-independent :-) > Where can I find documentation on GRE/IP tunnels? > RFC 1701. Pete From list-mgr@ISI.EDU Thu Oct 19 01:26:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02073>; Wed, 18 Oct 1995 14:28:53 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02037>; Wed, 18 Oct 1995 14:27:31 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA02030>; Wed, 18 Oct 1995 14:27:29 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id XAA05642; Wed, 18 Oct 1995 23:26:59 +0200 Date: Wed, 18 Oct 1995 23:26:59 +0200 Message-Id: <199510182126.XAA05642@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Aviva Garrett <agarrett@cisco.com> Cc: multicast-support@cisco.com, mbone Subject: Re: bandwidth questions In-Reply-To: <199510182049.NAA19478@hubbub.cisco.com> References: <95Oct18.100728pdt.177482@crevenia.parc.xerox.com> <199510182049.NAA19478@hubbub.cisco.com> Aviva Garrett writes: > In message <95Oct18.100728pdt.177482@crevenia.parc.xerox.com> you write: > > One place to start is in the Cisco router documentation. > In the "Router Products Configuration Guide," in the > "Configurating Interfaces" chapter, there is a section called > "Configure a Tunnel Interface." You might also want to poke > around in the "Internetwork Design Guide" and the "Internetwork > Technology Overview." You can also try using the search function > on UniverCD; I can't get mine to work @:-( > > ..Aviva > You most likely haven't paid Verity for The Right To Search. This is something to be included in The Letter to Santa. Pete P.S. On the more serious side, I would be happy with a search engine with less features and more portablity. From list-mgr@ISI.EDU Wed Oct 18 07:58:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04465>; Wed, 18 Oct 1995 15:08:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04315>; Wed, 18 Oct 1995 15:06:46 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA04307>; Wed, 18 Oct 1995 15:06:39 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15841(3)>; Wed, 18 Oct 1995 14:59:39 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 18 Oct 1995 14:58:48 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Petri Helenius <pete@sms.fi> Cc: Steve Deering <deering@parc.xerox.com>, mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Wed, 18 Oct 95 13:29:21 PDT." <199510182029.WAA05460@silver.sms.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 14:58:39 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct18.145848pdt.177478@crevenia.parc.xerox.com> In message <199510182029.WAA05460@silver.sms.fi> you write: >What you can do with Cisco's PIM implementation (dense or sparse mode) >is to prioritize the traffic so that you can get crystal clear audio at >the same time you have to discard 30% of your video frames. Of course this >only applies to the case of native non-tunneled multicast traffic. I run the MBONE over my ISDN link all the time, using a DVMRP tunnel. I routinely get crystal-clear audio and extremely lossy video, due to the ratelimiting and prioritising mechanisms in mrouted 3.6 . >As far the sorting goes, I think that it's mrouted implementation specific >caveat and as undocumented as the mrouted is, shouldn't really be blamed on >nothing else than mrouted. Actually, the requirement for sorted routing updates is clearly spelled out in mrouted's dvmrp.h ; given that the mrouted source code is the available DVMRP documentation and Cisco almost definitely read the source to determine packet formats, they must have seen dvmrp.h . They just chose to ignore the requirement. Bill From list-mgr@ISI.EDU Wed Oct 18 08:01:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04863>; Wed, 18 Oct 1995 15:13:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04781>; Wed, 18 Oct 1995 15:12:28 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA04774>; Wed, 18 Oct 1995 15:12:27 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15268(1)>; Wed, 18 Oct 1995 15:02:56 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 18 Oct 1995 15:02:04 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Petri Helenius <pete@sms.fi> Cc: Bill Fenner <fenner@parc.xerox.com>, multicast-support@cisco.com, mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Wed, 18 Oct 95 14:21:42 PDT." <199510182121.XAA05622@silver.sms.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 15:01:53 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct18.150204pdt.177478@crevenia.parc.xerox.com> In message <199510182121.XAA05622@silver.sms.fi> Petri Helenius writes: >Bill Fenner writes: > > Why are GRE/IP tunnels better than mrouted's ip-in-ip tunnels? > >It's protocol-independent :-) But the tunnels that mrouted builds are not general purpose; they are for the explicit purpose of moving multicast packets from one place to another. The multicast kernel code explicitly drops encapsulated unicast packets. Let me rephrase the question: For the specific purpose of moving multicast packets through a multicast-ignorant topology, why are GRE tunnels better than IP-in-IP tunnels? Bill From list-mgr@ISI.EDU Thu Oct 19 02:34:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06049>; Wed, 18 Oct 1995 15:36:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06006>; Wed, 18 Oct 1995 15:35:36 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA05997>; Wed, 18 Oct 1995 15:35:32 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id AAA05865; Thu, 19 Oct 1995 00:34:33 +0200 Date: Thu, 19 Oct 1995 00:34:33 +0200 Message-Id: <199510182234.AAA05865@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Bill Fenner <fenner@parc.xerox.com> Cc: mbone Subject: Re: bandwidth questions In-Reply-To: <95Oct18.145848pdt.177478@crevenia.parc.xerox.com> References: <199510182029.WAA05460@silver.sms.fi> <95Oct18.145848pdt.177478@crevenia.parc.xerox.com> Bill Fenner writes: > In message <199510182029.WAA05460@silver.sms.fi> you write: > >What you can do with Cisco's PIM implementation (dense or sparse mode) > >is to prioritize the traffic so that you can get crystal clear audio at > >the same time you have to discard 30% of your video frames. Of course this > >only applies to the case of native non-tunneled multicast traffic. > > I run the MBONE over my ISDN link all the time, using a DVMRP tunnel. I > routinely get crystal-clear audio and extremely lossy video, due to the > ratelimiting and prioritising mechanisms in mrouted 3.6 . > Yes, as long as you can guarantee that nothing else interferes with the available bandwidth between the endpoints of the tunnel (as I stated in my previous message). You can do this by prioritizing the ip-over-ip tunneled traffic over everything else but this is something you usually wouldn't want to do. What I'd like to see (and what I can do today) is to see the video traffic being thrown away ONLY when the link is experiencing congestion, not by some predefined hard limit on my multicast traffic (which in addition is consuming precious bandwidth by having two ip headers instead of one) For more clarity, I'll include an example. I've 256kbps of total bandwidth available. I'd like to receive 128kbps of video, 64kbps of audio and run X, telnet and others over the link at the same time without degrading my audio at all and without degrading my video unneccessarily and still having the X, telnet and others section to have up to 192kbps of the bandwidth when they so desire but still keep audio going. If I look at the mrouted implementation, I see that I've to set the rate limit to 192kps at lowest. That would keep the multicast traffic below 192kbps (or actually somewhere around 200-210kbps with the additional header overhead). From this tunnel termination point there is quite solid 192kbps datastream consisting of 1/3 of audio and 2/3s of video destined to some unicast destination over the 256kbps link in discussion. Now when do something that consumes more than 64kbps of bandwidth the unicast router forwarding the frames to my link has to discard something because the total adds up to more than what's available. It has to either discard my X, telnet or other traffic I would really like to keep (because I consider that more important than the talking head on the video window) or discard some random frames from the tunnel (in which case it has 33% chance of hitting an audio frame). There is no way to set the rate limit low enough and at the same time use all available bandwidth to deliver maximum-quality video when the bandwidth isn't used for other purposes. Please DO correct me if I'm wrong here but at present I do believe in the fact that in order to satisfy the requirements I stated with mrouted you have to trade off something. The point that is also missing here is that the above discussion only applies to leaf sites and homes, etc. where the bandwidth consumption is somewhat in control of the user or a couple of users utilizing the link. (so that they can avoid bandwidth-intensive tasks during conferencing) When we do run the links over backbone trunks, there is no real way to know beforehand how much bandwidth we will have available and because of that pre-set rate-limiting is pretty useless in controlling the queueing to avoid loss. It really needs congestive feedback from the device connected to the actual link(s). This will become even more true when networks where the real transmission bandwidth is not known. (like ATM, SMDS and FR) Pete From list-mgr@ISI.EDU Thu Oct 19 00:31:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06080>; Wed, 18 Oct 1995 15:37:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05852>; Wed, 18 Oct 1995 15:31:55 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA05844>; Wed, 18 Oct 1995 15:31:53 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id XAA23890; Wed, 18 Oct 1995 23:27:36 +0100 Message-Id: <199510182227.XAA23890@piraya.electrum.kth.se> To: Bill Fenner <fenner@parc.xerox.com> Cc: Petri Helenius <pete@sms.fi>, Steve Deering <deering@parc.xerox.com>, mbone, e93_mda@it.kth.se Subject: Re: bandwidth questions In-Reply-To: Your message of "Wed, 18 Oct 1995 14:58:39 PDT." <95Oct18.145848pdt.177478@crevenia.parc.xerox.com> Date: Wed, 18 Oct 1995 23:31:37 +0100 From: Magnus <e93_mda@it.kth.se> Yes, Cisco has read the mrouted source over and over again, but I think there is still a need for a separate document rather then the source. Maybe just a draft-dvmrp or something. Looking at the mrouted code and viewing the result of mrinfo reveals that Cisco is running DVMRP protocol version 11 nowdays... It is convinient to know where the Cisco's are... but is this the way? I would be happy to contribute to a propper document. Sourcecode as protocol specification is not really neat. Magnus From list-mgr@ISI.EDU Thu Oct 19 02:40:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06394>; Wed, 18 Oct 1995 15:41:29 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06346>; Wed, 18 Oct 1995 15:40:22 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA06339>; Wed, 18 Oct 1995 15:40:19 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id AAA05875; Thu, 19 Oct 1995 00:40:15 +0200 Date: Thu, 19 Oct 1995 00:40:15 +0200 Message-Id: <199510182240.AAA05875@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Bill Fenner <fenner@parc.xerox.com> Cc: multicast-support@cisco.com, mbone Subject: Re: bandwidth questions In-Reply-To: <95Oct18.150204pdt.177478@crevenia.parc.xerox.com> References: <199510182121.XAA05622@silver.sms.fi> <95Oct18.150204pdt.177478@crevenia.parc.xerox.com> Bill Fenner writes: > > But the tunnels that mrouted builds are not general purpose; they are for the > explicit purpose of moving multicast packets from one place to another. The > multicast kernel code explicitly drops encapsulated unicast packets. I think the issue here is that you can do a lot more with GRE/IP tunnels than you can with IP-in-IP tunnels. If you are using both for transporting multicast datagrams over arbitary topology, I don't see a reason for arguing whether one is better than another for that specific application. > > Let me rephrase the question: For the specific purpose of moving multicast > packets through a multicast-ignorant topology, why are GRE tunnels better than > IP-in-IP tunnels? > The nice thing here is that Cisco IOS supports both IP-in-IP and GRE/IP tunnels. It gives us control freaks something to fiddle with. It's good to have knobs, you know? You would be pissed if your transmission would be stuck in the 1st gear, right? Pete (disclaimer: Yes, I do know that most americans don't know how to shift, so they do leave the possibility out of the cars they make :-) From list-mgr@ISI.EDU Wed Oct 18 08:58:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07330>; Wed, 18 Oct 1995 16:00:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07241>; Wed, 18 Oct 1995 15:59:12 -0700 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA07139>; Wed, 18 Oct 1995 15:59:04 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA22856 (5.65c/IDA-1.4.4nsd for <mbone@isi.edu>); Wed, 18 Oct 1995 15:58:07 -0700 Received: by jaspar.NSD.3Com.COM id AA18762 (5.65c/IDA-1.4.4-910730); Wed, 18 Oct 1995 15:58:04 -0700 From: "Cyndi M. Jung" <cmj@NSD.3Com.COM> Message-Id: <199510182258.AA18762@jaspar.NSD.3Com.COM> Subject: Re: bandwidth questions To: pete@sms.fi (Petri Helenius) Date: Wed, 18 Oct 1995 15:58:04 -0700 (PDT) Cc: mbone, fenner@parc.xerox.com In-Reply-To: <199510182121.XAA05622@silver.sms.fi> from "Petri Helenius" at Oct 18, 95 11:21:42 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2616 > > Bill Fenner writes: > > In message <199510172007.VAA22418@faui40.informatik.uni-erlangen.de> Toerless > > wrote: > > >Yes, actually, there is a big problem with GRE/IP tunnels. mrouted does > > >not support them. I strongly suggest the maintainers of mrouted to > > >implement them > > > > Why are GRE/IP tunnels better than mrouted's ip-in-ip tunnels? > > > It's protocol-independent :-) > > > Where can I find documentation on GRE/IP tunnels? > > > RFC 1701. > > Pete > The RFC is a fairly blank template for anything-over-ip tunnels - there is much left to the reader to do to fill in the blanks. The RFC is no better for implementing GRE tunnels than RFC 1075 is for implementing DVMRP - with the exception that the DVMRP code is freely available over the network. I think (and you may all disagree) that the debate over the "goodness" of multicast routing using the unicast routes is fairly religious - I doubt there is sufficient experience to say one way or the other which is best. It is, however, fortunate that we have several possible ways to do it, so that we can consider the different aspects - maybe I'm slow or have not a great theoretical mind, but I have often failed to realize aspects of a protocol until I had seen it in operation, both good aspects as well as bad aspects. I'll hold my judgement on PIM, since I have never seen it, but DVMRP does have an important place in the whole scheme of things multicast - and *especially* it's ability to be used as a multicast-only router, that is, without also routing unicast traffic. This would not be possible if in fact the DVMRP tunnels were GRE tunnels, as the GRE tunnels would need to route unicast traffic as well as multicast traffic (correct me if I'm wrong on this - like I said, the RFC is quite superficial, and does not get into usage subtleties as this). We use a 3Com router to attach our engineering network to the MBONE. It is not also routing unicast traffic, which is good, because we are physically firewalled off from the Internet - this router has one interface on our demarc LAN, and a second interface into the multicast lab. We can secure this router (no telnet access of any kind), and keep our security guardians happy while we gain an easy source of multicast traffic to drive through our own routers, using DVMRP and/or MOSPF. I am very grateful for DVMRP tunnels that let me do this - if you are not happy with them for some other reason, I'm sure you have a legitimate gripe, but this one feature of DVMRP has been a great aid to my group in developing our multicast IP support. Cyndi From list-mgr@ISI.EDU Thu Oct 19 02:07:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10832>; Wed, 18 Oct 1995 17:08:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10811>; Wed, 18 Oct 1995 17:07:51 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA10804>; Wed, 18 Oct 1995 17:07:49 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id BAA26093; Thu, 19 Oct 1995 01:03:51 +0100 Message-Id: <199510190003.BAA26093@piraya.electrum.kth.se> To: "Cyndi M. Jung" <cmj@nsd.3com.com> Cc: pete@sms.fi (Petri Helenius), mbone, fenner@parc.xerox.com, e93_mda@it.kth.se Subject: Re: bandwidth questions In-Reply-To: Your message of "Wed, 18 Oct 1995 15:58:04 MST." <199510182258.AA18762@jaspar.NSD.3Com.COM> Date: Thu, 19 Oct 1995 01:07:46 +0100 From: Magnus <e93_mda@it.kth.se> An religous issue is wheiter to have joint unicast and multicast routing strategy or not, people seems to miss that discussion before they discuss the advantage and disadvantage of various protocols. Magnus From list-mgr@ISI.EDU Wed Oct 18 10:36:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11989>; Wed, 18 Oct 1995 17:39:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11916>; Wed, 18 Oct 1995 17:36:23 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA11909>; Wed, 18 Oct 1995 17:36:22 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id RAA09043; Wed, 18 Oct 1995 17:36:16 -0700 Date: Wed, 18 Oct 1995 17:36:16 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199510190036.RAA09043@greatdane.cisco.com> To: cmj@nsd.3com.com ("Cyndi M. Jung") Cc: mbone, fenner@parc.xerox.com Subject: Re: bandwidth questions > RFC 1701. The RFC is a fairly blank template for anything-over-ip tunnels Actually, it's anything over anything. - there is much left to the reader to do to fill in the blanks. Or, you can read RFC 1702, and see the rest of the story. like I said, the RFC is quite superficial, and does not get into usage subtleties as this A GRE provides a _generic_ tunnel. That was the point. One which can be used to support any type of datagram traffic. Yes, of COURSE, there are usage subtleties with a particular application. Fortunately, most of them are handled by pointing out that it simply follows the model of a point-to-point link. Perhaps you should take more than a superficial look at the RFC, eh? Tony From list-mgr@ISI.EDU Wed Oct 18 09:06:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13077>; Wed, 18 Oct 1995 18:04:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13041>; Wed, 18 Oct 1995 18:03:15 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA13033>; Wed, 18 Oct 1995 18:03:13 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16531(7)>; Wed, 18 Oct 1995 16:06:37 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 18 Oct 1995 16:06:10 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Petri Helenius <pete@sms.fi> Cc: Bill Fenner <fenner@parc.xerox.com>, mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Wed, 18 Oct 95 15:34:33 PDT." <199510182234.AAA05865@silver.sms.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 16:06:00 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct18.160610pdt.177478@crevenia.parc.xerox.com> The ultimate goal has always been to have multicast routing in the infrastructure. Of course tunnels are wasteful, of course native multicast routing is much better. But tunnels are also needed; I know of no Internet backbone provider that supports native multicast. Native multicast in the infrastructure can *always* beat unix mrouters and tunnels, no contest. But tunnels and unix mrouters will still be useful until the infrastructure does support multicast -- for example, my ISDN equipment is a pair of bridges from Combinet. They don't support multicast in any sense other than broadcast, so I have to run a tunnel over it. If I had real routers (even real UNIX boxes) on the ends of the ISDN line I wouldn't have to run a tunnel (and I certainly wouldn't). As Steve mentioned before, the mrouted/kernel code has been generally a student effort, and only for the last 6 months has there been a full-time professional responsible for the code. Of course it doesn't have the features that a router vendor's code is going to. Bill From list-mgr@ISI.EDU Wed Oct 18 09:30:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13085>; Wed, 18 Oct 1995 18:04:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13050>; Wed, 18 Oct 1995 18:03:16 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA13037>; Wed, 18 Oct 1995 18:03:14 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <19747(8)>; Wed, 18 Oct 1995 16:31:13 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 18 Oct 1995 16:30:56 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Petri Helenius <pete@sms.fi> Cc: Bill Fenner <fenner@parc.xerox.com>, multicast-support@cisco.com, mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Wed, 18 Oct 95 15:40:15 PDT." <199510182240.AAA05875@silver.sms.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 16:30:55 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct18.163056pdt.177478@crevenia.parc.xerox.com> In message <199510182240.AAA05875@silver.sms.fi> you write: >It's good to have knobs, you know? Oh, yes, I know how Cisco loves their knobs. "Turn this knob to break the MBONE." Bill From list-mgr@ISI.EDU Wed Oct 18 11:44:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14594>; Wed, 18 Oct 1995 18:45:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14578>; Wed, 18 Oct 1995 18:44:28 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA14570>; Wed, 18 Oct 1995 18:44:26 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id SAA11748; Wed, 18 Oct 1995 18:44:25 -0700 Date: Wed, 18 Oct 1995 18:44:25 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199510190144.SAA11748@greatdane.cisco.com> To: Bill Fenner <fenner@parc.xerox.com>, multicast-support@cisco.com, mbone Subject: Re: bandwidth questions Oh, yes, I know how Cisco loves their knobs. "Turn this knob to break the MBONE." Running real networks requires some knobs. Reality is like that. You might ask yourself why the exact same types of knobs which kill mbone have essentially no effect in the unicast world. I can (try to) inject 100,000 routes into unicast routing today. What do you think would happen? Tony From list-mgr@ISI.EDU Wed Oct 18 12:44:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16758>; Wed, 18 Oct 1995 19:50:42 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16619>; Wed, 18 Oct 1995 19:46:42 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA16612>; Wed, 18 Oct 1995 19:46:42 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15315(1)>; Wed, 18 Oct 1995 19:44:55 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 18 Oct 1995 19:44:45 -0700 To: Tony Li <tli@cisco.com> Cc: Bill Fenner <fenner@parc.xerox.com>, multicast-support@cisco.com, mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Wed, 18 Oct 95 18:44:25 PDT." <199510190144.SAA11748@greatdane.cisco.com> Date: Wed, 18 Oct 1995 19:44:38 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct18.194445pdt.177478@crevenia.parc.xerox.com> In message <199510190144.SAA11748@greatdane.cisco.com> you write: >You might ask yourself why the exact same types of knobs which kill >mbone have essentially no effect in the unicast world. Because the unicast world is running hierarchical routing protocols, while the MBONE is running a single instance of a distance-vector routing protocol. Could you inject 100,000 routes into a unicast RIP domain and expect it to work well? Bill (left unsaid, of course, is that hierarchical DVMRP is in the works!) From list-mgr@ISI.EDU Wed Oct 18 13:10:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17301>; Wed, 18 Oct 1995 20:12:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17263>; Wed, 18 Oct 1995 20:10:18 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA17256>; Wed, 18 Oct 1995 20:10:16 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id UAA13266; Wed, 18 Oct 1995 20:10:13 -0700 Date: Wed, 18 Oct 1995 20:10:13 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199510190310.UAA13266@greatdane.cisco.com> To: fenner@parc.xerox.com Cc: fenner@parc.xerox.com, multicast-support@cisco.com, mbone In-Reply-To: <95Oct18.194445pdt.177478@crevenia.parc.xerox.com> (message from Bill Fenner on Wed, 18 Oct 1995 19:44:38 PDT) Subject: Re: bandwidth questions Because the unicast world is running hierarchical routing protocols, while the MBONE is running a single instance of a distance-vector routing protocol. Could you inject 100,000 routes into a unicast RIP domain and expect it to work well? No, but you would only have _LOCAL_ effects. Why is mbone so brittle that the actions of one person, anywhere in the world can take it down? And how do you expect to scale multicast service given that SpamKing and others are clearly malicious? Tony From list-mgr@ISI.EDU Wed Oct 18 13:49:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18898>; Wed, 18 Oct 1995 21:05:39 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18782>; Wed, 18 Oct 1995 21:04:08 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA18774>; Wed, 18 Oct 1995 21:04:06 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14689(1)>; Wed, 18 Oct 1995 20:49:29 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 18 Oct 1995 20:49:19 -0700 To: Tony Li <tli@cisco.com> Cc: fenner@parc.xerox.com, multicast-support@cisco.com, mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Wed, 18 Oct 95 20:10:13 PDT." <199510190310.UAA13266@greatdane.cisco.com> Date: Wed, 18 Oct 1995 20:49:17 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct18.204919pdt.177478@crevenia.parc.xerox.com> In message <199510190310.UAA13266@greatdane.cisco.com> Tony wrote: > > Because ... the MBONE is running a single instance of a > distance-vector routing protocol. Could you inject 100,000 routes > into a unicast RIP domain and expect it to work well? > >No, but you would only have _LOCAL_ effects. As I said above, the MBONE is running a *single instance* of a distance-vector routing protocol. Global *is* "local". There is only one domain. >Why is mbone so brittle >that the actions of one person, anywhere in the world can take it down? Because the whole MBONE is being routed in one domain. Anyone in the world can create "local" problems, where "local" means the whole world. >And how do you expect to scale multicast service given that >SpamKing and others are clearly malicious? Migrate to hierarchical multicast routing, which will isolate local domains into seperate routing domains. Bill From list-mgr@ISI.EDU Wed Oct 18 15:00:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20500>; Wed, 18 Oct 1995 22:02:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20481>; Wed, 18 Oct 1995 22:00:33 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA20473>; Wed, 18 Oct 1995 22:00:32 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id WAA15090; Wed, 18 Oct 1995 22:00:27 -0700 Date: Wed, 18 Oct 1995 22:00:27 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199510190500.WAA15090@greatdane.cisco.com> To: fenner@parc.xerox.com Cc: fenner@parc.xerox.com, multicast-support@cisco.com, mbone In-Reply-To: <95Oct18.204919pdt.177478@crevenia.parc.xerox.com> (message from Bill Fenner on Wed, 18 Oct 1995 20:49:17 PDT) Subject: Re: bandwidth questions >And how do you expect to scale multicast service given that >SpamKing and others are clearly malicious? Migrate to hierarchical multicast routing, which will isolate local domains into seperate routing domains. And in the meantime....? What's the point in inventing yet another solution to the same problem? Tony From list-mgr@ISI.EDU Wed Oct 18 15:15:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21146>; Wed, 18 Oct 1995 22:22:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21101>; Wed, 18 Oct 1995 22:19:46 -0700 Received: from taurus.cs.nps.navy.mil (cs.nps.navy.mil) by venera.isi.edu (5.65c/5.61+local-22) id <AA21092>; Wed, 18 Oct 1995 22:19:44 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA12741; Wed, 18 Oct 95 22:15:58 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9510190515.AA12741@taurus.cs.nps.navy.mil> Subject: Re: Multicasting with ATM - a concern -> meta (long) To: jed@llnl.gov (James E. [Jed] Donnelley) Date: Wed, 18 Oct 1995 22:15:58 -0700 (PDT) Cc: ip-atm@matmos.hpl.hp.com, mbone In-Reply-To: <9510181955.AA07599@anduin.ocf.llnl.gov> from "James E. [Jed] Donnelley" at Oct 18, 95 12:55:28 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2827 Your metaquestion "does it matter" that ATM multicast is unlikely to match IP-multicast is pretty interesting. The examples you present are one-to-many or several-to-many. A small number of one-way trees can likely suffice in such scenarios. However there is another existing application that is many-to-many: large-scale virtual environments (VEs) as currently implemented using the Distributed Interactive Simulation (DIS) protocol. Other implementations of large-scale networked entity interactions are likely to emerge in connection with the Virtual Reality Modeling Language (VRML) version 2 development effort. With 100,000 simultaneous players as a nominal goal, ATM-level bandwidths and latencies will eventually be needed. The following paper addresses most of the problems inherent in scaling up. It does not discuss ATM directly but the concepts apply to your metaquestion. Internetwork Infrastructure Requirements for Virtual Environments Donald P. Brutzman, Michael R. Macedonia and Michael J. Zyda Computer Science Department, Naval Postgraduate School Monterey California 93943-5000 USA 408.656.2149 voice, 408.656.3679 fax {brutzman, macedonia, zyda}@cs.nps.navy.mil Abstract. Virtual environments (VEs) are a broad multidisciplinary research area that includes all aspects of computer science, virtual reality, virtual worlds, teleoperation and telepresence. A variety of network elements are required to scale up virtual environments to arbitrarily large sizes, simultaneously connecting thousands of interacting players and all kinds of information objects. Four key communications components for virtual environments are found within the Internet Protocol (IP) suite: light-weight messages, network pointers, heavy-weight objects and real-time streams. Software and hardware shortfalls and successes for internetworked virtual environments provide specific research conclusions and recommendations. Since large-scale networked are intended to include all possible types of content and interaction, they are expected to enable new classes of interdisciplinary research and sophisticated applications that are particularly suitable for implementation using the Virtual Reality Modeling Language (VRML). To be presented at the Virtual Reality Modeling Language (VRML) Symposium, San Diego Supercomputing Center, San Diego California, 13-15 December 1995. Available at http//www.stl.nps.navy.mil/~brutzman/vrml_95.ps all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA [Root 200] fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv_uvw.html From list-mgr@ISI.EDU Thu Oct 19 10:16:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22667>; Wed, 18 Oct 1995 23:17:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22630>; Wed, 18 Oct 1995 23:16:26 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA22622>; Wed, 18 Oct 1995 23:16:23 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id IAA06602; Thu, 19 Oct 1995 08:16:12 +0200 Date: Thu, 19 Oct 1995 08:16:12 +0200 Message-Id: <199510190616.IAA06602@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: "Cyndi M. Jung" <cmj@NSD.3Com.COM> Cc: mbone, fenner@parc.xerox.com Subject: Re: bandwidth questions In-Reply-To: <199510182258.AA18762@jaspar.NSD.3Com.COM> References: <199510182121.XAA05622@silver.sms.fi> <199510182258.AA18762@jaspar.NSD.3Com.COM> Cyndi M. Jung writes: [tli already addressed some of your issues so I'm not wasting too much bandwidth on repeating what he correctly pointed out] > > I think (and you may all disagree) that the debate over the "goodness" of > multicast routing using the unicast routes is fairly religious - I doubt > there is sufficient experience to say one way or the other which is best. The two routing protocols are likely to carry the same topology information in the future. Today this is not true and nobody knows when we are at "future". :-) > It is, however, fortunate that we have several possible ways to do it, so > that we can consider the different aspects - maybe I'm slow or have not a great > theoretical mind, but I have often failed to realize aspects of a protocol > until I had seen it in operation, both good aspects as well as bad aspects. > I'll hold my judgement on PIM, since I have never seen it, but DVMRP does > have an important place in the whole scheme of things multicast - and > *especially* it's ability to be used as a multicast-only router, that is, without > also routing unicast traffic. This would not be possible if in fact the > DVMRP tunnels were GRE tunnels, as the GRE tunnels would need to route unicast > traffic as well as multicast traffic (correct me if I'm wrong on this - like I said, > the RFC is quite superficial, and does not get into usage subtleties as this). > GRE is just point-to-point encapsulation. It depens on the routing decision on the endpoint boxes to judge what to put on the wire. You can do policy routing so that all packets destined to *.*.*.1 and *.*.*.42 go over the wire and everything else follows the unicast path. Or you can run DVMRP for multicast over the GRE-interface, have PIM RPF to that and run OSPF and BGP4 for your unicast. Just turn some of the infamous knobs. All this (and more) is there in currently shipping code. And as I've told you there, I'm a happy user who thinks the code is mature enough for production use in todays MBone. > We use a 3Com router to attach our engineering network to the MBONE. It is not > also routing unicast traffic, which is good, because we are physically firewalled > off from the Internet - this router has one interface on our demarc LAN, and > a second interface into the multicast lab. We can secure this router (no telnet > access of any kind), and keep our security guardians happy while we gain an easy > source of multicast traffic to drive through our own routers, using DVMRP and/or > MOSPF. I am very grateful for DVMRP tunnels that let me do this - if you are not > happy with them for some other reason, I'm sure you have a legitimate gripe, but > this one feature of DVMRP has been a great aid to my group in developing our > multicast IP support. > Of course if your provider supports only DVMRP tunnels, that's what you have to get in order to get to MBone. If you want to run something else than a protocol mostly related to RIP, you have the option of running PIM or MOSPF. Unfortunately MOSPF has some scalability problems when going to hundreds of routers (as OSPF does) but it's useful in a small environment. Pete From list-mgr@ISI.EDU Thu Oct 19 14:31:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23047>; Wed, 18 Oct 1995 23:29:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22852>; Wed, 18 Oct 1995 23:24:11 -0700 Received: from vx23.cc.monash.edu.au by venera.isi.edu (5.65c/5.61+local-22) id <AA22844>; Wed, 18 Oct 1995 23:23:49 -0700 Received: from basil.eng.monash.edu.au ("port 1374"@basil.eng.monash.edu.au) by vaxc.cc.monash.edu.au (PMDF V5.0-4 #8933) id <01HWMM1E5AW0I25WBP@vaxc.cc.monash.edu.au>; Thu, 19 Oct 1995 14:32:19 +1000 Received: from BASIL/SpoolDir by basil.eng.monash.edu.au (Mercury 1.20); Thu, 19 Oct 1995 14:32:19 -1000 Received: from SpoolDir by BASIL (Mercury 1.20); Thu, 19 Oct 1995 14:31:57 -1000 Date: Thu, 19 Oct 1995 14:31:47 GMT+1100 From: Brett Pentland <brett.pentland@eng.monash.edu.au> Subject: Re: bandwidth questions To: Bill Fenner <fenner@parc.xerox.com> Cc: mbone Reply-To: brett.pentland@monash.edu.au Message-Id: <245D9911779@basil.eng.monash.edu.au> X-Mailer: Pegasus Mail/Windows (v1.22) Content-Transfer-Encoding: 7BIT Priority: normal > (left unsaid, of course, is that hierarchical DVMRP is in the works!) > I was just curious. About how far down the track is the widespread usage of hierarchical DVMRP ? Brett ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Brett Pentland brett.pentland@monash.edu.au Centre for Telecommunications and Information Systems Department of Electrical and Computer Systems Engineering Monash University, Wellington Road Clayton, Vic 3168, Australia Phone : +61 3 9905-5245 Fax : +61 3 9905-5757 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From list-mgr@ISI.EDU Wed Oct 18 17:50:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25254>; Thu, 19 Oct 1995 00:53:11 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25091>; Thu, 19 Oct 1995 00:51:01 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA25084>; Thu, 19 Oct 1995 00:51:00 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id AAA10754; Thu, 19 Oct 1995 00:50:57 -0700 Date: Thu, 19 Oct 1995 00:50:57 -0700 From: Dino Farinacci <dino@cisco.com> Message-Id: <199510190750.AAA10754@stilton.cisco.com> To: deering@parc.xerox.com Cc: Toerless.Eckert@informatik.uni-erlangen.de, jzwiebel@cisco.com, mbone, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Tue, 17 Oct 1995 13:52:37 PDT <95Oct17.135246pdt.75270@digit.parc.xerox.com> Subject: bandwidth questions [Jeez, go on vacation and all hell breaks loose :-)] >> Of course, but it is difficult/unnatural to run PIM over tunnels that are >> intended to carry *multicast traffic only* -- my statement was that cisco's >> PIM doesn't support *multicast* tunneling (i.e., multicast only) -- since >> PIM does not run its own topology-discovery protocol but rather relies on Steve, I think my response will also address Cyndi Jung's question too. Before all of cisco moved to our San Jose site, we had the CBONE. Very much like the MBONE. There were multicast-only routers attached to our production links and GRE tunnels connecting some of them together. We ran EIGRP over the tunneled topology (much like the MBONE runs DVMRP RIP-like unicast routing). PIM ran over this topology which was different than the production unicast traffic, which was routed via IGRP. The multicast-only routers never received unicast packets because the hosts and the IGRP routers directed packets to IGRP routers. So, this cites a case where you just tell PIM where it should RPF to. I just want to make it clear that PIM doesn't have to be routed the same way unicast packets go. I've mentioned this to you on more than one account. >> instance of the unicast routing protocol. I say this is unnatural, because >> the main (only?) selling point of Dense-Mode PIM is that it *doesn't* >> maintain a separate routing table or run a separate topology-discovery >> protocol. (Sparse-Mode PIM has the same property, but has value beyond that, >> in the area of scalability of multicast routing over very large-scale global >> internets.) However, where parts of the topology are aligned (for both multicast and unicast) you can use a single unicast protocol. This eliminates overhead. Dense-mode PIM also has less storage requirements (i.e. there is no additional prune database per LAN per group). Dino From list-mgr@ISI.EDU Wed Oct 18 18:09:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25613>; Thu, 19 Oct 1995 01:10:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25599>; Thu, 19 Oct 1995 01:09:04 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA25591>; Thu, 19 Oct 1995 01:09:03 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id BAA10930; Thu, 19 Oct 1995 01:09:00 -0700 Date: Thu, 19 Oct 1995 01:09:00 -0700 From: Dino Farinacci <dino@cisco.com> Message-Id: <199510190809.BAA10930@stilton.cisco.com> To: fenner@parc.xerox.com Cc: tli@cisco.com, fenner@parc.xerox.com, multicast-support@cisco.com, mbone In-Reply-To: Bill Fenner's message of Wed, 18 Oct 1995 20:49:17 PDT <95Oct18.204919pdt.177478@crevenia.parc.xerox.com> Subject: bandwidth questions >> Because the unicast world is running hierarchical routing protocols, while >> the MBONE is running a single instance of a distance-vector routing protocol. Bill, it seems to me your building a case for using the existing unicast infrastructure since it is already hierarchical and scaling to a certain degree. >> Migrate to hierarchical multicast routing, which will isolate local domains >> into seperate routing domains. Don't you really mean migrate to hierarchical unicast routing. Dino From list-mgr@ISI.EDU Thu Oct 19 10:24:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26170>; Thu, 19 Oct 1995 01:30:58 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26079>; Thu, 19 Oct 1995 01:25:21 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA26072>; Thu, 19 Oct 1995 01:25:20 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA27953>; Thu, 19 Oct 1995 01:25:17 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.06066-0@bells.cs.ucl.ac.uk>; Thu, 19 Oct 1995 09:24:59 +0100 To: mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Thu, 19 Oct 95 00:40:15 +0100." <199510182240.AAA05875@silver.sms.fi> Date: Thu, 19 Oct 95 09:24:56 +0100 Message-Id: <6619.814091096@cs.ucl.ac.uk> From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> > > IP-in-IP tunnels? apropos not much at all: we were thinking of building a version of the mrouted kernel that used the IP proto field value for TCP inbstead of IP in IP, to break some of those so called 'firewalls' out there.....as far as i can tell, so long as you didnt want to run any tcp based applications _to_ the mrouted box, you'd be ok (and you could always use our udp based reliable login program, slogin....)( but we were only thinking this, and wont do it, not even to the australians:-) jon From list-mgr@ISI.EDU Thu Oct 19 10:36:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26441>; Thu, 19 Oct 1995 01:39:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26380>; Thu, 19 Oct 1995 01:37:32 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA26373>; Thu, 19 Oct 1995 01:37:31 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA27980>; Thu, 19 Oct 1995 01:37:19 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.06501-0@bells.cs.ucl.ac.uk>; Thu, 19 Oct 1995 09:36:29 +0100 To: jed@llnl.gov (James E. [Jed] Donnelley) Cc: ip-atm@matmos.hpl.hp.com, mbone, J.Crowcroft@cs.ucl.ac.uk Subject: Re: Multicasting with ATM - a concern -> meta (long) In-Reply-To: Your message of "Wed, 18 Oct 95 12:55:28 PDT." <9510181955.AA07599@anduin.ocf.llnl.gov> Date: Thu, 19 Oct 95 09:36:27 +0100 Message-Id: <6883.814091787@cs.ucl.ac.uk> From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> >My meta question is: are there applications for >which such an approach will not suffice? I.e. >are there applications where a true multipoint >to multipoint capability is needed? do you want to risk not being able to supprt them if someone thinks of them (and i think the DSI example is sufficient anyhow!)? not a good business case! cheers jon From list-mgr@ISI.EDU Wed Oct 18 18:42:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26635>; Thu, 19 Oct 1995 01:43:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26497>; Thu, 19 Oct 1995 01:42:43 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA26490>; Thu, 19 Oct 1995 01:42:42 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id BAA11313; Thu, 19 Oct 1995 01:42:15 -0700 Date: Thu, 19 Oct 1995 01:42:15 -0700 From: Dino Farinacci <dino@cisco.com> Message-Id: <199510190842.BAA11313@stilton.cisco.com> To: J.Crowcroft@cs.ucl.ac.uk Cc: fenner@parc.xerox.com, tli@cisco.com, multicast-support@cisco.com, mbone, J.Crowcroft@cs.ucl.ac.uk In-Reply-To: Jon Crowcroft's message of Thu, 19 Oct 95 09:35:17 +0100 <6875.814091717@cs.ucl.ac.uk> Subject: bandwidth questions >> you are making a big assumption that the unicast hierarchies are >> appropriate to the multicast groups..... No, I'm not assuming that at all. If there are going to be multicast-only routers, why not run BGP4 that is not connected with the BGP4 mesh that unicast routing is using. Then run PIM over that topology. Or even run DVMRP over it and just have the mrouted code RPF to BGP routes. >> the damage limitation mechanisms (policy areas etc etc) may be >> different.....assuming they should be the same may turn out ok, but i >> don't see why we should assume it - after all, having two routing >> databases is only twice the memory, its not an order of grwoth that is >> going to go up much more (i mean after unicast and many-to-many >> multicast, what kind of other routing table can you need?:-) Anycast, Virtual Reality, IPv6, PNNI. Do I need to say more ;-) Dino From list-mgr@ISI.EDU Thu Oct 19 10:35:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26660>; Thu, 19 Oct 1995 01:46:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26368>; Thu, 19 Oct 1995 01:37:20 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA26360>; Thu, 19 Oct 1995 01:37:19 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA27977>; Thu, 19 Oct 1995 01:36:29 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.06458-0@bells.cs.ucl.ac.uk>; Thu, 19 Oct 1995 09:35:21 +0100 To: Dino Farinacci <dino@cisco.com> Cc: fenner@parc.xerox.com, tli@cisco.com, multicast-support@cisco.com, mbone, J.Crowcroft@cs.ucl.ac.uk Subject: Re: bandwidth questions In-Reply-To: Your message of "Thu, 19 Oct 95 01:09:00 PDT." <199510190809.BAA10930@stilton.cisco.com> Date: Thu, 19 Oct 95 09:35:17 +0100 Message-Id: <6875.814091717@cs.ucl.ac.uk> From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> >>> Because the unicast world is running hierarchical routing protocols, while >>> the MBONE is running a single instance of a distance-vector routing protocol. > > Bill, it seems to me your building a case for using the existing unicast > infrastructure since it is already hierarchical and scaling to a certain > degree. >>> Migrate to hierarchical multicast routing, which will isolate local domains >>> into seperate routing domains. > Don't you really mean migrate to hierarchical unicast routing. Dino you are making a big assumption that the unicast hierarchies are appropriate to the multicast groups..... therein lies a serious research question.....the TV nets are not the same topologies as the phone nets, so the logical tpologies we build for group work may not ressemble the logical ones we build for one on one work, even if we do see most the unicast traffic moving to web server-server caching and mirroring traffic..... the damage limitation mechanisms (policy areas etc etc) may be different.....assuming they should be the same may turn out ok, but i don't see why we should assume it - after all, having two routing databases is only twice the memory, its not an order of grwoth that is going to go up much more (i mean after unicast and many-to-many multicast, what kind of other routing table can you need?:-) jon From list-mgr@ISI.EDU Thu Oct 19 01:54:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27913>; Thu, 19 Oct 1995 02:55:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27906>; Thu, 19 Oct 1995 02:55:04 -0700 Received: from foghorn.reston.mci.net ([204.70.133.150]) by venera.isi.edu (5.65c/5.61+local-22) id <AA27899>; Thu, 19 Oct 1995 02:55:02 -0700 Received: from localhost (young@localhost) by foghorn.reston.mci.net (8.6.12/8.6.9) with SMTP id FAA00444; Thu, 19 Oct 1995 05:54:20 -0400 Message-Id: <199510190954.FAA00444@foghorn.reston.mci.net> X-Authentication-Warning: foghorn.reston.mci.net: young owned process doing -bs X-Authentication-Warning: foghorn.reston.mci.net: Host localhost didn't use HELO protocol To: Tony Li <tli@cisco.com> Cc: Bill Fenner <fenner@parc.xerox.com>, multicast-support@cisco.com, mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Wed, 18 Oct 1995 18:44:25 PDT." <199510190144.SAA11748@greatdane.cisco.com> Date: Thu, 19 Oct 1995 05:54:20 -0400 From: "Jeff Young" <young@mci.net> oh please, i really don't have enough to do today. my coworkers have been slacking off too, just don't tell anyone when you're going to start. :-) Jeff Young young@mci.net > Date: Wed, 18 Oct 1995 18:44:25 -0700 > From: Tony Li <tli@cisco.com> > Message-Id: <199510190144.SAA11748@greatdane.cisco.com> > To: Bill Fenner <fenner@parc.xerox.com>, multicast-support@cisco.com, > mbone@ISI.EDU > Subject: Re: bandwidth questions > > > Oh, yes, I know how Cisco loves their knobs. "Turn this knob to break the > MBONE." > > Running real networks requires some knobs. Reality is like that. > > You might ask yourself why the exact same types of knobs which kill > mbone have essentially no effect in the unicast world. I can (try to) > inject 100,000 routes into unicast routing today. What do you think > would happen? > > Tony From list-mgr@ISI.EDU Thu Oct 19 04:24:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29823>; Thu, 19 Oct 1995 05:23:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29772>; Thu, 19 Oct 1995 05:20:50 -0700 Received: from watserv2.uwaterloo.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA29765>; Thu, 19 Oct 1995 05:20:48 -0700 Received: from watarts.uwaterloo.ca ([129.97.42.10]) by watserv2.uwaterloo.ca with SMTP id <90278-4>; Thu, 19 Oct 1995 08:20:39 -0400 Received: from artshh46.watstar.uwaterloo.ca by watarts.uwaterloo.ca; (5.65/1.1.8.2/13Jun95-0851AM) id AA20941; Thu, 19 Oct 1995 08:20:32 -0400 Message-Id: <9510191220.AA20941@watarts.uwaterloo.ca> X-Sender: nrandall@watarts X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Oct 1995 08:24:58 -0400 To: mbone From: Neil Randall <nrandall@watarts.uwaterloo.ca> Subject: Fame! Fortune! Your name in black ink! Please excuse if this is an inappropriate posting to this list. Is anyone out there interested in helping out with a book about MBone? My co-author and I are looking for someone with experience on the MBone and who'd be willing to turn 60-80 pages over the next month (writing plus lots of screens where possible, so it's not really 60-80 pages). The book has a U.S. publisher, and is scheduled to appear early in '96. Good writing would be neat, but we're more interested in strong information. We'll talk money as we go along (yep, real American green things). Thanks very much Neil Randall University of Waterloo Waterloo, Canada nrandall@watarts.uwaterloo.ca From list-mgr@ISI.EDU Thu Oct 19 03:24:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02204>; Thu, 19 Oct 1995 06:33:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02179>; Thu, 19 Oct 1995 06:32:45 -0700 Received: from fnal.fnal.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA02172>; Thu, 19 Oct 1995 06:32:44 -0700 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HWM97XHECW0026XV@FNAL.FNAL.GOV>; Thu, 19 Oct 1995 08:25:45 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA07050; Thu, 19 Oct 95 08:24:24 CDT Date: Thu, 19 Oct 1995 08:24:24 -0500 From: Matt Crawford <crawdad@FNAL.FNAL.GOV> Subject: Re: PIM question.. In-Reply-To: Your message of Wed, 18 Oct 95 13:22:20 +1000. <22CAC180343@basil.eng.monash.edu.au> Sender: crawdad@munin.fnal.gov To: JOHN PSALLIDAS <YANNIS@basil.eng.monash.edu.au> Cc: mbone Message-Id: <9510191324.AA07050@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6, 8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r John, > I would like to know if the following is currently possible ... You bet. We've been doing that here (but with even more hair) for a long time now. Matt Crawford From list-mgr@ISI.EDU Thu Oct 19 00:53:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05134>; Thu, 19 Oct 1995 07:57:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05021>; Thu, 19 Oct 1995 07:53:58 -0700 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA05014>; Thu, 19 Oct 1995 07:53:57 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA07489 (5.65c/IDA-1.4.4nsd for <mbone@isi.edu>); Thu, 19 Oct 1995 07:53:56 -0700 Received: by jaspar.NSD.3Com.COM id AA20451 (5.65c/IDA-1.4.4-910730); Thu, 19 Oct 1995 07:53:50 -0700 From: "Cyndi M. Jung" <cmj@NSD.3Com.COM> Message-Id: <199510191453.AA20451@jaspar.NSD.3Com.COM> Subject: Re: bandwidth questions To: young@mci.net (Jeff Young) Date: Thu, 19 Oct 1995 07:53:50 -0700 (PDT) Cc: mbone In-Reply-To: <199510190954.FAA00444@foghorn.reston.mci.net> from "Jeff Young" at Oct 19, 95 05:54:20 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1079 And this was such a quiet, well-behaved mailing list, I used to tell people. It looks like cidrd and B-I have taken a holiday and come over here :-) Cyndi > > oh please, > > i really don't have enough to do today. > my coworkers have been slacking off too, > just don't tell anyone when you're going > to start. :-) > > Jeff Young > young@mci.net > > > Date: Wed, 18 Oct 1995 18:44:25 -0700 > > From: Tony Li <tli@cisco.com> > > Message-Id: <199510190144.SAA11748@greatdane.cisco.com> > > To: Bill Fenner <fenner@parc.xerox.com>, multicast-support@cisco.com, > > mbone@ISI.EDU > > Subject: Re: bandwidth questions > > > > > > Oh, yes, I know how Cisco loves their knobs. "Turn this knob to break the > > MBONE." > > > > Running real networks requires some knobs. Reality is like that. > > > > You might ask yourself why the exact same types of knobs which kill > > mbone have essentially no effect in the unicast world. I can (try to) > > inject 100,000 routes into unicast routing today. What do you think > > would happen? > > > > Tony > > From list-mgr@ISI.EDU Thu Oct 19 04:22:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10095>; Thu, 19 Oct 1995 09:24:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10048>; Thu, 19 Oct 1995 09:22:56 -0700 Received: from sneezy.lanl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA10041>; Thu, 19 Oct 1995 09:22:54 -0700 Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by sneezy.lanl.gov (8.6.12/8.6.10) with SMTP id KAA22550 for <mbone@isi.edu>; Thu, 19 Oct 1995 10:22:52 -0600 Message-Id: <199510191622.KAA22550@sneezy.lanl.gov> X-Authentication-Warning: sneezy.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: mbone Subject: mbone connection related to running out of mbufs? Date: Thu, 19 Oct 1995 10:22:52 -0600 From: Philip Wood <cpw@lanl.gov> Folks, I'm asking for any insight you might have on a problem that has cropped up over the last few months. Background: I've been off the mbone list for some time now, however I'm jumping back on because recently I've experienced two outages resulting from the old "panic: no more mbufs" problem which I thought went away with high button shoes. The first time I checked the system, (SunOS Release 4.1.3 (FDDI_MULTICAST_SYBASE) #1: Wed Dec 1 15:12:40 MST 1993), there was a direct correlation between running the mrouted and running out of mbufs. In other words, if I brought the system up with out the mrouted running, it stayed up. If I turned on the mrouted, it crashed eventually (within minutes). So, I turned it off, since the machine is used for other things besides mbone routing. About a month later, I turned it back on and ran along fine until recently (Sep 27) when I witnessed the same problem. This mrouter has been on the mbone for a long time and would be tunneling to an ESnet node (134.55.20.135), if it was enabled. Questions: Has anyone else seen problems like this possibly due to high utiliziation or some kind of poorly formulated multicast packets? Do you think asking the system to do both Sybase and Mbone in an fddi environment a bad idea? Any help appreciated, Phil From list-mgr@ISI.EDU Thu Oct 19 12:20:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12128>; Thu, 19 Oct 1995 10:02:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12051>; Thu, 19 Oct 1995 10:01:07 -0700 Received: from mailhost.lut.ac.uk (bgate.lut.ac.uk) by venera.isi.edu (5.65c/5.61+local-22) id <AA11863>; Thu, 19 Oct 1995 09:59:33 -0700 Received: (jon@localhost) by weeble.lut.ac.uk (8.6.12/8.6.9) id LAA10038; Thu, 19 Oct 1995 11:20:04 +0100 Date: Thu, 19 Oct 1995 11:20:04 +0100 (BST) From: Jon Knight <J.P.Knight@lut.ac.uk> To: Tony Li <tli@cisco.com> Cc: fenner@parc.xerox.com, multicast-support@cisco.com, mbone Subject: Re: bandwidth questions In-Reply-To: <199510190500.WAA15090@greatdane.cisco.com> Message-Id: <Pine.SUN.3.91.951019111719.231T-100000@weeble.lut.ac.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 18 Oct 1995, Tony Li wrote: > Migrate to hierarchical multicast routing, which will isolate local domains > into seperate routing domains. > > And in the meantime....? > > What's the point in inventing yet another solution to the same problem? In a word: choice. Multicast comms still has lots of uncharted territory. Hell, unicast routing has lots of uncharted territory. Unless you implement different idea how are you supposed to find out if there's a better solution to some of the problems out there. If people din't try out different ideas we might as well all pack our bags and go home. Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Researcher, Sysop and General Dogsbody, Department of Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. ********** Heureusement ces champignons ne sont pas radioactifs. ********** From list-mgr@ISI.EDU Thu Oct 19 09:18:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13195>; Thu, 19 Oct 1995 10:22:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12925>; Thu, 19 Oct 1995 10:19:32 -0700 Received: from vax.darpa.mil (darpa.mil) by venera.isi.edu (5.65c/5.61+local-22) id <AA12918>; Thu, 19 Oct 1995 10:19:30 -0700 Received: from next146.darpa.mil (next146.darpa.mil) by vax.darpa.mil (5.65c/5.61+local-5) id <AA22309>; Thu, 19 Oct 1995 13:18:12 -0400 Received: by next146.darpa.mil (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA05866; Thu, 19 Oct 95 13:18:36 EDT Date: Thu, 19 Oct 1995 13:18:34 -0400 (EDT) From: bmiller@ito.snap.org Subject: Asymmetric routing and multicast tunneling To: mbone Message-Id: <951019131834.5243AABmS.bmiller@next146> Mime-Version: 1.0 (Generated by Eloquent) Content-Type: text/plain; charset=US-ASCII X-Mailer: Eloquent[2.01]; Eloquent is a Trademark of Take 3 I'm confused (what else is new??) on how asymmetric IP routing affects the layout of multicast tunnels. Hopefully someone can clear this up for me. Hypothetical case here: I have an mbone router. My provider does not offer multicast service at this time. Someone (X) requests a tunnel from me since, from their viewpoint, I am the closest mbone router. However, from my perspective, the route back to X transits a network that contains an mrouter. This transit network is unwilling to provide a tunnel to X because their mrouter is already carrying more tunnels than it should, but one of the tunnels it is carrying is to me. So what's the "right" thing to do? Give X the tunnel from my mrouter? Convince the owners of the transit network to disconnect my tunnel and establish a tunnel to X, then I set up a tunnel between myself and X? Tell X to look elsewhere? Ignore it, wait for a wholesale reorganization of the existing multicast topology, and go drink a beer? brian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The System Administrator formerly known as Brian Miller bmiller@ito.snap.org brian@cfar.umd.edu Killing people is not the solution, but it's a damn fine way to make sure they stop bothering you until you find a better way to deal with them. From list-mgr@ISI.EDU Thu Oct 19 06:52:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24777>; Thu, 19 Oct 1995 13:55:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24721>; Thu, 19 Oct 1995 13:54:32 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA24713>; Thu, 19 Oct 1995 13:54:30 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id NAA26184; Thu, 19 Oct 1995 13:52:20 -0700 Date: Thu, 19 Oct 1995 13:52:20 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199510192052.NAA26184@greatdane.cisco.com> To: J.P.Knight@lut.ac.uk Cc: fenner@parc.xerox.com, multicast-support@cisco.com, mbone In-Reply-To: <Pine.SUN.3.91.951019111719.231T-100000@weeble.lut.ac.uk> (message from Jon Knight on Thu, 19 Oct 1995 11:20:04 +0100 (BST)) Subject: Re: bandwidth questions In a word: choice. Multicast comms still has lots of uncharted territory. Hell, unicast routing has lots of uncharted territory. Unless you implement different idea how are you supposed to find out if there's a better solution to some of the problems out there. If people din't try out different ideas we might as well all pack our bags and go home. Please explain the conceptual differences between hierarchical routing and hierarchical routing. Tony From list-mgr@ISI.EDU Fri Oct 20 21:26:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19221>; Thu, 19 Oct 1995 20:30:04 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19207>; Thu, 19 Oct 1995 20:28:14 -0700 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp) by venera.isi.edu (5.65c/5.61+local-22) id <AA19192>; Thu, 19 Oct 1995 20:27:49 -0700 Received: from dec300 by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id MAA07505; Fri, 20 Oct 1995 12:26:59 +0900 Return-Path: <sinji-t@is.aist-nara.ac.jp> Received: by dec300.aist-nara.ac.jp (5.65+1.6W/2.7W-AIST/1.3) id AA06098; Fri, 20 Oct 95 12:26:55 GMT+0900 Message-Id: <9510200326.AA06098@dec300.aist-nara.ac.jp> To: mbone Cc: Apec-PT@pingu.kiis.or.jp Subject: Session announce ``ASIA PACIFIC MUSIC FESTIVAL'' Reply-To: sinji-t@is.aist-nara.ac.jp X-Mailer: Mew version 1.00+ on Emacs 18.59.1, Mule 1.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Date: Fri, 20 Oct 1995 12:26:52 +0900 From: =?ISO-2022-JP?B?GyRCRFhMbhsoQg==?= =?ISO-2022-JP?B?GyRCPzUbKEI=?= =?ISO-2022-JP?B?GyRCPCMbKEI=?= <sinji-t@is.aist-nara.ac.jp> Hi MBoner, welcome to Osaka, Japan, Asia. We are preparing to broadcast the following event, being held on November 14, 9:30 UCT. I'll announce about mbone session in detail later. ====================================================== It's so nice!! ASIA PACIFIC MUSIC FESTIVAL Presented by PANASONIC Don't miss this rare opportunity to see Asia's hottest international stars in one show! Scheduled to take place just before the Osaka APEC meeting, the Asia Pacific Music Festival,bringing together performers of several nationalities, will demonstrate the borderless nature of music. Now, if you can't make it to the concert hall of Osaka's Asia Pacific Trade Center on November 14, you can still catch the event's live broadcast on the Internet!! So remember to plug in on November 14, 18:30 (Japan time) for this extraordinary event. (http://www.apec.or.jp/ck/event/event.html) PERFORMERS LIST Dick Lee - Singapore L$B"+"*(BR - Japan Tracy Huang - Taiwan Shirly Kwan - Hong Kong Tamura Naomi - Japan ===================================================================== With kind regards. -- Shinji Tsubakino, E-mail: sinji-t@is.aist-nara.ac.jp // Graduate School of Information Science Nara Institute of Science and Technology, Japan // APEC(Asia Pacific Economic Cooperation)'95 Osaka Internet NOC. From list-mgr@ISI.EDU Fri Oct 20 06:21:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23073>; Thu, 19 Oct 1995 22:38:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23036>; Thu, 19 Oct 1995 22:34:33 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA23029>; Thu, 19 Oct 1995 22:34:31 -0700 Received: from haig.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA12715>; Thu, 19 Oct 1995 22:34:30 -0700 Received: from rodent.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.03444-0@haig.cs.ucl.ac.uk>; Fri, 20 Oct 1995 06:34:08 +0100 To: Tony Li <tli@cisco.com> Cc: multicast-support@cisco.com, mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Thu, 19 Oct 95 13:52:20 PDT." <199510192052.NAA26184@greatdane.cisco.com> Date: Fri, 20 Oct 95 05:21:10 +0100 Message-Id: <1877.814162870@cs.ucl.ac.uk> From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> >Please explain the conceptual differences between hierarchical routing >and hierarchical routing. if you have different policiers for your unicst and your multicast traffic, you want different tables - depending on the policies and the differences it may be more efficient to have seperate routign tables for each....someoen might develope a routing algorithm, that is better for one set of policies than the other - so you might want two routing protocols (well algorithm,s at least, but they might be implemented by different protocols for boring real worlkd reasons...) jon From list-mgr@ISI.EDU Thu Oct 19 16:33:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24821>; Thu, 19 Oct 1995 23:36:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24764>; Thu, 19 Oct 1995 23:34:13 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA24757>; Thu, 19 Oct 1995 23:34:11 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA22906; Thu, 19 Oct 1995 23:33:57 -0700 Date: Thu, 19 Oct 1995 23:33:57 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199510200633.XAA22906@greatdane.cisco.com> To: J.Crowcroft@cs.ucl.ac.uk Cc: multicast-support@cisco.com, mbone In-Reply-To: <1877.814162870@cs.ucl.ac.uk> (message from Jon Crowcroft on Fri, 20 Oct 95 05:21:10 +0100) Subject: Re: bandwidth questions [Soapbox-on] I will certainly grant you that policy may cause you to want multiple orthogonal topologies in the fully general case. Hell, we would very much like the ability to do that in the unicast case. However, there is a cost to implementing this. Now, the least cost way of implementing this would be to take an existing unicast routing protocol and modify it so that it ran over the tunnel topology and only populated a table which is used for RPFs. As I understand it, we're now off implementing our own version... But I think that the more intrinsic problem here is the thought that we can continue to manage the overlaid tunnel topology at all. Something that the unicast case should also be teaching us is that network management is very labor intensive. An overlaid topology more than doubles the problem. When the mbone was an experimental service, it made sense to deploy it in this disconnected fashion. Now that it's time for ubiquitous production deployment, the management overhead of this model is simply prohibitive, and the operations community is trying to make this fact known (to me, at least). Unfortunately, the standard operational model of the mbone today is to provide a tunnel, and people do not correctly evaluate the management burdens that they incur. So they don't even consider running on the native topology, thereby further ingraining the overlaid topology resulting in management problems. Thus, the biggest impediment to the ubiquitous deployment of mbone today is the continued use of the overlaid topology. We need an intentional paradigm shift, and we need it to start with the mbone leadership. Until then, we run with bailing wire and chewing gum.... Tony [Soapbox-off] From list-mgr@ISI.EDU Fri Oct 20 10:14:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27728>; Fri, 20 Oct 1995 01:17:07 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27649>; Fri, 20 Oct 1995 01:14:56 -0700 Received: from mailhost.lut.ac.uk (bgate.lut.ac.uk) by venera.isi.edu (5.65c/5.61+local-22) id <AA27642>; Fri, 20 Oct 1995 01:14:54 -0700 Received: (jon@localhost) by weeble.lut.ac.uk (8.6.12/8.6.9) id JAA14123; Fri, 20 Oct 1995 09:14:23 +0100 Date: Fri, 20 Oct 1995 09:14:23 +0100 (BST) From: Jon Knight <J.P.Knight@lut.ac.uk> To: Tony Li <tli@cisco.com> Cc: fenner@parc.xerox.com, multicast-support@cisco.com, mbone Subject: Re: bandwidth questions In-Reply-To: <199510192052.NAA26184@greatdane.cisco.com> Message-Id: <Pine.SUN.3.91.951020091013.231v-100000@weeble.lut.ac.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Oct 1995, Tony Li wrote: > Please explain the conceptual differences between hierarchical routing > and hierarchical routing. What an odd statement. You might as well ask someone to explain the conceptual differences between routing and routing. What I thought we were all talking about were different _implementations_ of the concepts, some of which may have advantages over others. If we're not then fair enough, I can delete this whole thread. Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Researcher, Sysop and General Dogsbody, Department of Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. ********** Heureusement ces champignons ne sont pas radioactifs. ********** From list-mgr@ISI.EDU Thu Oct 19 18:42:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28315>; Fri, 20 Oct 1995 01:43:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28290>; Fri, 20 Oct 1995 01:42:42 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA28283>; Fri, 20 Oct 1995 01:42:41 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA02971; Fri, 20 Oct 1995 01:42:25 -0700 Date: Fri, 20 Oct 1995 01:42:25 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199510200842.BAA02971@greatdane.cisco.com> To: J.P.Knight@lut.ac.uk Cc: fenner@parc.xerox.com, multicast-support@cisco.com, mbone In-Reply-To: <Pine.SUN.3.91.951020091013.231v-100000@weeble.lut.ac.uk> (message from Jon Knight on Fri, 20 Oct 1995 09:14:23 +0100 (BST)) Subject: Re: bandwidth questions What an odd statement. You might as well ask someone to explain the conceptual differences between routing and routing. Exactly. What I thought we were all talking about were different _implementations_ of the concepts, some of which may have advantages over others. If we're not then fair enough, I can delete this whole thread. Are we? I wasn't aware that there was a significant amount of learning that happens by re-implementation of the same concepts. Certainly we refine our implementation techniques, but is that the point of the mbone? "My RIP is better than your RIP?" This is fiddling while the house is burning. Tony From list-mgr@ISI.EDU Fri Oct 20 05:50:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09480>; Fri, 20 Oct 1995 09:12:14 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09146>; Fri, 20 Oct 1995 09:06:05 -0700 Received: from ackbar.arl.wustl.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA09135>; Fri, 20 Oct 1995 09:06:01 -0700 Received: by ackbar.arl.wustl.edu (5.x/ECL-A1.27) id AA27454; Fri, 20 Oct 1995 10:50:48 -0500 Date: Fri, 20 Oct 1995 10:50:48 -0500 From: jdd@arl.wustl.edu (John DeHart) Message-Id: <9510201550.AA27454@ackbar.arl.wustl.edu> To: ip-atm@matmos.hpl.hp.com, mbone, jed@llnl.gov Subject: Re: Multicasting with ATM - a concern -> meta (long) X-Sun-Charset: US-ASCII This thread seems to have quieted, but let me throw in my two cents worth. > From: jed@llnl.gov (James E. [Jed] Donnelley) > Subject: Re: Multicasting with ATM - a concern -> meta (long) > > My conclusion from the discussion on this thread is that > ATM will not effectively support multipoint to multipoint > "circuits." It won't even effectively support bi-directional > point to multipoint "circuits." I hope my terminology is > clear here. The basic problem is the multiplexing of > a single circuit data structure while still separating the > multiple transmitters at the destination - e.g. with VCIs > within a VPI or whatever. There doesn't seem to be any reason why ATM can not effectively support multipoint to multipoint circuits. A lot of ATM switching hardware supports it today. It is not difficult to build a call model and signaling structures that support it. I think given the capapbility to use mpt-to-mpt you would find an explosion of applications and services that would use it. Virtual Environments have already been mentioned. General conferencing applications are another For these applications to scale it seems that a flexible, efficient general multipoint paradigm is needed. The signaling and control operations needed to scale an overlay of N 1xM connections blows up as you try to add new participants. There are still probably significant issues to address in the areas of traffic management in general multipoint connections. Here are some pointers to some papers concerning general multipoint call models and signaling: http://www.arl.wustl.edu/~jdd/Papers John DeHart jdd@arl.wustl.edu From list-mgr@ISI.EDU Fri Oct 20 08:03:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09027>; Fri, 20 Oct 1995 09:04:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08963>; Fri, 20 Oct 1995 09:03:21 -0700 Received: from MERCKX.GRAPHICS.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA08954>; Fri, 20 Oct 1995 09:03:17 -0700 Received: by merckx.graphics.cornell.edu (5.65/DEC-Ultrix/4.3) id AA18927; Fri, 20 Oct 1995 12:03:16 -0400 Message-Id: <9510201603.AA18927@merckx.graphics.cornell.edu> Received: by verdi.graphics.cornell.edu (1.37.109.16/16.2) id AA163284993; Fri, 20 Oct 1995 12:03:13 -0400 From: Hurf Sheldon <hurf@graphics.cornell.edu> Subject: What time is it, Mr. Fox? To: mbone Date: Fri, 20 Oct 1995 12:03:13 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 791 The Mbone broadcasts are international in scope and often marvelous. What isn't so marvelous is trying to figure out when in your time zone they really are. Why not have schedule announcements publish GMT or "Zulu" time (which is Greenwich Mean Time or Universal Coordinate Time), and/or the offset from GMT as well as the local time. For unix systems at least, with zulu time and 'echo $TZ' one can figure it out quickly. Is there a list somewhere on the net of the offsets from GMT for each world timezone to make it easy for everybody? -- Hurf Sheldon Network: hurf@graphics.cornell.edu Program of Computer Graphics Voice:607 255 6713 fax:607 255 0806 580 Eng. Theory Center, Cornell University, Ithaca, N.Y. 14853 http://www.graphics.cornell.edu/~hurf/ From list-mgr@ISI.EDU Fri Oct 20 09:45:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14948>; Fri, 20 Oct 1995 10:51:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14723>; Fri, 20 Oct 1995 10:47:00 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id <AA14703>; Fri, 20 Oct 1995 10:46:42 -0700 Received: by chops.icp.net id <20696>; Fri, 20 Oct 1995 13:45:56 -0400 From: Sean Doran <smd@icp.net> To: tli@cisco.com, young@mci.net Subject: Re: bandwidth questions Cc: fenner@parc.xerox.com, mbone, multicast-support@cisco.com Message-Id: <95Oct20.134556-0400_edt.20696+9@chops.icp.net> Date: Fri, 20 Oct 1995 13:45:45 -0400 Oh, I dunno -- if he announces 100000 long prefixes in 206/8-223/8, that wouldn't be so bad. :-) Sean. - -- From list-mgr@ISI.EDU Fri Oct 20 09:36:45 1995 X-Authentication-Warning: foghorn.reston.mci.net: young owned process doing -bs X-Authentication-Warning: foghorn.reston.mci.net: Host localhost didn't use HELO protocol To: Tony Li <tli@cisco.com> Cc: Bill Fenner <fenner@parc.xerox.com>, multicast-support@cisco.com, mbone@ISI.EDU Subject: Re: bandwidth questions From: "Jeff Young" <young@mci.net> oh please, i really don't have enough to do today. my coworkers have been slacking off too, just don't tell anyone when you're going to start. :-) Jeff Young young@mci.net > Date: Wed, 18 Oct 1995 18:44:25 -0700 > From: Tony Li <tli@cisco.com> > Message-Id: <199510190144.SAA11748@greatdane.cisco.com> > To: Bill Fenner <fenner@parc.xerox.com>, multicast-support@cisco.com, > mbone@ISI.EDU > Subject: Re: bandwidth questions > > > Oh, yes, I know how Cisco loves their knobs. "Turn this knob to break the > MBONE." > > Running real networks requires some knobs. Reality is like that. > > You might ask yourself why the exact same types of knobs which kill > mbone have essentially no effect in the unicast world. I can (try to) > inject 100,000 routes into unicast routing today. What do you think > would happen? > > Tony From list-mgr@ISI.EDU Fri Oct 20 11:48:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20676>; Fri, 20 Oct 1995 12:50:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20627>; Fri, 20 Oct 1995 12:49:41 -0700 Received: from clone4 (clone4.Reston.mci.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA20619>; Fri, 20 Oct 1995 12:49:39 -0700 Received: from localhost (localhost.mci.net [127.0.0.1]) by clone4 (8.6.12/8.6.6) with ESMTP id PAA01446; Fri, 20 Oct 1995 15:48:40 -0400 Message-Id: <199510201948.PAA01446@clone4> To: Sean Doran <smd@icp.net> Cc: tli@cisco.com, fenner@parc.xerox.com, mbone, multicast-support@cisco.com Subject: Re: bandwidth questions In-Reply-To: Your message of "Fri, 20 Oct 1995 13:45:45 EDT." <95Oct20.134556-0400_edt.20696+9@chops.icp.net> Date: Fri, 20 Oct 1995 15:48:04 -0400 From: "Jeff Young" <young@mci.net> that'd be an interesting experiment. feed a router 130000 routes in a bgp update and see if it can throw 100000 of them on the floor. hmmm. whadya think? Jeff Young young@mci.net > From: Sean Doran <smd@icp.net> > To: tli@cisco.com, young@mci.net > Subject: Re: bandwidth questions > Cc: fenner@parc.xerox.com, mbone@ISI.EDU, multicast-support@cisco.com > Message-Id: <95Oct20.134556-0400_edt.20696+9@chops.icp.net> > Date: Fri, 20 Oct 1995 13:45:45 -0400 > > Oh, I dunno -- if he announces 100000 long prefixes in 206/8-223/8, > that wouldn't be so bad. :-) > > Sean. > - -- > Subject: Re: bandwidth questions > From: "Jeff Young" <young@mci.net> > > oh please, > > i really don't have enough to do today. > my coworkers have been slacking off too, > just don't tell anyone when you're going > to start. :-) > > Jeff Young > young@mci.net > > > Date: Wed, 18 Oct 1995 18:44:25 -0700 > > From: Tony Li <tli@cisco.com> > > Message-Id: <199510190144.SAA11748@greatdane.cisco.com> > > To: Bill Fenner <fenner@parc.xerox.com>, multicast-support@cisco.com, > > mbone@ISI.EDU > > Subject: Re: bandwidth questions > > > > > > Oh, yes, I know how Cisco loves their knobs. "Turn this knob to break the > > MBONE." > > > > Running real networks requires some knobs. Reality is like that. > > > > You might ask yourself why the exact same types of knobs which kill > > mbone have essentially no effect in the unicast world. I can (try to) > > inject 100,000 routes into unicast routing today. What do you think > > would happen? > > > > Tony > > > From list-mgr@ISI.EDU Fri Oct 20 14:45:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01450>; Fri, 20 Oct 1995 15:45:42 -0700 Received: from brewster.JBJ.ORG (brewster.OBPA.USDA.GOV) by venera.isi.edu (5.65c/5.61+local-22) id <AA01443>; Fri, 20 Oct 1995 15:45:34 -0700 Received: by brewster.JBJ.ORG id AA05167 (5.67a/IDA-1.5 for mbone-na@isi.edu); Fri, 20 Oct 1995 18:45:30 -0400 From: Jeff Johnson <jbj@brewster.JBJ.ORG> Message-Id: <199510202245.AA05167@brewster.JBJ.ORG> Subject: Tunnel request ... To: mbone-na Date: Fri, 20 Oct 1995 18:45:30 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 241 Hi -- I'm looking for someone who would permit me to attach to the mbone in the DC/VA/MD area. I'm not looking for more than audio on my 28.8Kb line. Any help would be appreciated. Jeff -- Jeff Johnson ARS N3NPQ jbj@jbj.org Bethesda, MD From list-mgr@ISI.EDU Fri Oct 20 09:13:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02833>; Fri, 20 Oct 1995 16:12:42 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA02823>; Fri, 20 Oct 1995 16:12:40 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id QAA08458; Fri, 20 Oct 1995 16:13:41 -0700 Message-Id: <199510202313.QAA08458@rx7.ee.lbl.gov> To: mbone-na Subject: LSI Logic sending 400kb/s of nv screendump to Mbone Date: Fri, 20 Oct 95 16:13:41 PDT From: Van Jacobson <van@ee.lbl.gov> For the past 3 hours, user "bin@drbob" (147.145.42.100) has been sending 200-400kb/s of an nv screendump to 224.2.211.31/41115. This address is behind a firewall so it's not possible to send them email. Is there anyone at or near LSI logic that could contact this person & let them know they're being antisocial? Thanks. - Van From list-mgr@ISI.EDU Fri Oct 20 09:16:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03251>; Fri, 20 Oct 1995 16:18:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03216>; Fri, 20 Oct 1995 16:17:11 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA03208>; Fri, 20 Oct 1995 16:17:10 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id QAA01034 for <mbone@ISI.EDU>; Fri, 20 Oct 1995 16:16:37 -0700 Message-Id: <199510202316.QAA01034@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: mbone Subject: isdn and nv video bandwith.. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Oct 1995 16:16:36 -0700 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Hi, Basically, I just want to know what should be the expected frame rate for transmitting video using a 128kb ISDN line of lets say something like a tv broadcast. On my FreeBSD box , I am getting about 1 to frames per second when an nv video session is aimed at my workstation. Tnks, Amancio From list-mgr@ISI.EDU Sat Oct 21 23:27:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14838>; Fri, 20 Oct 1995 22:28:51 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14817>; Fri, 20 Oct 1995 22:28:00 -0700 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp) by venera.isi.edu (5.65c/5.61+local-22) id <AA14810>; Fri, 20 Oct 1995 22:27:55 -0700 Received: from alpha211.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id OAA06525; Sat, 21 Oct 1995 14:27:52 +0900 Return-Path: <sinji-t@is.aist-nara.ac.jp> Received: from localhost by alpha211.aist-nara.ac.jp (5.67+1.6W[kuis-17]/2.8Wb/NAIST-1.3[is]) id AA04611; Sat, 21 Oct 95 14:27:52 GMT+0900 Message-Id: <9510210527.AA04611@alpha211.aist-nara.ac.jp> To: mbone Subject: ipmulticast3.5 + sunlink FDDI/S 3.0 Reply-To: sinji-t@is.aist-nara.ac.jp X-Mailer: Mew version 1.00+ on Emacs 18.59.1, Mule 1.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 21 Oct 1995 14:27:51 +0900 From: =?ISO-2022-JP?B?GyRCRFhMbhsoQg==?= =?ISO-2022-JP?B?GyRCPzUbKEI=?= =?ISO-2022-JP?B?GyRCPCMbKEI=?= <sinji-t@is.aist-nara.ac.jp> As for ipmulticast3.5, How to get on well with sunlink FDDI/S 3.0 ? My platoform is SunOS4.1.4/SparcStation20. I can't even `ping' to local fddi interface. help!! With kind regards. -- Shinji Tsubakino, E-mail: sinji-t@is.aist-nara.ac.jp // Graduate School of Information Science Nara Institute of Science and Technology, Japan // From list-mgr@ISI.EDU Mon Oct 23 20:24:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06487>; Sun, 22 Oct 1995 17:29:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06315>; Sun, 22 Oct 1995 17:26:23 -0700 Received: from octavia.anu.edu.au by venera.isi.edu (5.65c/5.61+local-22) id <AA06293>; Sun, 22 Oct 1995 17:25:09 -0700 Received: (from markus@localhost) by octavia.anu.edu.au (8.6.12/8.6.12) id KAA05308; Mon, 23 Oct 1995 10:24:23 +1000 Date: Mon, 23 Oct 1995 10:24:23 +1000 From: Markus Buchhorn <markus@octavia.anu.edu.au> Message-Id: <199510230024.KAA05308@octavia.anu.edu.au> To: hurf@graphics.cornell.edu, mbone Subject: Re: What time is it, Mr. Fox? I started exactly this thread quite a while back :-) and got no response :-(. So I wrote a script to do it. Then Paul Stewart wrapped it in a nice little CGI and added a couple of more bells: http://hibp7.ecse.rpi.edu/~stewart/mbone/tzconvert.cgi Before I ran out of 'round tuits' I was planning on merging that script with an mbone agenda tool, so that whoever looked at the timetable would see/edit it in their local time. Unfortunately all my tuits have shot through at the moment :-( :-). Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] From list-mgr@ISI.EDU Fri Oct 23 09:31:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04402>; Mon, 23 Oct 1995 10:33:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04364>; Mon, 23 Oct 1995 10:31:28 -0700 Received: from cocoa.brown.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA04355>; Mon, 23 Oct 1995 10:31:24 -0700 Received: from ets.cis.brown.edu (ets.cis.brown.edu [128.148.19.8]) by cocoa.brown.edu (8.6.12/8.6.12) with ESMTP id NAA05654 for <brown-lists-mbone@cocoa.brown.edu>; Mon, 23 Oct 1995 13:31:23 -0400 Received: (from james@localhost) by ets.cis.brown.edu (8.6.12/8.6.12) id NAA26795; Mon, 23 Oct 1995 13:31:22 -0400 To: brown-lists-mbone@cocoa.brown.edu Path: not-for-mail From: james@ets.cis.brown.edu (James_Mathiesen) Newsgroups: brown.lists.mbone Subject: Can't get Brown<->Nearnet tunnel working Date: 23 Oct 1995 13:31:21 -0400 Organization: Brown University -- Providence, Rhode Island USA Lines: 39 Message-Id: <46gjh9$q56@ets.cis.brown.edu> Hi, we at Brown Univeristy are trying to get back on the mbone and we need some help diagnosing why it isn't working. Our machine is mbone.brown.edu (128.148.128.3) and the nearnet side is 128.112.8.2. I'm not sure what nearnet is running, but we are using Solaris 2.4 with recommended patch cluster to 101945-27 on a sparc20 with 2 cpu We are running mrouted 2.2 with the solaris patch. We cannot run 3.4 because of concerns about putting non-supported patches on one of our production systems. tcpdump shows dvmrp messages going between nearnet, mbone.brown.edu and another mrouted on one of our subnets. However netstat -M on mbone does not give a list of hosts on the mbone and neither sd nor vat show anyone beyond myself. This is the output from netstat on our central mbone router. golden.brown.edu% netstat -M Virtual Interface Table Vif Threshold Local-Address Remote-Address Groups 1 32 golden noc.near.net 2 16 golden geordie.cis.brown.edu Multicast Routing Table Origin-Subnet In-Vif Out-Vifs cis-net.brown.edu 2 1* Anyone have some suggestions of things to look at? My armchair theory is that nearnet is running pruning and we aren't. BTW, I'm starting to see dvmrp packets from places that are neither nearnet nor Brown. --james From list-mgr@ISI.EDU Mon Oct 23 04:04:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06959>; Mon, 23 Oct 1995 11:09:00 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06558>; Mon, 23 Oct 1995 11:06:11 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA06548>; Mon, 23 Oct 1995 11:06:10 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15758(3)>; Mon, 23 Oct 1995 11:05:23 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 23 Oct 1995 11:04:51 -0700 To: Dino Farinacci <dino@cisco.com> Cc: jzwiebel@cisco.com, mbone, deering@parc.xerox.com Subject: Re: bandwidth questions In-Reply-To: dino's message of Thu, 19 Oct 95 00:50:57 -0800. <199510190750.AAA10754@stilton.cisco.com> Date: Mon, 23 Oct 1995 11:04:46 PDT Sender: Steve Deering <deering@parc.xerox.com> From: Steve Deering <deering@parc.xerox.com> Message-Id: <95Oct23.110451pdt.75270@digit.parc.xerox.com> > So, this cites a case where you just tell PIM where it should RPF to. > I just want to make it clear that PIM doesn't have to be routed the > same way unicast packets go. I've mentioned this to you on more than one > account. Thanks, Dino. Yes, now that you have reminded me, I do remember you explaining your use of separate cisco routers to route only multicasts over a tunneled topology, and it is indeed an example of multicast-only tunneling using cisco's PIM implementation (albeit one that requires using routers other than those used for unicast routing). I must apologize to John Zweibel and to cisco. When I read this fragment of his original message: "We, of course, use PIM and so can avoid having to set up tunnels...", I mistakenly interpreted it as a false claim of a PIM benefit ("Use PIM! It's the One that Doesn't Need Tunnels!"), rather than what it was: a simple statement of his experience that could have been stated a little more clearly. I should have sent a polite message pointing out that it was not the use of PIM, per se, that eliminated the need to use tunnels, but rather the fact that there were multicast-capable routers at each end of the link. Instead, I added immensely to the misinformation by commiting the same type of mistake (an insufficiently qualified statement) in the opposite direction, which was unsurprisingly misinterpreted as: "Don't Use PIM! It's the One the Can't Use Tunnels!". And I added insult to injury by using sarcasm. I am sorry. What I understood to be true, based on many more conversations with Dino, was that, *at this point in time*, it is not possible to use cisco's PIM implementation to route multicast packets over a non-statically-configured topology that includes tunnels, without either (a) also having unicast packets flow over those same tunnels, or (b) disabling unicast routing on those routers doing the multicast routing. This has nothing to do with PIM. It is, at least conceptually, easily fixed, and may well have been fixed by now (or maybe it was "fixed" all along, and I was just misinformed) -- the mechanisms are basically the same as required to do multiple TOS routing. I also concede that the relative importance of that capability is debatable -- clearly there are some happy cisco customers out there using PIM anyway. I do think it would greatly facilitate phased transition to "native multicast" in large, administratively-decentralized internets like my company's internal internet. Steve From list-mgr@ISI.EDU Fri Oct 23 13:09:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17077>; Mon, 23 Oct 1995 14:13:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16794>; Mon, 23 Oct 1995 14:10:02 -0700 Received: from cocoa.brown.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA16777>; Mon, 23 Oct 1995 14:09:54 -0700 Received: from ets.cis.brown.edu (ets.cis.brown.edu [128.148.19.8]) by cocoa.brown.edu (8.6.12/8.6.12) with ESMTP id RAA18498 for <brown-lists-mbone@cocoa.brown.edu>; Mon, 23 Oct 1995 17:09:47 -0400 Received: (from james@localhost) by ets.cis.brown.edu (8.6.12/8.6.12) id RAA01211; Mon, 23 Oct 1995 17:09:46 -0400 To: brown-lists-mbone@cocoa.brown.edu Path: not-for-mail From: james@ets.cis.brown.edu (James_Mathiesen) Newsgroups: brown.lists.mbone Subject: Brown's tunnel is up Date: 23 Oct 1995 17:09:46 -0400 Organization: Brown University -- Providence, Rhode Island USA Lines: 5 Message-Id: <46h0aq$15m@ets.cis.brown.edu> Thanks to everyone who offered help and suggestions getting mbone.brown.edu connected. It turns out that the nearnet machine feeding us is multihomed and was configured to use one interface as our tunnel but was actually transmitting through the other interface. The nearnet people put a static route in their machine to fix the problem. --james From list-mgr@ISI.EDU Mon Oct 23 07:40:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18343>; Mon, 23 Oct 1995 14:42:18 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18268>; Mon, 23 Oct 1995 14:40:54 -0700 Received: from crazy-horse.uoregon.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA18257>; Mon, 23 Oct 1995 14:40:50 -0700 Received: (from meyer@localhost) by crazy-horse.uoregon.edu (8.7.1/8.7.Gamma.1) id OAA01406; Mon, 23 Oct 1995 14:40:44 -0700 (PDT) Date: Mon, 23 Oct 1995 14:40:44 -0700 (PDT) From: "David M. Meyer 503/346-1747" <meyer@phloem.uoregon.edu> Message-Id: <199510232140.OAA01406@crazy-horse.uoregon.edu> To: mbone Subject: Re: bandwidth questions I've been watching this enlightening discussion unfold over the last week or so, and after I had a few minutes to think about it, I wanted to point out a few issues from my perspective as a consumer of this technology (I guess I'm a consumer...). I've deployed both PIM and DVMRP in fairly large campus environments, and I just wanted to address a few of the many good issues that have been raised: (i). Tunneling (or, virtual topologies) Multicast v. Unicast: I'm not sure which toplogy should be considered the "real" toplolgy, and which one should be considered virtual. However, it is clearly easier to build PIM networks when the unicast toploogy is congruent with the multicast topology (with DVMRP/tunneling, we just impose whatever toplogy we want). However, once you have default and static routes, it's not too hard to tell your router where you want it to RPF to (and, as has been pointed out, if you must have tunneling and PIM, one can do that in a too, possibly with some limitations). Bottom line: If your unicast and multicast topology are not congruent, you need some configuration to get around this. In practice, the difference between DVMRP and PIM in these cases is more about where and how you encode the information about what you want the multicast topology to look like. That being said, I have found that there are not too many places where the unicast and multicast routing topologies differ so widely that I couldn't induce the multicast topology that I wanted with default and/or static routes. Further, this has turned out to be the case for a wide range of applications and polcies. BTW, none of this discounts concerns like Jon's point about the differences in "damage limitation mechanisms". This is well taken; I'll just note that it applies to unicast policies as well. (ii). Protocol Overhead Don't discount the overhead of computing and storing an additional routing table in a big campus network (where we route IP, IPX, Appletalk, and DECnet, as painful as that might sound). In this environment, route calculation and associated storage requirements become non-trivial quickly. (iii). Knobs Someone mentioned that router vendors supply too many knobs, and the canonical instance of this was the ip dvmrp metric command (for Cisco DVMRP tunnels). My only comment here is that, I don't really see this as much different than, say, what happens when an inexperienced stub site administrator injects all the class C's from a /18 into the global routing system, or when some ISP incorrectly creates an AS-SET (it happens, daily). It seems that the issue here is pilot error (I'm sure someone will find a way of injecting their entire Gated unicast routing table into the MBONE..., or whatever). While this is unrelated to the protocol issues at hand, it does point out the need for better abstraction. In any event, such mistakes get made, and while it may be possible to minimize the window for such mistakes by clever engineering at the UI, they will always be with us. Our goals should be to be able to quickly diagnose these problems, and to find ways to minimize their impact. (vi). Pragmatics Finally, I just wanted to mention the pragmatic side of this: It is much easier for me (read: possible) to field multicast services on my existing router fabric; I'd have no chance of providing muticast services to the 200+ subnets I do if I had to do it with mrouteds. So, I conclude that, at least in our case, the Cisco PIM implementation has allowed IP multicast technology to reach many people that would not have otherwise had access to it. From my point of view, that is positive. Thanks, Dave David M. Meyer Voice: +1.503.346.1747 Senior Network Engineer SkyPager: +1.800.580.7929 Office of University Computing Cellular: +1.503.954.1103 Computing Center FAX: +1.503.346.4397 University of Oregon Internet: meyer@ns.uoregon.edu 1225 Kincaid URL: http://ns.uoregon.edu/~meyer Eugene, OR 97403 From list-mgr@ISI.EDU Mon Oct 23 09:22:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23524>; Mon, 23 Oct 1995 16:21:03 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA23517>; Mon, 23 Oct 1995 16:21:02 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id QAA11012; Mon, 23 Oct 1995 16:22:05 -0700 Message-Id: <199510232322.QAA11012@rx7.ee.lbl.gov> To: mbone-na Subject: Intel host minnie.jf.intel.com sending 200kb/s to mbone Date: Mon, 23 Oct 95 16:22:05 PDT From: Van Jacobson <van@ee.lbl.gov> For the past two hours, host minnie.jf.intel.com (134.134.208.170) has been sending 150-200kb/s of ttl 127 multicast in some unknown, non-standard format to 230.134.208.170/8033. The mbone is fairly active today and this stuff is pushing it well above the 500kb/s limit, causing losses both for Intel & for people who play by the rules. Perhaps Intel could do their internal testing at a more appropriate ttl, say 32 or less. - Van From list-mgr@ISI.EDU Mon Oct 23 09:58:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25509>; Mon, 23 Oct 1995 16:59:35 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25478>; Mon, 23 Oct 1995 16:58:46 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA25468>; Mon, 23 Oct 1995 16:58:44 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15803(2)>; Mon, 23 Oct 1995 16:58:30 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 23 Oct 1995 16:58:24 -0700 To: "David M. Meyer 503/346-1747" <meyer@phloem.uoregon.edu> Cc: mbone, deering@parc.xerox.com Subject: Re: bandwidth questions In-Reply-To: meyer's message of Mon, 23 Oct 95 14:40:44 -0800. <199510232140.OAA01406@crazy-horse.uoregon.edu> Date: Mon, 23 Oct 1995 16:58:09 PDT Sender: Steve Deering <deering@parc.xerox.com> From: Steve Deering <deering@parc.xerox.com> Message-Id: <95Oct23.165824pdt.75270@digit.parc.xerox.com> Dave, Thanks for reporting your experiences and observations with respect to ciscos vs. mrouteds for campus environments. I would certainly agree with you that, in domains where the multicast and unicast topologies are congruent, or near enough to congruent that some extra static configuration is acceptable and sufficient, it would be preferable not to incur the costs of running a separate multicast topology-discovery protocol and storing a separate multicast routing table. That has always been my end goal, and DVMRP (in concept, though not in its current concrete instantiation) and MOSPF were based on the approach of extending unicast routing protocols, rather than duplicating them. Conversely, in domains where the the unicast and multicast topologies are still far from congruent, as is the case in the MBone backbone and in many sites that are just starting to experiment with IP multicast or sites whose (unicast) routers do not yet support or have not yet been upgraded to support multicast routing, the ability to do dynamic routing on a separate, partially-tunneled multicast topology has been and, I think, will continue to be for some time yet, an essential transition tool. I hope that transition occurs sooner rather than later, and I am especially interested in hearing how soon the big ISPs would be willing to do native multicast routing so we can get out of the tunnel maintenance business. > Finally, I just wanted to mention the pragmatic > side of this: It is much easier for me (read: > possible) to field multicast services on my > existing router fabric; I'd have no chance of > providing muticast services to the 200+ subnets I > do if I had to do it with mrouteds. Absolutely. Note that the same would be true if your routers all implemented DVMRP or MOSPF, i.e., this is not a PIM-specific observation. Steve From list-mgr@ISI.EDU Mon Oct 23 11:43:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02209>; Mon, 23 Oct 1995 18:50:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01425>; Mon, 23 Oct 1995 18:43:21 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA01418>; Mon, 23 Oct 1995 18:43:20 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id SAA28644; Mon, 23 Oct 1995 18:43:12 -0700 Date: Mon, 23 Oct 1995 18:43:12 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199510240143.SAA28644@greatdane.cisco.com> To: deering@parc.xerox.com (Steve Deering) Cc: "David M. Meyer 503/346-1747" <meyer@phloem.uoregon.edu>, mbone Subject: Re: bandwidth questions I hope that transition occurs sooner rather than later, and I am especially interested in hearing how soon the big ISPs would be willing to do native multicast routing so we can get out of the tunnel maintenance business. As I tried to explain, one of the outstanding roadblocks (there are many) is the public perception that Mbone delivery _should_ be via a tunnel. Anything you can do to correct this perception would be most helpful. This would focus more attention on the ISP's in deploying native multicast. The challenge then becomes stabilizing our 11.0 code sufficiently for general deployment. This will only be accelerated by added market pressure for it... I do think it would greatly facilitate phased transition to "native multicast" in large, administratively-decentralized internets like my company's internal internet. We look forward to Xerox updating their routers. ;-) Tony From list-mgr@ISI.EDU Mon Oct 23 16:56:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09593>; Mon, 23 Oct 1995 19:58:26 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09400>; Mon, 23 Oct 1995 19:56:26 -0700 Received: from hendrix.cc.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA09389>; Mon, 23 Oct 1995 19:56:22 -0700 Received: (from ccshag@localhost) by hendrix.cc.missouri.edu (8.6.12/8.6.12) id VAA00605; Mon, 23 Oct 1995 21:56:24 -0500 Date: Mon, 23 Oct 1995 21:56:24 -0500 (CDT) From: "Paul 'Shag' Walmsley" <ccshag@cclabs.missouri.edu> X-Sender: ccshag@hendrix.cc.missouri.edu To: mbone Subject: Re: bandwidth questions In-Reply-To: <199510240143.SAA28644@greatdane.cisco.com> Message-Id: <Pine.SGI.3.91.951023215008.594B-100000@hendrix.cc.missouri.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 23 Oct 1995, Tony Li wrote: > This would focus more attention on the ISP's in deploying native > multicast. The challenge then becomes stabilizing our 11.0 code > sufficiently for general deployment. This will only be accelerated by > added market pressure for it... Personally, I've seen representatives from cisco and 3Com posting about their multicast-capable software to the list. Now, I'd like to hear from the Bay Networks people that (I sincerely hope) are out there: what's the status of multicast routing support in your software releases? To what extent and in what timeframe does Bay intend to support multicast routing? (By the way, I've tried calling Bay pre-sales information and asking the salesdroids about multicast support. After about 20 minutes of rummaging around the company for someone who knew what multicast was, they were able to tell me that it was in the most recent software releases, but they weren't able to tell me anything else about it, such as what routing scheme it used, or -- assuming DVMRP -- whether it pruned or not.) - Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu> "Praise and blame alike mean nothing." -- Virginia Woolf From list-mgr@ISI.EDU Tue Oct 24 00:14:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10171>; Mon, 23 Oct 1995 20:14:26 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id <AA10161>; Mon, 23 Oct 1995 20:14:25 -0700 Received: by chops.icp.net id <20701>; Mon, 23 Oct 1995 23:14:19 +0100 From: Sean Doran <smd@icp.net> To: mbone-na, van@ee.lbl.gov Subject: Re: Intel host minnie.jf.intel.com sending 200kb/s to mbone Message-Id: <95Oct23.231419+0100_edt.20701+25@chops.icp.net> Date: Mon, 23 Oct 1995 23:14:19 +0100 Aha, this explains a great deal. Thanks Van; once again your vigilance comes in handy. Sean. From list-mgr@ISI.EDU Mon Oct 23 20:39:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12631>; Mon, 23 Oct 1995 21:42:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12589>; Mon, 23 Oct 1995 21:38:57 -0700 Received: from arctos.LCS.MIT.EDU.LCS.MIT.EDU (arctos.lcs.mit.edu) by venera.isi.edu (5.65c/5.61+local-22) id <AA12582>; Mon, 23 Oct 1995 21:38:55 -0700 Received: by arctos.LCS.MIT.EDU.LCS.MIT.EDU (4.1/SMI-4.1) id AA13064; Tue, 24 Oct 95 00:39:13 EDT Message-Id: <9510240439.AA13064@arctos.LCS.MIT.EDU.LCS.MIT.EDU> To: "Paul 'Shag' Walmsley" <ccshag@cclabs.missouri.edu> Cc: mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Mon, 23 Oct 1995 21:56:24 CDT." <Pine.SGI.3.91.951023215008.594B-100000@hendrix.cc.missouri.edu> Date: Tue, 24 Oct 1995 00:39:12 -0400 From: Ed Hurley <hurley@Goldilocks.LCS.MIT.EDU> i just pulled up bay networks' homepage (www.baynetworks.com) and did a search on multicasting. i found a press release from january 24 which outlines their *intended* strategy and timeline for providing multicasting. http://www.baynetworks.com/News/Press/9501241.html and another document which seems to imply they currently support DVMRP. http://www.baynetworks.com/Products/Routers/Protocols/Bridge/IP2.html not quite what you're looking for, but maybe of interest. -ed From list-mgr@ISI.EDU Mon Oct 23 15:52:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14788>; Mon, 23 Oct 1995 22:54:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14760>; Mon, 23 Oct 1995 22:51:46 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA14753>; Mon, 23 Oct 1995 22:51:44 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id WAA11499; Mon, 23 Oct 1995 22:52:47 -0700 Message-Id: <199510240552.WAA11499@rx7.ee.lbl.gov> To: mbone Subject: Intel still sending 200-220kb/s to mbone Date: Mon, 23 Oct 95 22:52:47 PDT From: Van Jacobson <van@ee.lbl.gov> Host minnie.jf.intel.com (134.134.208.170) has now been sending 200-220kb/s continuously for more than 10 hours. When I sent a message about this 8 hours ago, the only response seemed to be that their average bandwidth went up by 20kb/s. They are sending some unknown, unannounced, non-standard format to an illegal address (230.134.208.170/8033) at a rate well above the MBone guidelines. The MBone is quite busy this week and their data is pushing it over the 500kb/s limit, causing losses both for Intel & for people who play by the rules. If you're having trouble receiving the Shuttle video or the Internet Fair, just remember "Intel Inside". - Van From list-mgr@ISI.EDU Mon Oct 23 16:08:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15417>; Mon, 23 Oct 1995 23:09:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15360>; Mon, 23 Oct 1995 23:08:36 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA15353>; Mon, 23 Oct 1995 23:08:35 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA04936; Mon, 23 Oct 1995 23:08:01 -0700 Date: Mon, 23 Oct 1995 23:08:01 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199510240608.XAA04936@greatdane.cisco.com> To: ccshag@cclabs.missouri.edu ("Paul 'Shag' Walmsley") Cc: mbone Subject: Re: bandwidth questions Personally, I've seen representatives from cisco and 3Com posting about their multicast-capable software to the list. Now, I'd like to hear from the Bay Networks people that (I sincerely hope) are out there: what's the status of multicast routing support in your software releases? To what extent and in what timeframe does Bay intend to support multicast routing? One data point: 8.10 supports DVMRP. Sorry, I have no info about whether or not it does pruning. This is second hand information, so... Tony From list-mgr@ISI.EDU Mon Oct 23 16:30:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15961>; Mon, 23 Oct 1995 23:31:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15915>; Mon, 23 Oct 1995 23:28:43 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA15908>; Mon, 23 Oct 1995 23:28:40 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id XAA05498; Mon, 23 Oct 1995 23:30:22 -0700 Message-Id: <199510240630.XAA05498@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Van Jacobson <van@ee.lbl.gov> Cc: mbone Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: Your message of "Mon, 23 Oct 1995 22:52:47 PDT." <199510240552.WAA11499@rx7.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Oct 1995 23:30:21 -0700 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Is there a way to control this type of situation ? Amancio >>> Van Jacobson said: > Host minnie.jf.intel.com (134.134.208.170) has now been sending > 200-220kb/s continuously for more than 10 hours. When I sent a > message about this 8 hours ago, the only response seemed to be > that their average bandwidth went up by 20kb/s. > > They are sending some unknown, unannounced, non-standard format > to an illegal address (230.134.208.170/8033) at a rate well above > the MBone guidelines. The MBone is quite busy this week and > their data is pushing it over the 500kb/s limit, causing > losses both for Intel & for people who play by the rules. If > you're having trouble receiving the Shuttle video or the Internet > Fair, just remember "Intel Inside". > > - Van From list-mgr@ISI.EDU Mon Oct 23 17:05:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16783>; Tue, 24 Oct 1995 00:07:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16752>; Tue, 24 Oct 1995 00:04:36 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA16745>; Tue, 24 Oct 1995 00:04:35 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id AAA11540; Tue, 24 Oct 1995 00:05:36 -0700 Message-Id: <199510240705.AAA11540@rx7.ee.lbl.gov> To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: mbone Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: Your message of Mon, 23 Oct 95 23:30:21 PDT. Date: Tue, 24 Oct 95 00:05:35 PDT From: Van Jacobson <van@ee.lbl.gov> If there were univeral deployment of pruning multicast, Intel would only be hurting themselves (with pruning, if no one is listening the data goes nowhere). But less than half the mbone currently supports pruning and, despite increasingly strident rants from Bill Fenner & me, the rate of deployment seems to be going down. I believe that Bill & Steve Deering plan to address this deployment problem in their hierarchical multicast distribution. The current situation is backwards compatible in the sense that a pruning router always delivers everything to older (or cisco PIM) non-pruning routers. This means that if there's only one non-pruning router per country, all multicast is delivered to all the world. I believe the level-2 (inter-domain) multicast rule is going to be that external traffic arriving at a domain is pruned unless at least one member in the domain has announced interest in the group. This means that the older, non-pruning implementations will get ignored rather than coddled so there should be more incentive to upgrade & the people who don't upgrade will only hurt themselves rather than harm the network. In the interim, I think the only solution is to point out when people are behaving antisocially. So far the MBone community has been remarkably civilized and polite. In the past 4 years, I recall only one incident that persisted for more than 12 hours after an initial complaint, and that one was cleared up in 24 hours. Usually there is terrific cooperation between the people running the local lan, the site's main networking people & the off-site tunnel peers. Often I've seen nicely coordinated reponses like "if you can't fix things on the local wire, we'll shut down the local tunnel until you can since if we don't shut down your tunnel, our provider will disconnect our entire site." I realize there's not much hope that the considerate & decent behavior will continue, particularly with things like Intel & Microsoft getting interested in the MBone. But it sure has been productive & satisfying while it lasted. - Van From list-mgr@ISI.EDU Mon Oct 23 15:52:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14788>; Mon, 23 Oct 1995 22:54:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14760>; Mon, 23 Oct 1995 22:51:46 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA14753>; Mon, 23 Oct 1995 22:51:44 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id WAA11499; Mon, 23 Oct 1995 22:52:47 -0700 Message-Id: <199510240552.WAA11499@rx7.ee.lbl.gov> To: mbone Subject: Intel still sending 200-220kb/s to mbone Date: Mon, 23 Oct 95 22:52:47 PDT From: Van Jacobson <van@ee.lbl.gov> Host minnie.jf.intel.com (134.134.208.170) has now been sending 200-220kb/s continuously for more than 10 hours. When I sent a message about this 8 hours ago, the only response seemed to be that their average bandwidth went up by 20kb/s. They are sending some unknown, unannounced, non-standard format to an illegal address (230.134.208.170/8033) at a rate well above the MBone guidelines. The MBone is quite busy this week and their data is pushing it over the 500kb/s limit, causing losses both for Intel & for people who play by the rules. If you're having trouble receiving the Shuttle video or the Internet Fair, just remember "Intel Inside". - Van From list-mgr@ISI.EDU Mon Oct 23 17:30:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01748>; Tue, 24 Oct 1995 04:06:50 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01232>; Tue, 24 Oct 1995 03:57:22 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA01218>; Tue, 24 Oct 1995 03:57:01 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14689(8)>; Tue, 24 Oct 1995 00:30:49 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Tue, 24 Oct 1995 00:30:30 -0700 To: Tony Li <tli@cisco.com> Cc: mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Mon, 23 Oct 95 18:43:12 PDT." <199510240143.SAA28644@greatdane.cisco.com> Date: Tue, 24 Oct 1995 00:30:30 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct24.003030pdt.177478@crevenia.parc.xerox.com> In message <199510240143.SAA28644@greatdane.cisco.com> you write: >We look forward to Xerox updating their routers. ;-) Actually, we have been considering it; however, we seem to have woefully underpowered hardware. In fact, just this past weekend I installed a new sparcstation mrouter to replace a tunnel, since the router that the tunnel crossed couldn't even handle the unicast traffic involved. This is, of course, saying nothing about Cisco in particular; it's just to point out that software upgrades aren't the only answer and that aging infrastructure will continue to be a problem. Bill From list-mgr@ISI.EDU Tue Oct 24 03:53:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03306>; Tue, 24 Oct 1995 04:58:48 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03231>; Tue, 24 Oct 1995 04:55:04 -0700 Received: from bbnplanet.com (poblano.near.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA03222>; Tue, 24 Oct 1995 04:55:03 -0700 Subject: Re: bandwidth questions To: deering@parc.xerox.com, tli@cisco.com, dino@cisco.com Date: Tue, 24 Oct 1995 07:53:47 -0400 (EDT) From: Henry Clark <hclark@bbnplanet.com> Cc: mbone In-Reply-To: <95Oct23.165824pdt.75270@digit.parc.xerox.com> from "Steve Deering" at Oct 23, 95 04:58:09 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1492 Message-Id: <9510240753.aa24084@poblano.bbnplanet.com> > I am especially interested in hearing > how soon the big ISPs would be willing to do native multicast routing so > we can get out of the tunnel maintenance business. I suspect the big ISPs understand what "the MBone problem" is. Note that: - the MBone does some changing to the economic models which ISPs use to price their service - there are lots of sites whose current physical topology will break in the midst of significant multicast traffic - the multicast software in routers isn't ready for prime-time (my favorite example being cisco process-switching DVMRP until 11.0, and 11.0 isn't quite ready for general deployment) - some amount of hardware may have to be upgraded (for example, if a site is using an IGS with 8.3 which happily forwards unicast packets, then they'll need to make a real out-of-pocket expenditure for native multicast routing), and this needs to be worked into budget cycles - there are no effective management tools ready for multicast (other than the occasional van-o-gram :-)) - multicast is still far too sensitive to one user making a naive mistake and trashing a large part of the Internet (at least with unicast, they have to work harder at it) I know that alot of work is going on behind the scenes to fix these problems. But, note that just getting rid of the tunnels won't fix the problem, though. Introducing hierarchy into the multicast routing system will be the only way for it to scale to large numbers. henry From list-mgr@ISI.EDU Mon Oct 23 16:08:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15417>; Mon, 23 Oct 1995 23:09:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15360>; Mon, 23 Oct 1995 23:08:36 -0700 Received: from greatdane.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA15353>; Mon, 23 Oct 1995 23:08:35 -0700 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA04936; Mon, 23 Oct 1995 23:08:01 -0700 Date: Mon, 23 Oct 1995 23:08:01 -0700 From: Tony Li <tli@cisco.com> Message-Id: <199510240608.XAA04936@greatdane.cisco.com> To: ccshag@cclabs.missouri.edu ("Paul 'Shag' Walmsley") Cc: mbone Subject: Re: bandwidth questions Personally, I've seen representatives from cisco and 3Com posting about their multicast-capable software to the list. Now, I'd like to hear from the Bay Networks people that (I sincerely hope) are out there: what's the status of multicast routing support in your software releases? To what extent and in what timeframe does Bay intend to support multicast routing? One data point: 8.10 supports DVMRP. Sorry, I have no info about whether or not it does pruning. This is second hand information, so... Tony From list-mgr@ISI.EDU Tue Oct 24 12:21:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04421>; Tue, 24 Oct 1995 05:27:02 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04388>; Tue, 24 Oct 1995 05:25:39 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA04381>; Tue, 24 Oct 1995 05:25:37 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA01197>; Tue, 24 Oct 1995 05:24:29 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.13517-0@bells.cs.ucl.ac.uk>; Tue, 24 Oct 1995 12:21:54 +0000 To: Henry Clark <hclark@bbnplanet.com> Cc: mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Tue, 24 Oct 95 07:53:47 -0400." <9510240753.aa24084@poblano.bbnplanet.com> Date: Tue, 24 Oct 95 12:21:48 +0000 Message-Id: <9724.814537308@cs.ucl.ac.uk> From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> >> I am especially interested in hearing >> how soon the big ISPs would be willing to do native multicast routing so >> we can get out of the tunnel maintenance business. this is a well phrased and timed message.... >I suspect the big ISPs understand what "the MBone problem" is. Note that: >- the MBone does some changing to the economic models which ISPs use to > price their service depends - there is one provider I know of that has potential backbone that exceeds subscriber loop capacity and could support mbone traffic for audio calls and audio conferences right now without having to change their economic model....given they provide a significant percentaghe of the transmission capacity (though not all) to the other providers in the country I am thinking of, this could go a long way to thinning out the number of ISPs... >- there are lots of sites whose current physical topology will break in > the midst of significant multicast traffic too true - but straight IP unicast growth with the unpredictable web sites springing up could do that too! >- the multicast software in routers isn't ready for prime-time (my favorite > example being cisco process-switching DVMRP until 11.0, and 11.0 isn't > quite ready for general deployment) really really true - we (idmr wg) have tried and tried to ghet this fixed....) >- some amount of hardware may have to be upgraded (for example, if a site > is using an IGS with 8.3 which happily forwards unicast packets, then > they'll need to make a real out-of-pocket expenditure for native multicast > routing), and this needs to be worked into budget cycles but the buy in costs ay be justified by getting a system to do RSVP at the same time.... >- there are no effective management tools ready for multicast (other than > the occasional van-o-gram :-)) and unplugging the offending site (this is the UK mandate...) >- multicast is still far too sensitive to one user making a naive mistake > and trashing a large part of the Internet (at least with unicast, they > have to work harder at it) >I know that alot of work is going on behind the scenes to fix these >problems. >But, note that just getting rid of the tunnels won't fix the problem, though. >Introducing hierarchy into the multicast routing system will be the only >way for it to scale to large numbers. agree totally - but what hierarchy - geographic?, mrouted provider? do we want hierarchical class D addresses>? ... jon From list-mgr@ISI.EDU Tue Oct 24 04:32:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04714>; Tue, 24 Oct 1995 05:36:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04653>; Tue, 24 Oct 1995 05:34:13 -0700 Received: from foghorn.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA04646>; Tue, 24 Oct 1995 05:34:11 -0700 Received: from localhost (young@localhost) by foghorn.reston.mci.net (8.6.12/8.6.9) with SMTP id IAA23447; Tue, 24 Oct 1995 08:32:52 -0400 Message-Id: <199510241232.IAA23447@foghorn.reston.mci.net> X-Authentication-Warning: foghorn.reston.mci.net: young owned process doing -bs X-Authentication-Warning: foghorn.reston.mci.net: Host localhost didn't use HELO protocol To: "Paul 'Shag' Walmsley" <ccshag@cclabs.missouri.edu> Cc: mbone, young@mci.net Subject: Re: bandwidth questions In-Reply-To: Your message of "Mon, 23 Oct 1995 21:56:24 CDT." <Pine.SGI.3.91.951023215008.594B-100000@hendrix.cc.missouri.edu> Date: Tue, 24 Oct 1995 08:32:52 -0400 From: "Jeff Young" <young@mci.net> i know it works, i saw it at interop (really). during the atlanta show (the one i participated in) and for a number of previous shows, 3com and Bay have demonstrated multicasting abilities. In the atlanta show, a Bay router took a feed from an mci dec alpha and a 3com took a feed from a sun sparc at gatech. after a few early glitches, things worked well - including pruning. i'd leave the specifics to the vendor reps: marten terpstra robin littlefield bay cyndi jung tom mauffer 3com as for isp's stepping up to the plate to run native multicasting, i can say that it's something that mci is testing (in a number of ways). to say anything more would be premature. Jeff Young young@mci.net From list-mgr@ISI.EDU Mon Oct 23 16:30:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15961>; Mon, 23 Oct 1995 23:31:44 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15915>; Mon, 23 Oct 1995 23:28:43 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA15908>; Mon, 23 Oct 1995 23:28:40 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id XAA05498; Mon, 23 Oct 1995 23:30:22 -0700 Message-Id: <199510240630.XAA05498@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Van Jacobson <van@ee.lbl.gov> Cc: mbone Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: Your message of "Mon, 23 Oct 1995 22:52:47 PDT." <199510240552.WAA11499@rx7.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Oct 1995 23:30:21 -0700 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Is there a way to control this type of situation ? Amancio >>> Van Jacobson said: > Host minnie.jf.intel.com (134.134.208.170) has now been sending > 200-220kb/s continuously for more than 10 hours. When I sent a > message about this 8 hours ago, the only response seemed to be > that their average bandwidth went up by 20kb/s. > > They are sending some unknown, unannounced, non-standard format > to an illegal address (230.134.208.170/8033) at a rate well above > the MBone guidelines. The MBone is quite busy this week and > their data is pushing it over the 500kb/s limit, causing > losses both for Intel & for people who play by the rules. If > you're having trouble receiving the Shuttle video or the Internet > Fair, just remember "Intel Inside". > > - Van From list-mgr@ISI.EDU Tue Oct 24 06:56:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05290>; Tue, 24 Oct 1995 06:00:11 -0700 Received: from cythera.unb.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA05283>; Tue, 24 Oct 1995 06:00:09 -0700 Received: from cythera.unb.ca (cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.6.12/8.6.5) with SMTP id JAA00616; Tue, 24 Oct 1995 09:56:21 -0300 Date: Tue, 24 Oct 1995 09:56:21 -0300 (ADT) From: "Dwight E. Spencer" <spencer@unb.ca> To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: Van Jacobson <van@ee.lbl.gov>, mbone-na Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: <199510240630.XAA05498@rah.star-gate.com> Message-Id: <Pine.SOL.3.91.951024095359.662f-100000@cythera.unb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 24 Oct 1995, Amancio Hasty Jr. wrote: > Is there a way to control this type of situation ? perhaps by having all the home phone numbers of mbone "routers" so we can call someone and say "hey, one of your users is killing us, get rid of him -puuhlease-" a few of us irc types have begun to do this, and yves lepage and i who look after (more or less) irc and the mbone here in canada have each other's home phone, and I've even been to his place. (though, i won't mention what is behind his house ;) dwight. ---------------------------------------------------------------------------- Dwight E. Spencer Canada's Community Access Network eMail: spencer@unb.ca, "C-Net" Server Administrator UNB, Fredericton, NB, Canada Phone: +1 506 453 4614 Url: http://cnet.unb.ca/cspace/staff/dspencer/ From list-mgr@ISI.EDU Mon Oct 23 17:05:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16783>; Tue, 24 Oct 1995 00:07:17 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16752>; Tue, 24 Oct 1995 00:04:36 -0700 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA16745>; Tue, 24 Oct 1995 00:04:35 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id AAA11540; Tue, 24 Oct 1995 00:05:36 -0700 Message-Id: <199510240705.AAA11540@rx7.ee.lbl.gov> To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: mbone Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: Your message of Mon, 23 Oct 95 23:30:21 PDT. Date: Tue, 24 Oct 95 00:05:35 PDT From: Van Jacobson <van@ee.lbl.gov> If there were univeral deployment of pruning multicast, Intel would only be hurting themselves (with pruning, if no one is listening the data goes nowhere). But less than half the mbone currently supports pruning and, despite increasingly strident rants from Bill Fenner & me, the rate of deployment seems to be going down. I believe that Bill & Steve Deering plan to address this deployment problem in their hierarchical multicast distribution. The current situation is backwards compatible in the sense that a pruning router always delivers everything to older (or cisco PIM) non-pruning routers. This means that if there's only one non-pruning router per country, all multicast is delivered to all the world. I believe the level-2 (inter-domain) multicast rule is going to be that external traffic arriving at a domain is pruned unless at least one member in the domain has announced interest in the group. This means that the older, non-pruning implementations will get ignored rather than coddled so there should be more incentive to upgrade & the people who don't upgrade will only hurt themselves rather than harm the network. In the interim, I think the only solution is to point out when people are behaving antisocially. So far the MBone community has been remarkably civilized and polite. In the past 4 years, I recall only one incident that persisted for more than 12 hours after an initial complaint, and that one was cleared up in 24 hours. Usually there is terrific cooperation between the people running the local lan, the site's main networking people & the off-site tunnel peers. Often I've seen nicely coordinated reponses like "if you can't fix things on the local wire, we'll shut down the local tunnel until you can since if we don't shut down your tunnel, our provider will disconnect our entire site." I realize there's not much hope that the considerate & decent behavior will continue, particularly with things like Intel & Microsoft getting interested in the MBone. But it sure has been productive & satisfying while it lasted. - Van From list-mgr@ISI.EDU Tue Oct 24 15:35:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06447>; Tue, 24 Oct 1995 06:40:46 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06390>; Tue, 24 Oct 1995 06:38:20 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA06383>; Tue, 24 Oct 1995 06:38:17 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id OAA21685; Tue, 24 Oct 1995 14:30:57 +0100 Message-Id: <199510241330.OAA21685@piraya.electrum.kth.se> To: Tony Li <tli@cisco.com> Cc: deering@parc.xerox.com (Steve Deering), "David M. Meyer 503/346-1747" <meyer@phloem.uoregon.edu>, mbone, e93_mda@it.kth.se Subject: Re: bandwidth questions In-Reply-To: Your message of "Mon, 23 Oct 1995 18:43:12 MST." <199510240143.SAA28644@greatdane.cisco.com> Date: Tue, 24 Oct 1995 14:35:33 +0100 From: Magnus <e93_mda@it.kth.se> Hi! I think we better talk in terms of Mbone connectivity then tunnels or whatever.. Stable 11.0 code in terms of multicasting and present Mbone router technology would be really nice. Magnus From list-mgr@ISI.EDU Tue Oct 24 15:44:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06678>; Tue, 24 Oct 1995 06:45:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06532>; Tue, 24 Oct 1995 06:43:55 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA06525>; Tue, 24 Oct 1995 06:43:54 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id OAA21911; Tue, 24 Oct 1995 14:39:24 +0100 Message-Id: <199510241339.OAA21911@piraya.electrum.kth.se> To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: Van Jacobson <van@ee.lbl.gov>, mbone, e93_mda@it.kth.se Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: Your message of "Mon, 23 Oct 1995 23:30:21 MST." <199510240630.XAA05498@rah.star-gate.com> Date: Tue, 24 Oct 1995 14:44:00 +0100 From: Magnus <e93_mda@it.kth.se> There is a way to control such behaiviour.... cut their Mbone connectivity if they simply does not behaive after being informed. Magnus From list-mgr@ISI.EDU Tue Oct 24 06:09:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07521>; Tue, 24 Oct 1995 07:13:59 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07474>; Tue, 24 Oct 1995 07:13:08 -0700 Received: from lobster.wellfleet.com by venera.isi.edu (5.65c/5.61+local-22) id <AA07466>; Tue, 24 Oct 1995 07:13:02 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA28559; Tue, 24 Oct 95 10:11:54 EDT Received: from zaphod.engeast by BayNetworks.com (4.1/SMI-4.1) id AA11002; Tue, 24 Oct 95 10:12:51 EDT From: stephen@BayNetworks.com (Stephen Ostrowski) Message-Id: <9510241412.AA11002@BayNetworks.com> Subject: Re: bandwidth questions To: ccshag@cclabs.missouri.edu (Paul 'Shag' Walmsley) Date: Tue, 24 Oct 1995 10:09:14 -0400 (EDT) Cc: mbone In-Reply-To: <Pine.SGI.3.91.951023215008.594B-100000@hendrix.cc.missouri.edu> from "Paul 'Shag' Walmsley" at Oct 23, 95 09:56:24 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1841 Hi, I am one of the engineers at Bay who is working on our multicast protocols. In 8.10 (it's been shipping for a while), we supported DVMRP which was based off of mrouted 2.2 (i.e. no pruning). In 9.00 (which has been shipping for about a couple of weeks) our DVMRP is based off of mrouted 3.3 (and thus supports pruning). Also with 9.00 we support IGMPv2. We are planning to support CBT and PIM in future releases. We have been running DVMRP in our network for the past year or so with the MBONE tunnel. If anyone has any more questions, feel free to ask. - Stephen > > On Mon, 23 Oct 1995, Tony Li wrote: > > > This would focus more attention on the ISP's in deploying native > > multicast. The challenge then becomes stabilizing our 11.0 code > > sufficiently for general deployment. This will only be accelerated by > > added market pressure for it... > > Personally, I've seen representatives from cisco and 3Com posting about > their multicast-capable software to the list. Now, I'd like to hear from > the Bay Networks people that (I sincerely hope) are out there: what's the > status of multicast routing support in your software releases? To what > extent and in what timeframe does Bay intend to support multicast routing? > > (By the way, I've tried calling Bay pre-sales information and asking the > salesdroids about multicast support. After about 20 minutes of rummaging > around the company for someone who knew what multicast was, they were > able to tell me that it was in the most recent software releases, but > they weren't able to tell me anything else about it, such as what > routing scheme it used, or -- assuming DVMRP -- whether it pruned or not.) > > > - Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu> > "Praise and blame alike mean nothing." -- Virginia Woolf > > From list-mgr@ISI.EDU Tue Oct 24 06:13:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07544>; Tue, 24 Oct 1995 07:14:27 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07490>; Tue, 24 Oct 1995 07:13:29 -0700 Received: from cssun.mathcs.emory.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA07483>; Tue, 24 Oct 1995 07:13:26 -0700 Received: (from cheung@localhost) by cssun.mathcs.emory.edu (8.6.10/8.6.9-940818.01cssun) id KAA25217; Tue, 24 Oct 1995 10:13:19 -0400 Date: Tue, 24 Oct 1995 10:13:19 -0400 From: Shun Yan Cheung <cheung@mathcs.emory.edu> Message-Id: <199510241413.KAA25217@cssun.mathcs.emory.edu> To: e93_mda@it.kth.se Subject: Re: Intel still sending 200-220kb/s to mbone Cc: mbone Content-Length: 584 >From list-mgr@ISI.EDU Tue Oct 24 10:04 EDT 1995 >To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> >Cc: Van Jacobson <van@ee.lbl.gov>, mbone@ISI.EDU, e93_mda@it.kth.se >Subject: Re: Intel still sending 200-220kb/s to mbone >Date: Tue, 24 Oct 1995 14:44:00 +0100 >From: Magnus <e93_mda@it.kth.se> > >There is a way to control such behaiviour.... cut their Mbone connectivity if >they simply does not behaive after being informed. > >Magnus What if the violator is not a leaf on the MBone topology ? All MBones sites that receive feed from the violating site are also cut off... sy From list-mgr@ISI.EDU Tue Oct 24 16:31:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08169>; Tue, 24 Oct 1995 07:33:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08130>; Tue, 24 Oct 1995 07:31:49 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA08121>; Tue, 24 Oct 1995 07:31:48 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id PAA22977; Tue, 24 Oct 1995 15:27:23 +0100 Message-Id: <199510241427.PAA22977@piraya.electrum.kth.se> To: Shun Yan Cheung <cheung@mathcs.emory.edu> Cc: e93_mda@it.kth.se, mbone Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: Your message of "Tue, 24 Oct 1995 10:13:19 -0400." <199510241413.KAA25217@cssun.mathcs.emory.edu> Date: Tue, 24 Oct 1995 15:31:59 +0100 From: Magnus <e93_mda@it.kth.se> Well, if they are feeding other people.. the larger reason they should behaive! What you do point out is a weakness of todays topology, where some of the core routers is also feeding a local net(s). As the Mbone grows, the less people know eachother well enougth for behaiving properly. Magnus From list-mgr@ISI.EDU Tue Oct 24 06:44:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08999>; Tue, 24 Oct 1995 07:57:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08855>; Tue, 24 Oct 1995 07:54:00 -0700 Received: from maelstrom.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA08847>; Tue, 24 Oct 1995 07:53:50 -0700 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.7.1/8.6.6) id KAA00671; Tue, 24 Oct 1995 10:44:46 -0400 (GMT-0400) Message-Id: <199510241444.KAA00671@maelstrom.cc.mcgill.ca> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Yves Lepage <yves@CC.McGill.CA> Date: Tue, 24 Oct 95 10:44:44 -0400 To: Magnus <e93_mda@it.kth.se> Subject: Re: Intel still sending 200-220kb/s to mbone Cc: Shun Yan Cheung <cheung@mathcs.emory.edu>, mbone Reply-To: yves@cc.mcgill.ca References: <199510241427.PAA22977@piraya.electrum.kth.se> Hello, >Well, if they are feeding other people.. the larger reason they should >behaive! >What you do point out is a weakness of todays topology, where some of the core >routers is also feeding a local net(s). As the Mbone grows, the less people >know eachother well enougth for behaiving properly. I am unsure that people need to know each other as a requirement for behaving. The limitrate option of the post-3.3 mrouted could also be a good mean of avoiding such events. If they were set on all the big routers of course. regards, Yves Lepage From list-mgr@ISI.EDU Tue Oct 24 07:14:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09630>; Tue, 24 Oct 1995 08:15:20 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09604>; Tue, 24 Oct 1995 08:14:17 -0700 Received: from margit.scri.fsu.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA09595>; Tue, 24 Oct 1995 08:14:15 -0700 Received: by margit.scri.fsu.edu (AIX 3.2/UCB 5.64/4.03) id AA31866; Tue, 24 Oct 1995 11:14:05 -0400 Date: Tue, 24 Oct 1995 11:14:05 -0400 From: hays@margit.scri.fsu.edu (Ken Hays) Message-Id: <9510241514.AA31866@margit.scri.fsu.edu> To: Shun Yan Cheung <cheung@mathcs.emory.edu> Cc: mbone In-Reply-To: <199510241413.KAA25217@cssun.mathcs.emory.edu> Subject: Re: Intel still sending 200-220kb/s to mbone Reply-To: Ken Hays <hays@scri.fsu.edu> Yes, down strteam folks would get hit. Of course, this is would provide some input from people that might know the offending folks phone number about "what is wrong with the mbone" and at least potentially some pressure for the offending folks to get their act cleaned up. Later, Ken --------------- Prompting Message Fragment Follows --------------- Shun Yan Cheung wrote on 24-Oct-95 at 10:13:19 -0400, in part: >>From list-mgr@ISI.EDU Tue Oct 24 10:04 EDT 1995 >>To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> >>Cc: Van Jacobson <van@ee.lbl.gov>, mbone@ISI.EDU, e93_mda@it.kth.se >>Subject: Re: Intel still sending 200-220kb/s to mbone >>Date: Tue, 24 Oct 1995 14:44:00 +0100 >>From: Magnus <e93_mda@it.kth.se> >> >>There is a way to control such behaiviour.... cut their Mbone connectivity if >>they simply does not behaive after being informed. >> >>Magnus > >What if the violator is not a leaf on the MBone topology ? >All MBones sites that receive feed from the violating site >are also cut off... > >sy From list-mgr@ISI.EDU Tue Oct 24 15:30:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10792>; Tue, 24 Oct 1995 08:44:21 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10758>; Tue, 24 Oct 1995 08:43:05 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA10751>; Tue, 24 Oct 1995 08:43:03 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA02047>; Tue, 24 Oct 1995 08:42:07 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.23155-0@bells.cs.ucl.ac.uk>; Tue, 24 Oct 1995 15:30:52 +0000 From: Mark Handley <M.Handley@cs.ucl.ac.uk> Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: yves@cc.mcgill.ca Cc: Magnus <e93_mda@it.kth.se>, Shun Yan Cheung <cheung@mathcs.emory.edu>, mbone Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: Your message of "Tue, 24 Oct 95 10:44:44 -0400." <199510241444.KAA00671@maelstrom.cc.mcgill.ca> Date: Tue, 24 Oct 95 15:30:43 +0000 Message-Id: <3294.814548643@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >I am unsure that people need to know each other as a requirement for behaving. > >The limitrate option of the post-3.3 mrouted could also be a good mean of >avoiding such events. If they were set on all the big routers of course. Interesting point - rate_limit is normally set symmetrically, and only rate limits the traffic that can be sent down a link. It shouldn't be too difficult to rate_limit the traffic received *up* a link so your ISPs can protect themselves from high rate leaves without requiring the cooperation of the leaf site administrator. Of course cooperation is better, but... Mark From list-mgr@ISI.EDU Tue Oct 24 17:55:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11351>; Tue, 24 Oct 1995 08:56:28 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11318>; Tue, 24 Oct 1995 08:55:27 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA11311>; Tue, 24 Oct 1995 08:55:24 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id QAA25161; Tue, 24 Oct 1995 16:50:54 +0100 Message-Id: <199510241550.QAA25161@piraya.electrum.kth.se> To: yves@cc.mcgill.ca Cc: Magnus <e93_mda@it.kth.se>, Shun Yan Cheung <cheung@mathcs.emory.edu>, mbone Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: Your message of "Tue, 24 Oct 1995 10:44:44 -0400." <199510241444.KAA00671@maelstrom.cc.mcgill.ca> Date: Tue, 24 Oct 1995 16:55:31 +0100 From: Magnus <e93_mda@it.kth.se> I agree that the ratelimit option is a step forward in killing of some of these streams, at least partly... but haveing non-pruneing routers in a global DVMRP cloud is probably a larger problem. The ratelimit has a default value of 500kbps. The current lack of a complete set of monitoring/administration tools does not really help either. Today only few machines/OS combinations is up-to-date with current mrouted software. If someone has a good tool to continously monitor streams and thier bandwith, please let me know. Magnus From list-mgr@ISI.EDU Tue Oct 24 18:06:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12092>; Tue, 24 Oct 1995 09:10:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11959>; Tue, 24 Oct 1995 09:07:01 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA11951>; Tue, 24 Oct 1995 09:06:58 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id RAA25487; Tue, 24 Oct 1995 17:02:21 +0100 Message-Id: <199510241602.RAA25487@piraya.electrum.kth.se> To: Mark Handley <M.Handley@cs.ucl.ac.uk> Cc: yves@cc.mcgill.ca, Magnus <e93_mda@it.kth.se>, Shun Yan Cheung <cheung@mathcs.emory.edu>, mbone Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: Your message of "Tue, 24 Oct 1995 15:30:43 GMT." <3294.814548643@cs.ucl.ac.uk> Date: Tue, 24 Oct 1995 17:06:58 +0100 From: Magnus <e93_mda@it.kth.se> Hmm... maybe it's not a bad idea... giving people higher bandwidth if they behave properly.... then it would be interesting to behave. Magnus From list-mgr@ISI.EDU Tue Oct 24 02:26:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13204>; Tue, 24 Oct 1995 09:28:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13144>; Tue, 24 Oct 1995 09:27:33 -0700 Received: from hermes.intel.com by venera.isi.edu (5.65c/5.61+local-22) id <AA13135>; Tue, 24 Oct 1995 09:27:28 -0700 Received: from argus.intel.com by hermes.intel.com (5.65/10.0i); Tue, 24 Oct 95 09:27:18 -0700 Received: by argus.intel.com (5.65/10.0i); Tue, 24 Oct 95 09:26:54 -0700 From: sedayao@argus.intel.com (Jeffrey C. Sedayao) Message-Id: <9510241626.AA05050@argus.intel.com> Subject: Re: Intel still sending 200-220kb/s to mbone To: van@ee.lbl.gov (Van Jacobson) Date: Tue, 24 Oct 95 9:26:54 PDT Cc: mbone, lou@ssd.intel.com, tod@ibeam.intel.com In-Reply-To: <199510240552.WAA11499@rx7.ee.lbl.gov> from "Van Jacobson" at Oct 23, 95 10:52:47 pm X-Mailer: ELM [version 2.4dev PL66] Mime-Version: 1.0 Content-Type: text Content-Length: 849 > Host minnie.jf.intel.com (134.134.208.170) has now been sending > 200-220kb/s continuously for more than 10 hours. When I sent a > message about this 8 hours ago, the only response seemed to be > that their average bandwidth went up by 20kb/s. > They are sending some unknown, unannounced, non-standard format > to an illegal address (230.134.208.170/8033) at a rate well above > the MBone guidelines. The MBone is quite busy this week and > their data is pushing it over the 500kb/s limit, causing > losses both for Intel & for people who play by the rules. If > you're having trouble receiving the Shuttle video or the Internet > Fair, just remember "Intel Inside". I'll track down the people within Intel doing this and ask them to stop. Sorry for the inconvenience. > - Van -- Jeff Sedayao Intel Corporation sedayao@argus.intel.com From list-mgr@ISI.EDU Tue Oct 24 09:47:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14249>; Tue, 24 Oct 1995 09:48:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14190>; Tue, 24 Oct 1995 09:47:04 -0700 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA14183>; Tue, 24 Oct 1995 09:47:01 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.7.1/8.7.1) id MAA29255; Tue, 24 Oct 1995 12:47:06 -0400 (EDT) Date: Tue, 24 Oct 1995 12:30:07 From: "Dave Thaler" <thalerd@eecs.umich.edu> Subject: Intel still sending 200-220kb/s to mbone Message-Id: <19951024123007.0@dip.eecs.umich.edu> To: mbone One idea we're working on at Merit is to allow (via SNMP) dynamically adding/deleting an administrative boundary. Thus, it would be possible for an administrator to make a policy decision like: "We will not route traffic across link X from any source (or, alternatively, for any group) sending data at a sustained rate >= 200 kbps" Thus, a separate daemon could poll (via SNMP) the various mrouted's in its administrative domain. If it finds any offenders (such as the one being discussed at Intel), it can instantiate a "scoped" boundary (which would of course initiate a prune towards the source from that point). This could be used at mrouted's connected to the backbone (e.g. mbone.merit.edu) to prevent anyone under Merit from flooding the rest of the MBone. Any comments on this would be appreciated. We have sample code and are planning on running a few local tests in the near future. Dave Thaler From list-mgr@ISI.EDU Tue Oct 24 13:56:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14776>; Tue, 24 Oct 1995 09:58:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14663>; Tue, 24 Oct 1995 09:57:06 -0700 Received: from chops.icp.net by venera.isi.edu (5.65c/5.61+local-22) id <AA14656>; Tue, 24 Oct 1995 09:57:04 -0700 Received: by chops.icp.net id <20701>; Tue, 24 Oct 1995 12:56:23 +0100 From: Sean Doran <smd@icp.net> To: e93_mda@it.kth.se, tli@cisco.com Subject: Re: bandwidth questions Cc: deering@parc.xerox.com, mbone, meyer@phloem.uoregon.edu Message-Id: <95Oct24.125623+0100_edt.20701+31@chops.icp.net> Date: Tue, 24 Oct 1995 12:56:12 +0100 >Stable 11.0 code ... would be really nice. I had planned to start rolling out some 11.0 into the SprintLink backbone last weekend, but operational issues and a surprise social visit got in the way. The next obvious window of opportunity is the weekend after this coming weekend, although it could happen before then. (Besides, someone else might decide to go push the envelope of IOS technology by deploying it in their backbone first, and watching what happens, making notes of bugs, deploying fast fixes and the like). Naturally, once 11.0 unicast is reasonably stable and moderately well-deployed in the backbone, we can start playing with native multicast. The point, however, is that the only way in practice to get code which is stable enough to deploy in the core of the Internet is still actually deploying it and fixing all the bugs that uncovers. Sean. From list-mgr@ISI.EDU Tue Oct 24 03:04:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15179>; Tue, 24 Oct 1995 10:05:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15139>; Tue, 24 Oct 1995 10:04:40 -0700 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA15132>; Tue, 24 Oct 1995 10:04:37 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id KAA06251; Tue, 24 Oct 1995 10:04:19 -0700 Message-Id: <199510241704.KAA06251@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: "Dave Thaler" <thalerd@eecs.umich.edu> Cc: mbone Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: Your message of "Tue, 24 Oct 1995 12:30:07." <19951024123007.0@dip.eecs.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Oct 1995 10:04:18 -0700 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> I like it :) If the mbone is to survive we will need rapid response to stop speeders on the mbone . BTW: My ISP already controlls me in such a fashion if I hug the net too much he just slimply throttles my net connection like cutting off one of ISDN channels . Is a long story however I did have problems when I first brought mrouted on my Freebsd box. Amancio >>> "Dave Thaler" said: > One idea we're working on at Merit is to allow (via SNMP) dynamically > adding/deleting an administrative boundary. Thus, it would be possible > for an administrator to make a policy decision like: > > "We will not route traffic across link X from any source (or, alternatively , > for any group) sending data at a sustained rate >= 200 kbps" > > Thus, a separate daemon could poll (via SNMP) the various mrouted's in its > administrative domain. If it finds any offenders (such as the one being > discussed at Intel), it can instantiate a "scoped" boundary (which would > of course initiate a prune towards the source from that point). > > This could be used at mrouted's connected to the backbone (e.g. > mbone.merit.edu) to prevent anyone under Merit from flooding the rest of > the MBone. > > Any comments on this would be appreciated. We have sample code and > are planning on running a few local tests in the near future. > > Dave Thaler From list-mgr@ISI.EDU Tue Oct 24 03:07:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15388>; Tue, 24 Oct 1995 10:09:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15324>; Tue, 24 Oct 1995 10:08:24 -0700 Received: from osi-east.es.net by venera.isi.edu (5.65c/5.61+local-22) id <AA15316>; Tue, 24 Oct 1995 10:08:22 -0700 Received: from viipuri.nersc.gov by osi-east.es.net with ESnet SMTP (PP); Tue, 24 Oct 1995 10:07:53 -0700 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA04471; Tue, 24 Oct 95 10:07:48 PDT Date: Tue, 24 Oct 95 10:07:48 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9510241707.AA04471@viipuri.nersc.gov> To: sedayao@argus.intel.com, van@ee.lbl.gov Subject: Re: Intel still sending 200-220kb/s to mbone Cc: lou@ssd.intel.com, mbone, tod@ibeam.jf.intel.com > I'll track down the people within Intel doing this and ask them to > stop. > > Sorry for the inconvenience. Bit late for that ...they've already been found. >From: Mojtaba Mirashrafi <Mojtaba_Mirashrafi@ccm.jf.intel.com> Message-ID: <Tue, 24 Oct 95 08:50:03 PDT_9@ccm.jf.intel.com> To: ari@interserve.com Subject: Re: Intel still sending 200-220kb/s to mbone Text item: Very sorry. I checked in the lab just now. The mrouted machine was by mistake turned on. I turned it off. Mojy Ari@ES.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 ~~RECOM Technologies Inc.~~ From list-mgr@ISI.EDU Tue Oct 24 09:11:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15682>; Tue, 24 Oct 1995 10:14:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15655>; Tue, 24 Oct 1995 10:13:43 -0700 Received: from foghorn.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA15647>; Tue, 24 Oct 1995 10:13:41 -0700 Received: from localhost (young@localhost) by foghorn.reston.mci.net (8.6.12/8.6.9) with SMTP id NAA25375; Tue, 24 Oct 1995 13:11:11 -0400 Message-Id: <199510241711.NAA25375@foghorn.reston.mci.net> X-Authentication-Warning: foghorn.reston.mci.net: young owned process doing -bs X-Authentication-Warning: foghorn.reston.mci.net: Host localhost didn't use HELO protocol To: Mark Handley <M.Handley@cs.ucl.ac.uk> Cc: yves@cc.mcgill.ca, Magnus <e93_mda@it.kth.se>, Shun Yan Cheung <cheung@mathcs.emory.edu>, mbone Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: Your message of "Tue, 24 Oct 1995 15:30:43 -0000." <3294.814548643@cs.ucl.ac.uk> Date: Tue, 24 Oct 1995 13:11:11 -0400 From: "Jeff Young" <young@mci.net> why not just apply a boundary to the traffic at the intel/isp border? that will not affect any of the folks at intel who are legitimately watching nasa or any of the intel feeds downstream. just a thought. Jeff Young young@mci.net > Return-Path: list-mgr@ISI.EDU > Received: from venera.isi.edu (venera.isi.edu [128.9.0.32]) by postoffice.reston.mci.net (8.6.12/8.6.6) with SMTP id MAA07573; Tue, 24 Oct 1995 12:57:20 -0400 > Received: by venera.isi.edu (5.65c/5.61+local-22) > id <AA10792>; Tue, 24 Oct 1995 08:44:21 -0700 > Received: by venera.isi.edu (5.65c/5.61+local-22) > id <AA10758>; Tue, 24 Oct 1995 08:43:05 -0700 > Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) > id <AA10751>; Tue, 24 Oct 1995 08:43:03 -0700 > Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) > id <AA02047>; Tue, 24 Oct 1995 08:42:07 -0700 > Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP > id <g.23155-0@bells.cs.ucl.ac.uk>; Tue, 24 Oct 1995 15:30:52 +0000 > From: Mark Handley <M.Handley@cs.ucl.ac.uk> > Organisation: University College London, CS Dept. > Phone: +44 171 419 3666 > To: yves@cc.mcgill.ca > Cc: Magnus <e93_mda@it.kth.se>, Shun Yan Cheung <cheung@mathcs.emory.edu>, > mbone@ISI.EDU > Subject: Re: Intel still sending 200-220kb/s to mbone > In-Reply-To: Your message of "Tue, 24 Oct 95 10:44:44 -0400." <199510241444.KAA00671@maelstrom.cc.mcgill.ca> > Date: Tue, 24 Oct 95 15:30:43 +0000 > Message-Id: <3294.814548643@cs.ucl.ac.uk> > Sender: M.Handley@cs.ucl.ac.uk > > > >I am unsure that people need to know each other as a requirement for behaving. > > > >The limitrate option of the post-3.3 mrouted could also be a good mean of > >avoiding such events. If they were set on all the big routers of course. > > Interesting point - rate_limit is normally set symmetrically, and only > rate limits the traffic that can be sent down a link. It shouldn't be > too difficult to rate_limit the traffic received *up* a link so your > ISPs can protect themselves from high rate leaves without requiring > the cooperation of the leaf site administrator. > > Of course cooperation is better, but... > > Mark From list-mgr@ISI.EDU Tue Oct 24 03:09:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17476>; Tue, 24 Oct 1995 10:47:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17376>; Tue, 24 Oct 1995 10:46:09 -0700 Received: from ormail.intel.com by venera.isi.edu (5.65c/5.61+local-22) id <AA17368>; Tue, 24 Oct 1995 10:46:07 -0700 Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0t7nQA-000UhDC; Tue, 24 Oct 95 10:45 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0t7nQ0-000twdC; Tue, 24 Oct 95 10:45 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Tue, 24 Oct 95 10:45:41 PDT Date: Tue, 24 Oct 95 10:09:00 PDT From: Mojtaba Mirashrafi <Mojtaba_Mirashrafi@ccm.jf.intel.com> Message-Id: <Tue, 24 Oct 95 10:45:32 PDT_1@ccm.hf.intel.com> To: mbone Subject: Mbone Traffic My apologies for the traffic on the MBONE. The mrouted machine in the lab was turned on by mistake thereby forwarding traffic to the MBONE. Mojy From list-mgr@ISI.EDU Tue Oct 24 17:23:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17726>; Tue, 24 Oct 1995 10:53:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17398>; Tue, 24 Oct 1995 10:46:17 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA17391>; Tue, 24 Oct 1995 10:46:15 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA03815>; Tue, 24 Oct 1995 10:46:08 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.28833-0@bells.cs.ucl.ac.uk>; Tue, 24 Oct 1995 17:23:32 +0000 From: Mark Handley <M.Handley@cs.ucl.ac.uk> Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: Jeff Young <young@mci.net> Cc: yves@cc.mcgill.ca, Magnus <e93_mda@it.kth.se>, Shun Yan Cheung <cheung@mathcs.emory.edu>, mbone Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: Your message of "Tue, 24 Oct 95 13:11:11 -0400." <199510241711.NAA25375@foghorn.reston.mci.net> Date: Tue, 24 Oct 95 17:23:25 +0000 Message-Id: <3636.814555405@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >why not just apply a boundary to the traffic at the >intel/isp border? that will not affect any of the >folks at intel who are legitimately watching nasa >or any of the intel feeds downstream. > >just a thought. To prevent weird black holes just appearing all over the place, the folks at PARC put in the restriction that you can only add scope boundaries for addresses in the range 239.X.Y.Z. I think I prefer it that way, rather that spend all my time trying to diagnose black holes due to someone setting an admin scope boundary on 224.2.0.1 or some such address. On the other hand, there are cases when it would be nice to do... Mark From list-mgr@ISI.EDU Tue Oct 24 09:52:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18136>; Tue, 24 Oct 1995 10:57:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18101>; Tue, 24 Oct 1995 10:56:47 -0700 Received: from foghorn.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA18094>; Tue, 24 Oct 1995 10:56:45 -0700 Received: from localhost (young@localhost) by foghorn.reston.mci.net (8.6.12/8.6.9) with SMTP id NAA25525; Tue, 24 Oct 1995 13:52:38 -0400 Message-Id: <199510241752.NAA25525@foghorn.reston.mci.net> X-Authentication-Warning: foghorn.reston.mci.net: young owned process doing -bs X-Authentication-Warning: foghorn.reston.mci.net: Host localhost didn't use HELO protocol To: Mark Handley <M.Handley@cs.ucl.ac.uk> Cc: yves@cc.mcgill.ca, Magnus <e93_mda@it.kth.se>, Shun Yan Cheung <cheung@mathcs.emory.edu>, mbone Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: Your message of "Tue, 24 Oct 1995 17:23:25 -0000." <3636.814555405@cs.ucl.ac.uk> Date: Tue, 24 Oct 1995 13:52:38 -0400 From: "Jeff Young" <young@mci.net> learn something every day. but as a service provider, i'm not as inclined to just shut down a feed as i would be to shut down an offending stream. give us the rope i say! we'll hang ourselves. or something like that... Jeff Young young@mci.net > Return-Path: M.Handley@cs.ucl.ac.uk > Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by postoffice.reston.mci.net (8.6.12/8.6.6) with SMTP id NAA08597 for <young@mci.net>; Tue, 24 Oct 1995 13:27:23 -0400 > Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP > id <g.28833-0@bells.cs.ucl.ac.uk>; Tue, 24 Oct 1995 17:23:32 +0000 > From: Mark Handley <M.Handley@cs.ucl.ac.uk> > Organisation: University College London, CS Dept. > Phone: +44 171 419 3666 > To: Jeff Young <young@mci.net> > cc: yves@cc.mcgill.ca, Magnus <e93_mda@it.kth.se>, > Shun Yan Cheung <cheung@mathcs.emory.edu>, mbone@isi.edu > Subject: Re: Intel still sending 200-220kb/s to mbone > In-reply-to: Your message of "Tue, 24 Oct 95 13:11:11 -0400." <199510241711.NAA25375@foghorn.reston.mci.net> > Date: Tue, 24 Oct 95 17:23:25 +0000 > Message-ID: <3636.814555405@cs.ucl.ac.uk> > Sender: M.Handley@cs.ucl.ac.uk > > > >why not just apply a boundary to the traffic at the > >intel/isp border? that will not affect any of the > >folks at intel who are legitimately watching nasa > >or any of the intel feeds downstream. > > > >just a thought. > > To prevent weird black holes just appearing all over the place, the > folks at PARC put in the restriction that you can only add scope > boundaries for addresses in the range 239.X.Y.Z. > > I think I prefer it that way, rather that spend all my time trying to > diagnose black holes due to someone setting an admin scope boundary on > 224.2.0.1 or some such address. On the other hand, there are cases > when it would be nice to do... > > Mark > > From list-mgr@ISI.EDU Tue Oct 24 10:10:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18959>; Tue, 24 Oct 1995 11:12:06 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18879>; Tue, 24 Oct 1995 11:10:23 -0700 Received: from odin.UU.NET by venera.isi.edu (5.65c/5.61+local-22) id <AA18867>; Tue, 24 Oct 1995 11:10:19 -0700 Received: by odin.UU.NET (maildrop) id QQzmwe10017; Tue, 24 Oct 1995 14:10:11 -0400 Date: Tue, 24 Oct 1995 14:10:11 -0400 Message-Id: <QQzmwe10017.199510241810@odin.UU.NET> From: Henry Kilmer <hank@uunet.uu.net> To: yves@cc.mcgill.ca Cc: Magnus <e93_mda@it.kth.se>, Shun Yan Cheung <cheung@mathcs.emory.edu>, mbone Subject: Re: Intel still sending 200-220kb/s to mbone In-Reply-To: <199510241444.KAA00671@maelstrom.cc.mcgill.ca> References: <199510241427.PAA22977@piraya.electrum.kth.se> <199510241444.KAA00671@maelstrom.cc.mcgill.ca> Yves Lepage writes: >Hello, > >>Well, if they are feeding other people.. the larger reason they should >behaive! >>What you do point out is a weakness of todays topology, where some of the core >>routers is also feeding a local net(s). As the Mbone grows, the less people >>know eachother well enougth for behaiving properly. > >I am unsure that people need to know each other as a requirement for behaving. > >The limitrate option of the post-3.3 mrouted could also be a good mean of >avoiding such events. If they were set on all the big routers of course. I've thought about this but it is not always easy to determine what the limit should be and how you determine that value. Any ideas? -Hank From list-mgr@ISI.EDU Tue Oct 24 10:28:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20450>; Tue, 24 Oct 1995 11:41:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20372>; Tue, 24 Oct 1995 11:39:25 -0700 Received: from maelstrom.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA20362>; Tue, 24 Oct 1995 11:39:23 -0700 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.7.1/8.6.6) id OAA01266; Tue, 24 Oct 1995 14:28:51 -0400 (GMT-0400) Message-Id: <199510241828.OAA01266@maelstrom.cc.mcgill.ca> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Yves Lepage <yves@CC.McGill.CA> Date: Tue, 24 Oct 95 14:28:50 -0400 To: Henry Kilmer <hank@uunet.uu.net> Subject: Re: Intel still sending 200-220kb/s to mbone Cc: yves@cc.mcgill.ca, Magnus <e93_mda@it.kth.se>, Shun Yan Cheung <cheung@mathcs.emory.edu>, mbone Reply-To: yves@cc.mcgill.ca References: <199510241427.PAA22977@piraya.electrum.kth.se> <199510241444.KAA00671@maelstrom.cc.mcgill.ca> <QQzmwe10017.199510241810@odin.UU.NET> Hello, >I've thought about this but it is not always easy to determine what the limit >should be and how you determine that value. Any ideas? I *think* I read somewhere that no single broadcast should send more than 128kbps of combined audio and video data. And that the total MBONE bandwdith consumption should not exceed 512kbps. I think that limiting to 128kbps seems pretty reasonable to me. Escpecially with vic that makes bandwidth usage lower. Yves Lepage From list-mgr@ISI.EDU Tue Oct 24 05:09:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21957>; Tue, 24 Oct 1995 12:10:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AB21830>; Tue, 24 Oct 1995 12:09:10 -0700 Received: from bridge2.NSD.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA21821>; Tue, 24 Oct 1995 12:09:09 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA25619 (5.65c/IDA-1.4.4nsd for <mbone@isi.edu>); Tue, 24 Oct 1995 12:09:07 -0700 Received: by jaspar.NSD.3Com.COM id AA02523 (5.65c/IDA-1.4.4-910730); Tue, 24 Oct 1995 12:09:05 -0700 From: "Cyndi M. Jung" <cmj@NSD.3Com.COM> Message-Id: <199510241909.AA02523@jaspar.NSD.3Com.COM> Subject: Re: bandwidth questions To: stephen@baynetworks.com (Stephen Ostrowski) Date: Tue, 24 Oct 1995 12:09:05 -0700 (PDT) Cc: mbone In-Reply-To: <9510241412.AA11002@BayNetworks.com> from "Stephen Ostrowski" at Oct 24, 95 10:09:14 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3617 Yep, I saw it at Interop too - the Bay routers were running 3.3, according to our routers' neighbor information. All the routers were running DVMRP, so the entire show was native-multicast enabled. Connection to the MBone was via two tunnels, one to MCI, another to GaTech, and we did have some rather spectacular glitches to start with, but that's why we were there. Actually, multicast was the highlight of the show - for me, at least - since our code had only begun shipping to beta test sites. We were able to find a performance problem, which lead to a pruning problem in the mrouted code (all derivative implementations), which led to a couple of solutions which will benefit everyone involved - I'm not sure if anybody at Cisco is aware of the problem, but since it only shows up where redundant routers have a downstream router on their common interface, it has probably never occured in actual mrouted configurations. We've worked with Bill Fenner to implement both the preferred solution and the necessary solution (for interworking with older versions on pruning mrouted), and this has been very rewarding. Besides DVMRP 3.5, we also support IGMPv2, and have implemented MOSPF for those of our customers with larger, more complex networks where they are already running OSPF. The real jewel here is MOSPF - there's no better way to find the optimal route than knowing the entire topology, which MOSPF does by virtue of the link state data base. It took me a while to understand this, but where DVMRP, PIM and MOSPF all select a route back to the source, only MOSPF computes routes to the receivers - both DVMRP and PIM simply flood until pruned. Cyndi > > Hi, > > I am one of the engineers at Bay who is working on our multicast > protocols. In 8.10 (it's been shipping for a while), we supported > DVMRP which was based off of mrouted 2.2 (i.e. no pruning). In > 9.00 (which has been shipping for about a couple of weeks) our > DVMRP is based off of mrouted 3.3 (and thus supports pruning). Also > with 9.00 we support IGMPv2. > > We are planning to support CBT and PIM in future releases. > > We have been running DVMRP in our network for the past year or so > with the MBONE tunnel. > > If anyone has any more questions, feel free to ask. > > - Stephen > > > > > > On Mon, 23 Oct 1995, Tony Li wrote: > > > > > This would focus more attention on the ISP's in deploying native > > > multicast. The challenge then becomes stabilizing our 11.0 code > > > sufficiently for general deployment. This will only be accelerated by > > > added market pressure for it... > > > > Personally, I've seen representatives from cisco and 3Com posting about > > their multicast-capable software to the list. Now, I'd like to hear from > > the Bay Networks people that (I sincerely hope) are out there: what's the > > status of multicast routing support in your software releases? To what > > extent and in what timeframe does Bay intend to support multicast routing? > > > > (By the way, I've tried calling Bay pre-sales information and asking the > > salesdroids about multicast support. After about 20 minutes of rummaging > > around the company for someone who knew what multicast was, they were > > able to tell me that it was in the most recent software releases, but > > they weren't able to tell me anything else about it, such as what > > routing scheme it used, or -- assuming DVMRP -- whether it pruned or not.) > > > > > > - Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu> > > "Praise and blame alike mean nothing." -- Virginia Woolf > > > > > > From list-mgr@ISI.EDU Tue Oct 24 08:56:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03621>; Tue, 24 Oct 1995 15:57:10 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03572>; Tue, 24 Oct 1995 15:56:08 -0700 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA03564>; Tue, 24 Oct 1995 15:56:07 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id PAA18759; Tue, 24 Oct 1995 15:56:05 -0700 Date: Tue, 24 Oct 1995 15:56:05 -0700 From: Dino Farinacci <dino@cisco.com> Message-Id: <199510242256.PAA18759@stilton.cisco.com> To: cmj@NSD.3Com.COM Cc: stephen@baynetworks.com, mbone In-Reply-To: "Cyndi M. Jung"'s message of Tue, 24 Oct 1995 12:09:05 -0700 (PDT) <199510241909.AA02523@jaspar.NSD.3Com.COM> Subject: bandwidth questions >> MOSPF does by virtue of the link state data base. It took me a while to >> understand this, but where DVMRP, PIM and MOSPF all select a route back >> to the source, only MOSPF computes routes to the receivers - both DVMRP and >> PIM simply flood until pruned. Correction: 1) MOSPF computes forward shortest paths (from source to receivers) when they are located within an area. For sources outside of an area or AS, the MOSPF routers compute reverse shortest path trees. 2) PIM does flood and prune only for dense-mode groups. Sparse-mode groups use explicit joins (prune state is the default initial state). Dino From list-mgr@ISI.EDU Wed Oct 25 08:54:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02983>; Wed, 25 Oct 1995 08:56:57 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02891>; Wed, 25 Oct 1995 08:54:46 -0700 Received: from hub.ubc.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA02878>; Wed, 25 Oct 1995 08:54:43 -0700 Received: (from ean@localhost) by hub.ubc.ca (8.6.12/1.14) id IAA16018 for mbone@isi.edu; Wed, 25 Oct 1995 08:54:38 -0700 X400-Received: by /PRMD=ca/ADMD=/C=/; Relayed; Wed, 25 Oct 1995 8:54:36 UTC-0700 X400-Received: by /PRMD=ca/ADMD=/C=/; Relayed; Wed, 25 Oct 1995 8:54:18 UTC-0700 Date: Wed, 25 Oct 1995 8:54:18 UTC-0700 X400-Originator: hay@ucs.ubc.ca X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=ca/ADMD=/C=/;951025085418] Content-Identifier: 40368 From: Marilyn Hay <hay@ucs.ubc.ca> To: mbone Message-Id: <"40368*hay@ucs.ubc.ca"@MHS> Subject: Connectivity Problems Mime-Version: 1.0 (Generated by Ean X.400 to MIME gateway) Hi, I have people here reporting that they have been cut off this morning from the Global Learning session being broadcast from Monterey. I do not have the address of the broadcasting site as it has disappeared off the session list. The site here is mbone.ubc.ca and it is seeing the normal default channels and very few participants on the NASA channel. Would someone please take a look as to why this broadcast stopped getting to us? Thanks and take care, Marilyn Hay voice mail: 604-822-5438 Network Management Centre fax mail: 604-822-5116 University of British Columbia e-mail: Marilyn.Hay@ubc.ca Vancouver, B.C. Canada V6T 1Z2 From list-mgr@ISI.EDU Wed Oct 25 10:34:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05190>; Wed, 25 Oct 1995 09:39:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05140>; Wed, 25 Oct 1995 09:38:08 -0700 Received: from cythera.unb.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA05132>; Wed, 25 Oct 1995 09:38:04 -0700 Received: from cythera.unb.ca (cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.6.12/8.6.5) with SMTP id NAA08888; Wed, 25 Oct 1995 13:34:10 -0300 Date: Wed, 25 Oct 1995 13:34:10 -0300 (ADT) From: "Dwight E. Spencer" <spencer@unb.ca> To: Marilyn Hay <hay@ucs.ubc.ca> Cc: mbone Subject: Re: Connectivity Problems In-Reply-To: <"40368*hay@ucs.ubc.ca"@MHS> Message-Id: <Pine.SOL.3.91.951025133140.662o-100000@cythera.unb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 25 Oct 1995, Marilyn Hay wrote: > channels and very few participants on the NASA channel. Would someone > please take a look as to why this broadcast stopped getting to us? My feed has indeed slowed down updates as well. Joining a session usually resulted in members appearing almost immediately. This could be a global problem, or possibly my feeds own feed (cythera.unb.ca <- tempest.cc.mcgill.ca <- a-wing.jvnc.net) 7443 root 33 0 1504K 972K sleep 1:52 0.79% 0.85% mrouted My mrouted is not bogging my kernel down, so I don't suspect that it is a route advertising flood as we had a few times in the last few weeks. dwight s. ---------------------------------------------------------------------------- Dwight E. Spencer Canada's Community Access Network eMail: spencer@unb.ca, "C-Net" Server Administrator UNB, Fredericton, NB, Canada Phone: +1 506 453 4614 Url: http://cnet.unb.ca/cspace/staff/dspencer/ From list-mgr@ISI.EDU Wed Oct 25 18:07:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10083>; Wed, 25 Oct 1995 11:09:45 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10001>; Wed, 25 Oct 1995 11:08:34 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA09994>; Wed, 25 Oct 1995 11:08:33 -0700 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA23718>; Wed, 25 Oct 1995 11:08:09 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.01063-0@bells.cs.ucl.ac.uk>; Wed, 25 Oct 1995 18:07:45 +0000 From: Mark Handley <M.Handley@cs.ucl.ac.uk> Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: mbone Subject: mrouted crashes Date: Wed, 25 Oct 95 18:07:45 +0000 Message-Id: <5894.814644465@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk At least 4 mrouted's here in the UK appear to have crashed pretty much simultaneously around 5:30pm UTC (the machines stayed up - just mrouted crashed). Of the two I have access to (an HP running mrouted 3.3 and a Sun runing mrouted 3.5) I don't see anything out of the ordinary in the logs. I don't see any unusal routing tables now I've restarted them either. Anyone else have problems or see anything odd in their logs? Mark From list-mgr@ISI.EDU Wed Oct 25 12:31:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11467>; Wed, 25 Oct 1995 11:36:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11377>; Wed, 25 Oct 1995 11:35:02 -0700 Received: from di.ufpe.br (recife.di.ufpe.br) by venera.isi.edu (5.65c/5.61+local-22) id <AA11359>; Wed, 25 Oct 1995 11:34:41 -0700 Received: from paulista.di.ufpe.br ([150.161.2.201]) by di.ufpe.br (4.1/SMI-4.1) id AA05990; Wed, 25 Oct 95 15:36:59 EST Received: by paulista.di.ufpe.br (4.1/SMI-4.1) id AA04293; Wed, 25 Oct 95 15:31:16 EST Date: Wed, 25 Oct 1995 15:31:16 -0300 (EST) From: Fernando Jose de Aguiar Sodre <fjas@di.ufpe.br> Subject: Questions To: Marilyn Hay <hay@ucs.ubc.ca> Cc: mbone In-Reply-To: <"40368*hay@ucs.ubc.ca"@MHS> Message-Id: <Pine.3.89.9510251551.B4134-0100000@paulista> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Mboners, I'm new in this list and I don't know if I need any hardware in my LAN to do a transmission. What and How ? Do you help me ? Thanks, Fernando Sodre. On Wed, 25 Oct 1995, Marilyn Hay wrote: > Hi, > > I have people here reporting that they have been cut off this morning > from the Global Learning session being broadcast from Monterey. I do > not have the address of the broadcasting site as it has disappeared > off the session list. > > The site here is mbone.ubc.ca and it is seeing the normal default > channels and very few participants on the NASA channel. Would someone > please take a look as to why this broadcast stopped getting to us? > > Thanks and take care, > > Marilyn Hay voice mail: 604-822-5438 > Network Management Centre fax mail: 604-822-5116 > University of British Columbia e-mail: Marilyn.Hay@ubc.ca > Vancouver, B.C. Canada V6T 1Z2 > > From list-mgr@ISI.EDU Wed Oct 25 18:38:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11755>; Wed, 25 Oct 1995 11:40:05 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11701>; Wed, 25 Oct 1995 11:39:30 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA11688>; Wed, 25 Oct 1995 11:39:21 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id TAA01178; Wed, 25 Oct 1995 19:38:52 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id SAA08209; Wed, 25 Oct 1995 18:38:48 GMT Date: Wed, 25 Oct 1995 18:38:46 +0000 (GMT) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Mark Handley <M.Handley@cs.ucl.ac.uk> Cc: mbone Subject: Re: mrouted crashes In-Reply-To: <5894.814644465@cs.ucl.ac.uk> Message-Id: <Pine.SV4.3.91.951025183736.7150J-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 25 Oct 1995, Mark Handley wrote: > > At least 4 mrouted's here in the UK appear to have crashed pretty much > simultaneously around 5:30pm UTC (the machines stayed up - just > mrouted crashed). Of the two I have access to (an HP running mrouted > 3.3 and a Sun runing mrouted 3.5) I don't see anything out of the > ordinary in the logs. I don't see any unusal routing tables now I've > restarted them either. > > Anyone else have problems or see anything odd in their logs? Well at about 1750 UTC I saw things like warning - received wrong graft ack from 193.63.106.100 from my upstream mrouted. None of the mrouteds in and around Edinburgh have gone down though. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Wed Oct 25 07:21:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19751>; Wed, 25 Oct 1995 14:22:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19721>; Wed, 25 Oct 1995 14:21:48 -0700 Received: from skat.usc.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA19712>; Wed, 25 Oct 1995 14:21:46 -0700 Received: from alshain.usc.edu (root@alshain.usc.edu [128.125.142.68]) by skat.usc.edu (8.6.10/8.6.12+usc) with ESMTP id OAA13870 for <mbone@isi.edu>; Wed, 25 Oct 1995 14:21:45 -0700 Received: from alshain.usc.edu (lkimes@localhost.usc.edu [127.0.0.1]) by alshain.usc.edu (8.6.12/8.6.7+ucs) with ESMTP id OAA06124 for <mbone@isi.edu>; Wed, 25 Oct 1995 14:21:45 -0700 Message-Id: <199510252121.OAA06124@alshain.usc.edu> X-Mailer: exmh version 1.6.2 7/18/95 To: mbone Subject: USC tunnel problem's Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Oct 1995 14:21:44 -0700 From: "Lance 'Moof' Kimes" <lkimes@ucs.usc.edu> Who is the mbone administrator at ISI now that Steve has left? Lance Kimes USC MBone administrator lkimes@ucs.usc.edu From list-mgr@ISI.EDU Wed Oct 25 15:37:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27370>; Wed, 25 Oct 1995 16:38:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27324>; Wed, 25 Oct 1995 16:37:23 -0700 Received: from all-purpose-gunk.near.net by venera.isi.edu (5.65c/5.61+local-22) id <AA27317>; Wed, 25 Oct 1995 16:37:22 -0700 Received: (from jhawk@localhost) by all-purpose-gunk.near.net (8.7.1/8.7.1) id TAA02782; Wed, 25 Oct 1995 19:37:14 -0400 (EDT) Date: Wed, 25 Oct 1995 19:37:14 -0400 (EDT) Message-Id: <199510252337.TAA02782@all-purpose-gunk.near.net> To: mbone Subject: Re: mrouted crashes From: John Hawkinson <jhawk@near.net> Are those of you whose mrouteds are crashing all running 2.x by any chance? Dino added some code to log when lots of routes are received from a particular peer, and I consistently (like once or twice a day) get messages like: %DVMRP-1-ROUTEHOG: Receiving 11343 routes from 198.112.8.2 (Tunnel0) in the last 00:01:05 from each of the 2.x mrouteds my cisco tunnels w/, but not from any of the 3.x mrouteds. I also consistently don't see any more than 2.5k routes in the table, even immediately after the above such syslogs. There was some speculation that this was related to poisoned reverse behavior differing in 2.x and 3.x. I dunno... --jhawk From list-mgr@ISI.EDU Wed Oct 25 10:06:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28619>; Wed, 25 Oct 1995 17:07:31 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28574>; Wed, 25 Oct 1995 17:06:54 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA28565>; Wed, 25 Oct 1995 17:06:52 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14546(2)>; Wed, 25 Oct 1995 17:06:45 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 25 Oct 1995 17:06:31 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Mark Handley <M.Handley@cs.ucl.ac.uk> Cc: mbone Subject: Re: mrouted crashes In-Reply-To: Your message of "Wed, 25 Oct 95 11:07:45 PDT." <5894.814644465@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Oct 1995 17:06:27 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct25.170631pdt.177478@crevenia.parc.xerox.com> In message <5894.814644465@cs.ucl.ac.uk> you write: >At least 4 mrouted's here in the UK appear to have crashed pretty much >simultaneously around 5:30pm UTC (the machines stayed up - just >mrouted crashed). Did mrouted crash or hang? If it crashed, did it leave a core dump lying around? Interestingly enough, 3.3 and 3.5 both have potential core-dump problems with responding to mtrace requests (you really should upgrade to 3.4 and 3.6...) Bill From list-mgr@ISI.EDU Wed Oct 25 11:55:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10120>; Wed, 25 Oct 1995 18:57:52 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10024>; Wed, 25 Oct 1995 18:56:01 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA10017>; Wed, 25 Oct 1995 18:55:59 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14508(1)>; Wed, 25 Oct 1995 18:55:47 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 25 Oct 1995 18:55:41 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: John Hawkinson <jhawk@near.net> Cc: mbone, multicast-support@cisco.com Subject: Re: mrouted crashes In-Reply-To: Your message of "Wed, 25 Oct 95 16:37:14 PDT." <199510252337.TAA02782@all-purpose-gunk.near.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Oct 1995 18:55:40 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct25.185541pdt.177478@crevenia.parc.xerox.com> In message <199510252337.TAA02782@all-purpose-gunk.near.net> you write: >Dino added some code to log when lots of routes are received from a >particular peer, and I consistently (like once or twice a day) get >messages like: > >%DVMRP-1-ROUTEHOG: Receiving 11343 routes from 198.112.8.2 (Tunnel0) >in the last 00:01:05 > >from each of the 2.x mrouteds my cisco tunnels w/, but not from any of >the 3.x mrouteds. There was a change in the meaning of probe messages between 2.x and 3.3; to a 2.x router a probe message means "Hello, I'm just starting up; could you please send me your routing table?" To a 3.3 and up, a probe message is a neighbor keepalive which is sent periodically on each interface. I don't know what Cisco does, but if they send periodic probe messages, a 2.x neighbor will reply to each one with a full routing table dump. This may be what is causing you to see large numbers of routing updates from your 2.x neighbors. Bill From list-mgr@ISI.EDU Wed Oct 25 11:52:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09972>; Wed, 25 Oct 1995 18:55:13 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09830>; Wed, 25 Oct 1995 18:53:11 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA09819>; Wed, 25 Oct 1995 18:53:11 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14446(4)>; Wed, 25 Oct 1995 18:53:03 PDT Received: by crevenia.parc.xerox.com id <177478>; Wed, 25 Oct 1995 18:52:55 -0700 From: Bill Fenner <fenner@parc.xerox.com> To: mbone Subject: Black holes caused by aggregation Cc: fenner@parc.xerox.com Message-Id: <95Oct25.185255pdt.177478@crevenia.parc.xerox.com> Date: Wed, 25 Oct 1995 18:52:46 PDT Longest-match routing was introduced in mrouted version 3.5 . Previous versions would only accept the least specific route that it heard, and if it heard routes that overlapped it would log a message and drop the new route. People now appear to be using Cisco's route aggregation feature in places that it shouldn't be used, which will cause problems when forwarding through mrouted versions previous to 3.5 (which is about 75% of the MBONE). A nice example of the breakage is net UIUC-CAMPUS-B, 128.174. (Not to pick on UIUC in particular, but it's the easiest example for me.) The three routes that I have in my routing tables for 128.174 are: 128.174.212.0/25 128.174.240/24 128.174/16 Note that the last route covers the first two, and mrouted versions previous to 3.5 will only accept the last route. In fact, if I traceroute towards 128.174.0.0, I have a nice short route: Mtrace from 128.174.0.0 to 204.162.228.2 via group 224.2.0.1 Querying full reverse path... 0 dartvader (204.162.228.2) -1 parc.dart.net (204.162.228.1) DVMRP thresh^ 1 200 s -2 ames.dart.net (140.173.144.1) DVMRP thresh^ 1 200 s -3 mbone2.nsi.nasa.gov (192.203.230.242) DVMRP thresh^ 64 200 s -4 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 1 200 s -5 oday.psc.edu (192.88.114.10) DVMRP thresh^ 64 176 s -6 mbone.merit.edu (198.108.2.20) DVMRP thresh^ 64 201 s -7 tibia.cic.net (192.217.65.100) DVMRP thresh^ 32 254 s Next router no mtrace -8 dcl2.gw.uiuc.edu (192.17.2.8) [proteon/mrouted 1.0] doesn't support mtrace However, if I trace towards one of the specific routes, I end up taking the shortest mrouted-3.5-or-greater path: Mtrace from 128.174.240.0 to 204.162.228.2 via group 224.2.0.1 Querying full reverse path... 0 dartvader (204.162.228.2) -1 parc.dart.net (204.162.228.1) DVMRP thresh^ 1 200 s -2 ames.dart.net (140.173.144.1) DVMRP thresh^ 1 200 s -3 mbone2.nsi.nasa.gov (192.203.230.242) DVMRP thresh^ 64 200 s -4 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 1 200 s -5 mbone.sdsc.edu (198.17.47.39) DVMRP thresh^ 64 200 s -6 VINEGAR.SESQUI.NET (128.241.0.91) DVMRP thresh^ 64 201 s -7 mae-bone.psi.net (192.41.177.247) DVMRP thresh^ 64 128 s -8 MBONE1.UU.NET (137.39.43.34) DVMRP thresh^ 64 201 s -9 MBONE2.UU.NET (137.39.246.98) DVMRP thresh^ 64 201 s -10 dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61) DVMRP thresh^ 64 2828 ms -11 dec3800-2-fddi-0.Denver.mci.net (204.70.152.61) DVMRP thresh^ 1 41 s -12 dec3800-1-fddi-0.WillowSprings.mci.net (204.70.104.29) DVMRP thresh^ 1 -24 s -13 tibia.cic.net (192.217.65.100) DVMRP thresh^ 32 254 s Next router no mtrace -14 dcl2.gw.uiuc.edu (192.17.2.8) [proteon/mrouted 1.0] doesn't support mtrace Round trip time 295 ms Now, you might say "Well, that just means that traffic is taking a suboptimal path, no big deal." But, because of the way DVMRP builds its forwarding trees, traffic that matches the specific routes (e.g. 128.174.240.1) will *not* get forwarded from a 3.5-and-up to a 3.4-and-down mrouter. Here is a (slightly altered, since there is no active source in 128.184.240.x right now) mtrace showing what you would see on that boundary: Mtrace from 128.174.240.0 to 141.210.188.1 via group 224.2.0.1 Querying full reverse path... 0 ? (141.210.188.1) -1 ? (141.210.188.3) DVMRP thresh^ 1 208 s -2 mbone.wayne.edu (141.217.1.74) DVMRP thresh^ 32 -250 s Not forwarding -3 mbone.merit.edu (198.108.2.20) DVMRP thresh^ 32 201 s -4 tibia.cic.net (192.217.65.100) DVMRP thresh^ 32 254 s Next router no mtrace -5 dcl2.gw.uiuc.edu (192.17.2.8) [proteon/mrouted 1.0] doesn't support mtrace Note the "Not forwarding" error code on the mbone.wayne.edu line. 141.210.188.3 is 3.4, mbone.wayne.edu is 3.5 . (Again, not to pick on wayne.edu; this was the easiest test case that I could come up with.) This means that if you are one of the people advertising this kind of specific and general routes, that you are isolating your traffic from the specifically routed subnets to the connected cloud of 3.5-and-above routers. Of course, the long term solution is to get the whole MBONE able to accept this kind of routing; the short term solution, however, is not to advertise this kind of route. Therefore, I will be periodically posting a list of routes that fall into this category; hopefully, the people responsible for those networks will reconfigure their routers to either advertise only a general route or only non-overlapping specific routes. The list follows. I will be posting this list (with a shorter explanation) periodically. Bill 36.18/16 is covered by 36/8 36.53/16 is covered by 36/8 36.56/16 is covered by 36/8 36.103/16 is covered by 36/8 36.153/16 is covered by 36/8 36.224/16 is covered by 36/8 128.32.211/24 is covered by 128.32/16 128.32.226/24 is covered by 128.32/16 128.171.3/24 is covered by 128.171/16 128.171.10/24 is covered by 128.171/16 128.171.11/24 is covered by 128.171/16 128.171.45/24 is covered by 128.171/16 128.174.212.0/25 is covered by 128.174/16 128.174.240/24 is covered by 128.174/16 132.250.88.170/32 is covered by 132.250.88.160/28 137.194.2/23 is covered by 137.194/16 137.194.34/23 is covered by 137.194/16 137.194.98/23 is covered by 137.194/16 137.194.160/23 is covered by 137.194/16 137.194.224/23 is covered by 137.194/16 137.194.230/23 is covered by 137.194/16 137.194.232/23 is covered by 137.194/16 From list-mgr@ISI.EDU Wed Oct 25 12:29:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12189>; Wed, 25 Oct 1995 19:33:24 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11968>; Wed, 25 Oct 1995 19:29:47 -0700 Received: from chow.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA11961>; Wed, 25 Oct 1995 19:29:46 -0700 Received: (mleelani@localhost) by chow.cisco.com (8.6.8+c/8.6.5) id TAA12643; Wed, 25 Oct 1995 19:29:41 -0700 From: Manoj Leelanivas <mleelani@cisco.com> Message-Id: <199510260229.TAA12643@chow.cisco.com> Subject: Re: mrouted crashes To: fenner@parc.xerox.com (Bill Fenner) Date: Wed, 25 Oct 95 19:29:41 PDT Cc: jhawk@near.net, mbone, multicast-support@cisco.com In-Reply-To: <95Oct25.185541pdt.177478@crevenia.parc.xerox.com>; from "Bill Fenner" at Oct 25, 95 6:55 pm X-Mailer: ELM [version 2.3 PL11] In message <199510252337.TAA02782@all-purpose-gunk.near.net> you write: >Dino added some code to log when lots of routes are received from a >particular peer, and I consistently (like once or twice a day) get >messages like: > >%DVMRP-1-ROUTEHOG: Receiving 11343 routes from 198.112.8.2 (Tunnel0) >in the last 00:01:05 > >from each of the 2.x mrouteds my cisco tunnels w/, but not from any of >the 3.x mrouteds. There was a change in the meaning of probe messages between 2.x and 3.3; to a 2.x router a probe message means "Hello, I'm just starting up; could you please send me your routing table?" To a 3.3 and up, a probe message is a neighbor keepalive which is sent periodically on each interface. I don't know what Cisco does, but if they send periodic probe messages, a 2.x neighbor will reply to each one with a full routing table dump. This may be what is causing you to see large numbers of routing updates from your 2.x neighbors. Ciscos dont send periodic probes. They just listen to the probes. That should'nt be the problem. -manoj From list-mgr@ISI.EDU Thu Oct 26 21:23:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17553>; Wed, 25 Oct 1995 22:25:34 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17506>; Wed, 25 Oct 1995 22:23:12 -0700 Received: from mimos.my by venera.isi.edu (5.65c/5.61+local-22) id <AA17499>; Wed, 25 Oct 1995 22:23:07 -0700 Received: from ms.mimos.my (ms.mimos.my [192.228.129.33]) by mimos.my (8.7.1/8.7.1) with SMTP id NAA24704; Thu, 26 Oct 1995 13:23:01 +0800 (MYT) Received: by ms.mimos.my (5.64/7.0) id AA01153; Thu, 26 Oct 95 13:23:00 +0800 Date: Thu, 26 Oct 1995 13:23:00 +0800 From: Norsuzana Harun <ana@ms.mimos.my> To: "Paul 'Shag' Walmsley" <ccshag@cclabs.missouri.edu> Cc: mbone Subject: Mbone Technology In-Reply-To: <Pine.SGI.3.91.951023215008.594B-100000@hendrix.cc.missouri.edu> Message-Id: <Pine.CVX.3.91.951026132147.1069A-100000@ms.mimos.my> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII hai.. I'm new in Mbone technology , so what should i do to have mbone. ------------------------------------------------------------------------------ webmaster/Norsuzana Harun Research Officer Computer System Division MIMOS ------------------------------------------------------------------------------ From list-mgr@ISI.EDU Thu Oct 26 15:31:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24935>; Thu, 26 Oct 1995 04:34:41 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24920>; Thu, 26 Oct 1995 04:33:01 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA24913>; Thu, 26 Oct 1995 04:32:57 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id NAA01884; Thu, 26 Oct 1995 13:31:54 +0200 Date: Thu, 26 Oct 1995 13:31:54 +0200 Message-Id: <199510261131.NAA01884@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Sean Doran <smd@icp.net> Cc: e93_mda@it.kth.se, tli@cisco.com, deering@parc.xerox.com, mbone, meyer@phloem.uoregon.edu Subject: Re: bandwidth questions In-Reply-To: <95Oct24.125623+0100_edt.20701+31@chops.icp.net> References: <95Oct24.125623+0100_edt.20701+31@chops.icp.net> Sean Doran writes: > > Naturally, once 11.0 unicast is reasonably stable and > moderately well-deployed in the backbone, we can start > playing with native multicast. > > The point, however, is that the only way in practice > to get code which is stable enough to deploy in the core > of the Internet is still actually deploying it and fixing > all the bugs that uncovers. > We've been doing this with one of our customers with reasonable success and only hitting ATM-related issues and crashes. Pete From list-mgr@ISI.EDU Wed Oct 25 22:15:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25446>; Thu, 26 Oct 1995 05:17:32 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25427>; Thu, 26 Oct 1995 05:16:05 -0700 Received: from phloem.uoregon.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA25420>; Thu, 26 Oct 1995 05:16:04 -0700 Received: (from meyer@localhost) by phloem.uoregon.edu (8.7.1/8.6.12) id FAA10443; Thu, 26 Oct 1995 05:15:30 -0700 (PDT) From: "David M. Meyer 503/346-1747" <meyer@phloem.uoregon.edu> Message-Id: <199510261215.FAA10443@phloem.uoregon.edu> Subject: Re: bandwidth questions To: pete@sms.fi (Petri Helenius) Date: Thu, 26 Oct 1995 05:15:26 -0700 (PDT) Cc: smd@icp.net, e93_mda@it.kth.se, tli@cisco.com, deering@parc.xerox.com, mbone In-Reply-To: <199510261131.NAA01884@silver.sms.fi> from "Petri Helenius" at Oct 26, 95 01:31:54 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Pete, > > Naturally, once 11.0 unicast is reasonably stable and > > moderately well-deployed in the backbone, we can start > > playing with native multicast. > > > > We've been doing this with one of our customers with reasonable success and > only hitting ATM-related issues and crashes. > We've been running an PIM cloud over an ATM backbone we have here in Oregon (about 15 PIM peers) for quite some time with really execellent success. Like you, our biggest problems revolve around ATM-related issues (Telco tarrifs, signalling issues in a public ATM cloud,...). However, unlike what you are reporting, we've not had too many crashes (I guess "too many" is somewhat subjective; I'll just note that my workstation is a lot less reliable). Dave From list-mgr@ISI.EDU Thu Oct 26 14:37:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25710>; Thu, 26 Oct 1995 05:38:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25678>; Thu, 26 Oct 1995 05:37:23 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA25671>; Thu, 26 Oct 1995 05:37:21 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id NAA07656; Thu, 26 Oct 1995 13:32:47 +0100 Message-Id: <199510261232.NAA07656@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: Bill Fenner <fenner@parc.xerox.com> Cc: e93_mda@it.kth.se, mbone Subject: Re: How did it get this bad? In-Reply-To: Your message of "Wed, 25 Oct 1995 19:09:30 PDT." <95Oct25.190932pdt.177478@crevenia.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Oct 1995 13:37:32 +0100 From: Magnus <e93_mda@it.kth.se> > In message <5412.814633706@cs.ucl.ac.uk> you write: > >mbone.cern.ch > >fmroute1-1.exp.edf.fr > >mae-bone.psi.net > >stockholm.mbone.ebone.net > > Are you sure it isn't > > fmroute1-1.exp.edf.fr > r-jusren.reseau.jussieu.fr > stockholm.mbone.ebone.net > > ? Well, the r-jusren box (a Cisco with 10.3) gives the following mrinfo reply: 134.157.0.221 (r-jusren.reseau.jussieu.fr) [version 10.3]: 192.44.54.126 -> 192.70.92.133 (fmroute1-1.exp.edf.fr) [1/32/tunnel/querier] 192.44.54.126 -> 194.68.128.50 (stockholm.mbone.ebone.net) [1/48/tunnel/querier/disabled/down/leaf] 192.44.54.126 -> 132.227.61.1 (artemis.ibp.fr) [1/32/tunnel/querier] 192.44.54.126 -> 194.68.128.50 (stockholm.mbone.ebone.net) [1/48/tunnel/querier] 192.44.54.126 -> 193.227.10.5 (ALPHA1.EUN.EG) [1/64/tunnel/querier/leaf] Could it possibly be so that the double pair of tunnels towards the stockholm box confuses the machine? It is obvously the first tunnel which is down, and the net seems to think this too. It is time to clean up the configs of many boxes, I have seen many boxes with old and uncleaned configs. > at least, stockholm.mbone.ebone.net claims that the previous hop is r-jusren... > perhaps the france->usa->sweden path should be a higher metric than the > france->france->sweden one =) Will concider it. :-) Magnus From list-mgr@ISI.EDU Thu Oct 26 18:36:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29953>; Thu, 26 Oct 1995 07:37:33 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29902>; Thu, 26 Oct 1995 07:36:29 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA29895>; Thu, 26 Oct 1995 07:36:26 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id QAA02281; Thu, 26 Oct 1995 16:36:11 +0200 Date: Thu, 26 Oct 1995 16:36:11 +0200 Message-Id: <199510261436.QAA02281@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: "David M. Meyer 503/346-1747" <meyer@phloem.uoregon.edu> Cc: smd@icp.net, e93_mda@it.kth.se, tli@cisco.com, deering@parc.xerox.com, mbone Subject: Re: bandwidth questions In-Reply-To: <199510261215.FAA10443@phloem.uoregon.edu> References: <199510261131.NAA01884@silver.sms.fi> <199510261215.FAA10443@phloem.uoregon.edu> David M. Meyer writes: > > Like you, our biggest problems revolve around ATM-related > issues (Telco tarrifs, signalling issues in a public ATM > cloud,...). However, unlike what you are reporting, > we've not had too many crashes (I guess "too many" is > somewhat subjective; I'll just note that my workstation is > a lot less reliable). > Are you running Classical IP and SVC's? Those have been the major killers. And another one is that you might be running 7XXX's as we do have many 4X00's running ATM. The worst case so far is average uptime of 15 minutes. But despite of the quality of first FCS code I've been impressed of the speed the code is getting together. Pete From list-mgr@ISI.EDU Thu Oct 26 00:41:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00400>; Thu, 26 Oct 1995 07:43:15 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00367>; Thu, 26 Oct 1995 07:42:29 -0700 Received: from crazy-horse.uoregon.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA00360>; Thu, 26 Oct 1995 07:42:28 -0700 Received: (from meyer@localhost) by crazy-horse.uoregon.edu (8.7.1/8.7.Gamma.1) id HAA12388; Thu, 26 Oct 1995 07:41:50 -0700 (PDT) From: "David M. Meyer 503/346-1747" <meyer@phloem.uoregon.edu> Message-Id: <199510261441.HAA12388@crazy-horse.uoregon.edu> Subject: Re: bandwidth questions To: pete@sms.fi (Petri Helenius) Date: Thu, 26 Oct 1995 07:41:49 -0700 (PDT) Cc: meyer@phloem.uoregon.edu, smd@icp.net, e93_mda@it.kth.se, tli@cisco.com, deering@parc.xerox.com, mbone In-Reply-To: <199510261436.QAA02281@silver.sms.fi> from "Petri Helenius" at Oct 26, 95 04:36:11 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Pete, > Are you running Classical IP and SVC's? Those have been the major killers. Yes. > And another one is that you might be running 7XXX's as we do have many > 4X00's running ATM. The worst case so far is average uptime of 15 minutes. 7ks, so this might account for some of it. > > But despite of the quality of first FCS code I've been impressed of the > speed the code is getting together. > Same here. Dave From list-mgr@ISI.EDU Thu Oct 26 19:12:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01569>; Thu, 26 Oct 1995 08:13:30 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01522>; Thu, 26 Oct 1995 08:12:36 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA01515>; Thu, 26 Oct 1995 08:12:33 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id RAA02387; Thu, 26 Oct 1995 17:12:00 +0200 Date: Thu, 26 Oct 1995 17:12:00 +0200 Message-Id: <199510261512.RAA02387@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Bill Fenner <fenner@parc.xerox.com> Cc: mbone Subject: Black holes caused by aggregation In-Reply-To: <95Oct25.185255pdt.177478@crevenia.parc.xerox.com> References: <95Oct25.185255pdt.177478@crevenia.parc.xerox.com> Bill Fenner writes: > > People now appear to be using Cisco's route aggregation feature in > places that it shouldn't be used, which will cause problems when > forwarding through mrouted versions previous to 3.5 (which is about 75% > of the MBONE). A nice example of the breakage is net UIUC-CAMPUS-B, > 128.174. (Not to pick on UIUC in particular, but it's the easiest > example for me.) The three routes that I have in my routing tables for > 128.174 are: > The 75% is old information, I get 43.3% classless-capable-mrouteds: Version hosts percent ------- ----- ------- 3.6 183 16.1% 10.3 89 7.8% 3.5 84 7.4% 10.2 77 6.8% 11.0 59 5.2% Pete From list-mgr@ISI.EDU Thu Oct 26 04:00:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11345>; Thu, 26 Oct 1995 11:02:08 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11312>; Thu, 26 Oct 1995 11:01:10 -0700 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA11305>; Thu, 26 Oct 1995 11:01:08 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15624(10)>; Thu, 26 Oct 1995 11:00:48 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Thu, 26 Oct 1995 11:00:41 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Petri Helenius <pete@sms.fi> Cc: mbone Subject: Re: Black holes caused by aggregation In-Reply-To: Your message of "Thu, 26 Oct 95 08:12:00 PDT." <199510261512.RAA02387@silver.sms.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Oct 1995 11:00:37 PDT Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Oct26.110041pdt.177478@crevenia.parc.xerox.com> In message <199510261512.RAA02387@silver.sms.fi> you write: >The 75% is old information, I get 43.3% classless-capable-mrouteds Yes, silly me, I forgot to count the ciscos. Still, it probably doesn't matter whether it is 75% or 50%; it's still way too large to want to simply exclude it. Bill From list-mgr@ISI.EDU Thu Oct 26 10:12:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12066>; Thu, 26 Oct 1995 11:14:43 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AB11985>; Thu, 26 Oct 1995 11:13:57 -0700 Received: from portal (portal.netedge.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA11976>; Thu, 26 Oct 1995 11:13:55 -0700 Received: from NetEdge.COM by portal id AA12026; Thu, 26 Oct 95 14:12:42 EDT Received: from suicidesix.NetEdge.COM by NetEdge.COM id AA26950; Thu, 26 Oct 95 14:13:59 EDT Return-Path: <Tom_Pusateri@NetEdge.COM> Received: from localhost by suicidesix.NetEdge.COM (4.1/NECL-6.14) id AA12617; Thu, 26 Oct 95 14:12:39 EDT Message-Id: <9510261812.AA12617@NetEdge.COM> To: "David M. Meyer 503/346-1747" <meyer@phloem.uoregon.edu> Cc: mbone Subject: Re: bandwidth questions In-Reply-To: Your message of "Thu, 26 Oct 1995 07:41:49 PDT." <199510261441.HAA12388@crazy-horse.uoregon.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <12614.814731158.1@suicidesix.netedge.com> Date: Thu, 26 Oct 1995 14:12:39 -0400 From: Thomas Pusateri <pusateri@NetEdge.COM> In message <199510261441.HAA12388@crazy-horse.uoregon.edu> you write: > >Pete, > >> Are you running Classical IP and SVC's? Those have been the major killers. > >Yes. Out of curiosity, how are you running IP Multicast over Classical IP? (A previous note mentioned you were running PIM.) Thanks, Tom From list-mgr@ISI.EDU Thu Oct 26 04:30:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13022>; Thu, 26 Oct 1995 11:31:49 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13004>; Thu, 26 Oct 1995 11:31:17 -0700 Received: from crazy-horse.uoregon.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA12995>; Thu, 26 Oct 1995 11:31:16 -0700 Received: (from meyer@localhost) by crazy-horse.uoregon.edu (8.7.1/8.7.Gamma.1) id LAA13784; Thu, 26 Oct 1995 11:30:56 -0700 (PDT) From: "David M. Meyer 503/346-1747" <meyer@phloem.uoregon.edu> Message-Id: <199510261830.LAA13784@crazy-horse.uoregon.edu> Subject: Re: bandwidth questions To: pusateri@NetEdge.COM (Thomas Pusateri) Date: Thu, 26 Oct 1995 11:30:55 -0700 (PDT) Cc: meyer@phloem.uoregon.edu, mbone In-Reply-To: <9510261812.AA12617@NetEdge.COM> from "Thomas Pusateri" at Oct 26, 95 02:12:39 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Tom, > >Pete, > > > >> Are you running Classical IP and SVC's? Those have been the major killers. > > > >Yes. > > Out of curiosity, how are you running IP Multicast over Classical IP? > (A previous note mentioned you were running PIM.) > Sorry about the confusion. > > Out of curiosity, how are you running IP Multicast over Classical IP? > (A previous note mentioned you were running PIM.) I'm not running PIM over Classical IP. I am running PIM over ATM in my WAN (and in my campus network), but in this case it's not Classical IP (just using PVP tunneling/IISP/ILMI to find the other end of the map). In addition, I am running Classical IP in LAN situations (for the most part). I think Pete was commmenting on the stability of early RFC1577 and signalling implementations in IOS. Dave From list-mgr@ISI.EDU Thu Oct 26 22:47:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13922>; Thu, 26 Oct 1995 11:48:37 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13876>; Thu, 26 Oct 1995 11:47:22 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA13863>; Thu, 26 Oct 1995 11:47:19 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id UAA02847; Thu, 26 Oct 1995 20:47:09 +0200 Date: Thu, 26 Oct 1995 20:47:09 +0200 Message-Id: <199510261847.UAA02847@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Bill Fenner <fenner@parc.xerox.com> Cc: mbone Subject: Re: Black holes caused by aggregation In-Reply-To: <95Oct26.110041pdt.177478@crevenia.parc.xerox.com> References: <199510261512.RAA02387@silver.sms.fi> <95Oct26.110041pdt.177478@crevenia.parc.xerox.com> Bill Fenner writes: > In message <199510261512.RAA02387@silver.sms.fi> you write: > >The 75% is old information, I get 43.3% classless-capable-mrouteds > > Yes, silly me, I forgot to count the ciscos. Still, it probably doesn't > matter whether it is 75% or 50%; it's still way too large to want to simply > exclude it. > Yes, not now. It seems though that this figure is going to be changing rapidly anyway. Pete From list-mgr@ISI.EDU Thu Oct 26 22:55:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14311>; Thu, 26 Oct 1995 11:56:49 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14282>; Thu, 26 Oct 1995 11:56:06 -0700 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA14275>; Thu, 26 Oct 1995 11:56:04 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id UAA02866; Thu, 26 Oct 1995 20:55:53 +0200 Date: Thu, 26 Oct 1995 20:55:53 +0200 Message-Id: <199510261855.UAA02866@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: "David M. Meyer 503/346-1747" <meyer@phloem.uoregon.edu> Cc: pusateri@netedge.com (Thomas Pusateri), mbone Subject: Re: bandwidth questions In-Reply-To: <199510261830.LAA13784@crazy-horse.uoregon.edu> References: <9510261812.AA12617@NetEdge.COM> <199510261830.LAA13784@crazy-horse.uoregon.edu> David M. Meyer writes: > > I'm not running PIM over Classical IP. I am running PIM over > ATM in my WAN (and in my campus network), but in this case > it's not Classical IP (just using PVP tunneling/IISP/ILMI > to find the other end of the map). In addition, I am running > Classical IP in LAN situations (for the most part). > > I think Pete was commmenting on the stability of early > RFC1577 and signalling implementations in IOS. > Yes, my PIM goes also over staticly mapped SVC's and PVC's (a mix). Pete From list-mgr@ISI.EDU Thu Oct 26 08:42:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16952>; Thu, 26 Oct 1995 12:42:54 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16909>; Thu, 26 Oct 1995 12:42:17 -0700 Received: from stargate.1starnet.com ([206.103.100.1]) by venera.isi.edu (5.65c/5.61+local-22) id <AA16898>; Thu, 26 Oct 1995 12:42:13 -0700 Received: from [206.103.100.17] ([206.103.100.17]) by stargate.1starnet.com (8.6.12/8.6.12-MT2.2) with SMTP id OAA00125 for <mbone@ISI.EDU>; Thu, 26 Oct 1995 14:37:59 CDT (-0500) Message-Id: <v01530501acb5a3168d25@[206.103.100.17]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Oct 1995 14:42:19 -0600 To: mbone From: rthrash@stargate.1starnet.com (Russell Thrasher) UNSUBSCRIBE From list-mgr@ISI.EDU Thu Oct 26 12:12:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18430>; Thu, 26 Oct 1995 13:12:36 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18403>; Thu, 26 Oct 1995 13:12:02 -0700 Received: from maelstrom.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA18393>; Thu, 26 Oct 1995 13:11:57 -0700 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.7.1/8.6.6) id QAA02020 for mbone@isi.edu; Thu, 26 Oct 1995 16:12:44 -0400 (GMT-0400) Message-Id: <199510262012.QAA02020@maelstrom.cc.mcgill.ca> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Yves Lepage <yves@CC.McGill.CA> Date: Thu, 26 Oct 95 16:12:42 -0400 To: mbone Subject: SD (old or new) Reply-To: yves@cc.mcgill.ca Hi all, I would like to know if source code to SD is available anywhere. So far, I could only find binaries and I'd like to give it a try to build it on a NeXT using the Co-Xist X server. Thanks in advance. Yves Lepage From list-mgr@ISI.EDU Thu Oct 26 13:38:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23175>; Thu, 26 Oct 1995 14:41:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23147>; Thu, 26 Oct 1995 14:40:39 -0700 Received: from sgi.sgi.com (SGI.COM) by venera.isi.edu (5.65c/5.61+local-22) id <AA23138>; Thu, 26 Oct 1995 14:40:38 -0700 Received: from mistral.detroit.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for <@sgi.sgi.com:mbone@ISI.EDU> id OAA29675; Thu, 26 Oct 1995 14:40:35 -0700 Received: by mistral.detroit.sgi.com (940816.SGI.8.6.9/930416.SGI) for mbone@ISI.EDU id RAA09113; Thu, 26 Oct 1995 17:38:01 -0400 From: "Jeffrey M. Feierfeil" <firefly@mistral.detroit.sgi.com> Message-Id: <9510261738.ZM9111@mistral.detroit.sgi.com> Date: Thu, 26 Oct 1995 17:38:01 -0400 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: mbone Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii UNSUBSCRIBE -- Jeffrey M. Feierfeil **************************************************************************** Jeff Feierfeil Silicon Graphics, Inc. Phone (810) 615-2116 FAX (810) 478-3181 VM 5-8339 MS DMR-225 firefly@detroit.sgi.com **************************************************************************** From list-mgr@ISI.EDU Thu Oct 26 11:45:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26462>; Thu, 26 Oct 1995 15:45:32 -0700 Received: from stargate.1starnet.com ([206.103.100.1]) by venera.isi.edu (5.65c/5.61+local-22) id <AA26455>; Thu, 26 Oct 1995 15:45:31 -0700 Received: from [206.103.100.17] ([206.103.100.17]) by stargate.1starnet.com (8.6.12/8.6.12-MT2.2) with SMTP id RAA00634 for <mbone-na@isi.edu>; Thu, 26 Oct 1995 17:41:21 CDT (-0500) Message-Id: <v01530507acb5ce1ccfa3@[206.103.100.17]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Oct 1995 17:45:41 -0600 To: mbone-na From: rthrash@stargate.1starnet.com (Russell Thrasher) UNSUBSCRIBE From list-mgr@ISI.EDU Fri Oct 27 07:06:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10680>; Thu, 26 Oct 1995 22:10:01 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10597>; Thu, 26 Oct 1995 22:06:49 -0700 Received: from valinor.commerce.uq.edu.au by venera.isi.edu (5.65c/5.61+local-22) id <AA10586>; Thu, 26 Oct 1995 22:06:45 -0700 Received: from [130.102.101.4] (gandalf.commerce.uq.edu.au [130.102.101.4]) by valinor.commerce.uq.edu.au (8.6.10/8.6.9) with SMTP id PAA27407 for <mbone@ISI.EDU>; Fri, 27 Oct 1995 15:06:39 +1000 X-Sender: bellamy@valinor.commerce.uq.edu.au Message-Id: <v02130506acb7155274fb@[130.102.101.4]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 1995 15:06:34 -0800 To: mbone From: bellamy@commerce.uq.edu.au (David Bellamy) Subject: Re: Black holes caused by aggregation >Bill Fenner writes: > > In message <199510261512.RAA02387@silver.sms.fi> you write: > > >The 75% is old information, I get 43.3% classless-capable-mrouteds > > > > Yes, silly me, I forgot to count the ciscos. Still, it probably doesn't > > matter whether it is 75% or 50%; it's still way too large to want to simply > > exclude it. > > >Yes, not now. It seems though that this figure is going to be changing >rapidly anyway. > Does anyone know if full kernel multicast support will be included in SunOS 5.5. I suspect that this would help speed implementation of 3.6 (or later). We have steered away from apply the unofficial patches, mainly because they are not supported in the normal patch process, i.e. application of Sun patches is liable to wipe them out. Thanks -- David Bellamy. Deparment of Commerce. The University of Queensland. Australia. Internet: bellamy@commerce.uq.edu.au Phone: +61 7 336 56652 From list-mgr@ISI.EDU Tue Oct 27 12:20:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13812>; Fri, 27 Oct 1995 00:16:47 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13698>; Fri, 27 Oct 1995 00:13:28 -0700 Received: from milpitas.adaptec.com by venera.isi.edu (5.65c/5.61+local-22) id <AA13691>; Fri, 27 Oct 1995 00:13:27 -0700 Received: from corpmail.adaptec.com ([162.62.105.19]) by milpitas.adaptec.com (4.1/SMI-4.1) id AA28993; Fri, 27 Oct 95 00:12:16 PDT Received: from mentor.adaptec.com by corpmail.adaptec.com (4.1/SMI-4.1) id AA02485; Thu, 26 Oct 95 23:44:26 PDT X-Nvlenv-01Date-Transferred: 27-Oct-1995 0:16:27 -0400; at Mentor.Adaptec X-Nvlenv-01Date-Posted: 27-Oct-1995 16:22:58 -0400; at AJL.Adaptec Date: 27 Oct 95 16:20:00 EDT From: TMatsumu@Asia.adaptec.com Subject: unsubscribe Message-Id: <743A9130016B1673@-SMF-> Reply-To: TMatsumu@Asia.adaptec.com References: <753A9130026B1673@-SMF-> To: mbone unsubscribe for now, thanks. ***** Ted Matsumura, Adaptec Japan ATM Program Manager InterNetworking Technology (INTO) Adaptec Japan Ltd. (03) 5276-8433 (Voice) (03) 5276-9364 (Fax) tmatsumu@asia.adaptec.com http://www.rahul.net/tedm ***** From list-mgr@ISI.EDU Fri Oct 27 09:30:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16724>; Fri, 27 Oct 1995 02:33:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16713>; Fri, 27 Oct 1995 02:31:08 -0700 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA16706>; Fri, 27 Oct 1995 02:31:03 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id JAA04057; Fri, 27 Oct 1995 09:30:47 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id JAA13674; Fri, 27 Oct 1995 09:30:44 GMT Date: Fri, 27 Oct 1995 09:30:41 +0000 (GMT) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: David Bellamy <bellamy@commerce.uq.edu.au> Cc: mbone Subject: Re: Black holes caused by aggregation In-Reply-To: <v02130506acb7155274fb@[130.102.101.4]> Message-Id: <Pine.SV4.3.91.951027091607.13618A-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 27 Oct 1995, David Bellamy wrote: > Does anyone know if full kernel multicast support will be included in SunOS > 5.5. I suspect that this would help speed implementation of 3.6 (or > later). I assume you mean by this that you want to know if SunOS 5.5 will include IP multicast version 3.6? Without breaking my Solaris 2.5 non-disclosure agreement I would say it would probably be unlikely that 3.6 will be included given that 3.6 for Solaris 2.4 is only in alpha at the moment and that Solaris 2.5 will be shipping with UltraSPARC when it is launched next month. > We have steered away from apply the unofficial patches, mainly because they > are not supported in the normal patch process, i.e. application of Sun > patches is liable to wipe them out. When 3.3 for SunOS 5.4 came out it was suggested that Sun Engineering were trying to get the multicast patches rolled into the normal patch process which would solve this problem. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Fri Oct 27 05:38:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18720>; Fri, 27 Oct 1995 05:41:16 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18701>; Fri, 27 Oct 1995 05:39:37 -0700 Received: from access.cc.univie.ac.at by venera.isi.edu (5.65c/5.61+local-22) id <AA18675>; Fri, 27 Oct 1995 05:38:55 -0700 Received: by cc.univie.ac.at (MX V4.1 VAX) id 4; Fri, 27 Oct 1995 13:37:22 MET Date: Fri, 27 Oct 1995 13:37:21 MET From: "Wilfried Woeber, UniVie/ACOnet" <woeber@cc.univie.ac.at> To: firefly@mistral.detroit.sgi.com, TMatsumu@Asia.adaptec.com Cc: mbone Message-Id: <009987F9.CE65B618.4@cc.univie.ac.at> Subject: RE: [none] ...unsubscribe requests Folks, could all of you who want to have their eMAil address removed from the list -*please*- send these requests to the "request-address" of the list ( <mbone-request@ISI.EDU> ) ?! It is completely useless and rather annoying to bother a whole load of people all around the globe who cannot do *anything* to honour your request. Thank you. -WW. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 -------------------------------------------------------------------------- From: "Jeffrey M. Feierfeil" <firefly@mistral.detroit.sgi.com> Date: Thu, 26 Oct 1995 17:38:01 -0400 To: mbone@ISI.EDU UNSUBSCRIBE -- Jeffrey M. Feierfeil **************************************************************************** Jeff Feierfeil Silicon Graphics, Inc. Phone (810) 615-2116 FAX (810) 478-3181 VM 5-8339 MS DMR-225 firefly@detroit.sgi.com **************************************************************************** Date: 27 Oct 95 16:20:00 EDT From: TMatsumu@Asia.adaptec.com Subject: unsubscribe To: mbone@ISI.EDU unsubscribe for now, thanks. ***** Ted Matsumura, Adaptec Japan ATM Program Manager InterNetworking Technology (INTO) Adaptec Japan Ltd. (03) 5276-8433 (Voice) (03) 5276-9364 (Fax) tmatsumu@asia.adaptec.com http://www.rahul.net/tedm ***** -------------------------------------------------------------------------------- From list-mgr@ISI.EDU Fri Oct 27 13:32:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20362>; Fri, 27 Oct 1995 06:36:40 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20342>; Fri, 27 Oct 1995 06:35:31 -0700 Received: from redwood.shu.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA20100>; Fri, 27 Oct 1995 06:34:25 -0700 X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Fri, 27 Oct 1995 13:32:13 +0000 X400-Received: by mta redwood.shu.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Fri, 27 Oct 1995 13:32:13 +0000 Date: Fri, 27 Oct 1995 13:32:13 +0000 X400-Originator: liaison@shu.ac.uk X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;redwood.shu.:024840:951027133159] X400-Content-Type: P2-1988 (22) Content-Identifier: Poor audio recep From: Dave Haywood <liaison@shu.ac.uk> Message-Id: <"redwood.shu.:004320:951027133155*/S=liaison/O=sheffield-hallam/PRMD=UK.AC/ADMD= /C=GB/"@MHS> To: MBONE UK <mbone-uk@cs.ucl.ac.uk> Cc: mbone <mbone> Subject: Poor audio reception from NASA in UK? X-Mua-Version: XT-MUA 1.3 (blenheim) of Wed Sep 21 12:29:27 BST 1994 Content-Type: multipart/mixed; boundary="---Multi-Part-Message-Level-1-1-5891" Mime-Version: 1.0 -----Multi-Part-Message-Level-1-1-5891 Content-type: text/plain; charset="us-ascii" Hi, I seem to keep "losing" the NASA audio plus the general quality is very poor. VAT reports 53087 packets, 126583 missing (!), 26178 misordered, 285 dropped. I have attached an mtrace from my mbone router to scorpio.arc.nasa.gov. Does anyone see anything strange in this output? Why are the values for lea.cs.ucl.ac.uk rediculous? By the way, I recently set: ndd -set /dev/ip ip_path_mtu_discovery 0 in rc2.d/S69inet to get around a solaris 2.4 kernel bug (BUGID 1149424). Thanks, Dave Haywood liaison@shu.ac.uk -----Multi-Part-Message-Level-1-1-5891 Content-type: text/plain; charset="us-ascii" # /usr/local/mbone/bin/mtrace scorpio.arc.nasa.gov 224.2.176.245 Mtrace from 128.102.84.140 to 143.52.2.8 via group 224.2.176.245 Querying full reverse path... * switching to hop-by-hop: 0 mbone.shu.ac.uk (143.52.2.8) -1 mbone.shu.ac.uk (143.52.2.8) DVMRP thresh^ 1 -45 ms -2 noc.dl.ja.net (193.63.108.100) DVMRP thresh^ 24 17685 ms -3 noc.mcc.ja.net (193.63.105.100) DVMRP thresh^ 24 27125 ms -4 noc.ed.ja.net (193.63.106.100) DVMRP thresh^ 24 43699 ms -5 noc2.ulcc.ja.net (193.63.94.26) DVMRP thresh^ 24 17692 ms -6 noc.ulcc.ja.net (193.63.94.25) DVMRP thresh^ 1 17723 ms -7 lea.cs.ucl.ac.uk (128.16.64.24) DVMRP thresh^ 24 -239960 ms -8 ? (193.58.172.2) DVMRP thresh^ 32 -34531 ms -9 sideral.rediris.es (130.206.1.32) DVMRP thresh^ 48 71046 ms -10 * netserv.cnr.it (192.12.192.6) didn't respond Round trip time 281 ms Waiting to accumulate statistics... * Results after 13 seconds: Source Response Dest Packet Statistics For Only For Traffic * * * 143.52.2.8 All Multicast Traffic From 128.102.84.140 | __/ rtt 301 ms Lost/Sent = Pct Rate To 224.2.176.245 v / hop -70 s --------------------- -------------------- 130.206.1.32 sideral.rediris.es | ^ ttl 48 v | hop 105 s -4/469 = 0% 36 pps 0/0 = --% 0 pps 193.190.247.74 193.58.172.2 ? | ^ ttl 49 v | hop 205 s 562/562 =100% 43 pps 0/0 = --% 0 pps 194.104.0.30 128.16.64.24 lea.cs.ucl.ac.uk | ^ ttl 50 v | hop -257 s 1134950506/1134951214= -1%87303939 pps 0/0 = --% 0 pps 193.63.94.25 noc.ulcc.ja.net | ^ ttl 51 v | hop 51 ms 0/727 = 0% 55 pps 0/0 = --% 0 pps 193.63.94.26 noc2.ulcc.ja.net | ^ ttl 52 v | hop -26 s 10/722 = 1% 55 pps 0/0 = --% 0 pps 193.63.106.100 noc.ed.ja.net | ^ ttl 53 v | hop 16 s 32/536 = 6% 41 pps 0/0 = --% 0 pps 193.63.105.100 noc.mcc.ja.net | ^ ttl 54 v | hop 9436 ms 2/461 = 0% 35 pps 0/0 = --% 0 pps 193.63.108.100 noc.dl.ja.net | ^ ttl 55 v | hop 17 s 10/204 = 5% 15 pps 0/0 = --% 0 pps 143.52.2.8 mbone.shu.ac.uk | \__ ttl 56 v \ hop -44 ms 129 9 pps 0 0 pps 143.52.2.8 143.52.2.8 Receiver Query Source -----Multi-Part-Message-Level-1-1-5891-- From list-mgr@ISI.EDU Fri Oct 27 15:45:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20780>; Fri, 27 Oct 1995 06:47:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20718>; Fri, 27 Oct 1995 06:45:47 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA20711>; Fri, 27 Oct 1995 06:45:46 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id OAA00580; Fri, 27 Oct 1995 14:40:47 +0100 Message-Id: <199510271340.OAA00580@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: Dave Haywood <liaison@shu.ac.uk> Cc: MBONE UK <mbone-uk@cs.ucl.ac.uk>, mbone <mbone>, e93_mda@it.kth.se Subject: Re: Poor audio reception from NASA in UK? In-Reply-To: Your message of "Fri, 27 Oct 1995 13:32:13 GMT." <"redwood.shu.:004320:951027133155*/S=liaison/O=sheffield-hallam/PRMD=UK.AC/ADMD= /C=GB/"@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 1995 14:45:42 +0100 From: Magnus <e93_mda@it.kth.se> > Hi, > > I seem to keep "losing" the NASA audio plus the general quality is > very poor. VAT reports 53087 packets, 126583 missing (!), 26178 > misordered, 285 dropped. > > I have attached an mtrace from my mbone router to > scorpio.arc.nasa.gov. Does anyone see anything strange in this output? > Why are the values for lea.cs.ucl.ac.uk rediculous? What you see is a mbone topology problem which brings your signal trough a much larger countries in Europe then you migth think... it is a known topology problem and I am working on it. The redicolous numbers of lea is due to the fact that there is a bug in that mrouted code (3.3 on HP-UX). This is also known and an upgrade is hopefully comming soon. Otherwise I liked your bugreport. Magnus From list-mgr@ISI.EDU Fri Oct 27 15:45:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20780>; Fri, 27 Oct 1995 06:47:25 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20718>; Fri, 27 Oct 1995 06:45:47 -0700 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA20711>; Fri, 27 Oct 1995 06:45:46 -0700 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id OAA00580; Fri, 27 Oct 1995 14:40:47 +0100 Message-Id: <199510271340.OAA00580@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: Dave Haywood <liaison@shu.ac.uk> Cc: MBONE UK <mbone-uk@cs.ucl.ac.uk>, mbone <mbone>, e93_mda@it.kth.se Subject: Re: Poor audio reception from NASA in UK? In-Reply-To: Your message of "Fri, 27 Oct 1995 13:32:13 GMT." <"redwood.shu.:004320:951027133155*/S=liaison/O=sheffield-hallam/PRMD=UK.AC/ADMD= /C=GB/"@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 1995 14:45:42 +0100 From: Magnus <e93_mda@it.kth.se> > Hi, > > I seem to keep "losing" the NASA audio plus the general quality is > very poor. VAT reports 53087 packets, 126583 missing (!), 26178 > misordered, 285 dropped. > > I have attached an mtrace from my mbone router to > scorpio.arc.nasa.gov. Does anyone see anything strange in this output? > Why are the values for lea.cs.ucl.ac.uk rediculous? What you see is a mbone topology problem which brings your signal trough a much larger countries in Europe then you migth think... it is a known topology problem and I am working on it. The redicolous numbers of lea is due to the fact that there is a bug in that mrouted code (3.3 on HP-UX). This is also known and an upgrade is hopefully comming soon. Otherwise I liked your bugreport. Magnus From list-mgr@ISI.EDU Sat Oct 28 06:24:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02077>; Sat, 28 Oct 1995 23:00:23 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01770>; Sat, 28 Oct 1995 22:59:31 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA01761>; Sat, 28 Oct 1995 22:59:30 -0700 Received: from darkstar.isi.edu by quark.isi.edu (5.65c/5.61+local-20) id <AA03161>; Sat, 28 Oct 1995 16:26:56 -0700 Received: from millennianet.com by darkstar.isi.edu (5.65c/5.61+local-20) id <AA00353>; Sat, 28 Oct 1995 13:44:25 -0700 Received: (from steve@localhost) by millennianet.com (8.6.12/8.6.12.950904.SGI) id UAA19164; Sat, 28 Oct 1995 20:24:34 GMT Date: Sat, 28 Oct 1995 13:24:32 -0700 (PDT) From: {Darkavich} <steve@millennianet.com> To: mbone Subject: Mbone feed Message-Id: <Pine.SGI.3.91.951028131815.18911H-100000@millennianet.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I would like to requst an mbone feed from someone that is close to the MCI backbone. It appears that MCI's position is they will not be offering MBONE services in the next 6-12 months. And there is some doubt as to when they will offer it, if ever. If there is some kind soul that would be willing to send us a feed I would greatly apreciate it. In addition, if there are any other MCI customers dealing with this same problem, I will be more than happy to be the central tunnel hub for these customers, at least until MCI can get their act together. Thanks in advance. ------------------------------------------------------------------- Steven Misrack (619) 623-1600 x325 (voice) MillenniaNet (619) 623-1603 (fax) Vice President, Technology. steve@MillenniaNet.COM From list-mgr@ISI.EDU Sat Oct 28 05:33:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01381>; Sat, 28 Oct 1995 22:57:22 -0700 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01049>; Sat, 28 Oct 1995 22:56:18 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA01042>; Sat, 28 Oct 1995 22:56:17 -0700 Received: from maelstrom.cc.mcgill.ca ([132.206.35.2]) by quark.isi.edu (5.65c/5.61+local-20) id <AA21334>; Sat, 28 Oct 1995 06:32:09 -0700 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.7.1/8.6.6) id JAA10925; Sat, 28 Oct 1995 09:33:04 -0400 (GMT-0400) Date: Sat, 28 Oct 1995 09:33:04 -0400 (GMT-0400) From: Yves Lepage <yves@CC.McGill.CA> Subject: My NeXT is partially on the MBONE To: mbone Message-Id: <Pine.3.89.9510280954.A10893-0100000@maelstrom> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I've managed to partially put my NeXT on the MBONE. I've sucessfully received the STS-73 video using nv. I got the parameters to give it from sd_listen (still looking for SD sources). I am currently working on vat but don't expect it soon. On a NeXT, you don't just throw audio at a device, high level calls manage it for you and I'll have to create a nextaudio.cc file to put in the vat package. I still have to find evidence that the NeXT can manage audio streams, not just audio files (I'd hate to have to fool it by cutting the stream into small parts that I'd give to the audio calls). the nv I built is 3.3 (beta) and I built it using tk3.6 and tcl 7.4. It is staticlly linked. I have used the X libs from the co-Xist X server/dev kit. You will need an X server running on your NeXT to get it to run. co-xist 3.3 gave me good performance on my old NeXT station turbo color (68040). I know that there are a couple of public domain X server for NeXT and I am thinking of mouse-X, which I am unsure has been maintained to run on NS 3.3. The binaries are on: ftp://ftp.mcgill.ca/pub/systems/NeXT/mbone I've compiled them for m68k for now. I can very easily produce binaries for sparc, hppa and intel if the demand is there. 1- run sd_listen 2- run nv in this fashion: nv <ip address (mcast group)> <port> You will also need an mrouted running on another machine that has an multicast capable interface on the segment on which the NeXT is. Just so that mcast traffic will will run down the wire to be picked up by your NeXT. NeXT's can't run mrouted because of insufficient mcast support (and insufficient kernel access). Note that Cray's can't either :-) Have fun. Yves Lepage "How often have I said to you that when you have eliminated the impossible, whatever remains, however improbable, must be the truth?" -- SIR ARTHUR CONAN DOYLE 1859-1930 From list-mgr@ISI.EDU Sun Oct 29 03:35:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08995>; Sun, 29 Oct 1995 05:37:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08982>; Sun, 29 Oct 1995 05:36:37 -0800 Received: from foghorn.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA08975>; Sun, 29 Oct 1995 05:36:35 -0800 Received: from localhost (young@localhost) by foghorn.reston.mci.net (8.6.12/8.6.9) with SMTP id IAA24358; Sun, 29 Oct 1995 08:35:15 -0500 Message-Id: <199510291335.IAA24358@foghorn.reston.mci.net> X-Authentication-Warning: foghorn.reston.mci.net: young owned process doing -bs X-Authentication-Warning: foghorn.reston.mci.net: Host localhost didn't use HELO protocol To: {Darkavich} <steve@millennianet.com> Cc: mbone, young@mci.net Subject: Re: Mbone feed In-Reply-To: Your message of "Sat, 28 Oct 1995 13:24:32 PDT." <Pine.SGI.3.91.951028131815.18911H-100000@millennianet.com> Date: Sun, 29 Oct 1995 08:35:14 -0500 From: "Jeff Young" <young@mci.net> steve, MCI has implemented a multicast backbone. I'm currently turning up early implementors (downstream ISP's, universities, etc...). I have configuration routines written and am working on monitoring routines, which means i have to rely on the tunnel endpoints to tell me when things aren't working until i'm finished. If you're willing to be a part of this group i can turn you up immediately. our infrastructure is dec alpha running mrouted 3.6. We require that tunnel endpoints implement an mrouted capable of pruning. other than that, we reserve the right to move the tunnel to a point closer to you when more machines become available (I'm waiting on OS upgrades to about half of the alpha's to run mcast). Our efforts are intended to reduce the number of tunnels that cross our backbone from customer to customer or customer to non-customer. Obviously, the information you were given is pretty damaging to this goal. Please let me know who has given you this information. regards, Jeff Young young@mci.net mbone@mci.net > Return-Path: list-mgr@ISI.EDU > Received: from venera.isi.edu (venera.isi.edu [128.9.0.32]) by postoffice.reston.mci.net (8.6.12/8.6.6) with SMTP id CAA09911; Sun, 29 Oct 1995 02:05:41 -0500 > Received: by venera.isi.edu (5.65c/5.61+local-22) > id <AA02077>; Sat, 28 Oct 1995 23:00:23 -0700 > Received: by venera.isi.edu (5.65c/5.61+local-22) > id <AA01770>; Sat, 28 Oct 1995 22:59:31 -0700 > Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) > id <AA01761>; Sat, 28 Oct 1995 22:59:30 -0700 > Received: from darkstar.isi.edu by quark.isi.edu (5.65c/5.61+local-20) > id <AA03161>; Sat, 28 Oct 1995 16:26:56 -0700 > Received: from millennianet.com by darkstar.isi.edu (5.65c/5.61+local-20) > id <AA00353>; Sat, 28 Oct 1995 13:44:25 -0700 > Received: (from steve@localhost) by millennianet.com (8.6.12/8.6.12.950904.SGI) id UAA19164; Sat, 28 Oct 1995 20:24:34 GMT > Date: Sat, 28 Oct 1995 13:24:32 -0700 (PDT) > From: {Darkavich} <steve@millennianet.com> > To: mbone@ISI.EDU > Subject: Mbone feed > Message-Id: <Pine.SGI.3.91.951028131815.18911H-100000@millennianet.com> > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > I would like to requst an mbone feed from someone that is close to the > MCI backbone. It appears that MCI's position is they will not be > offering MBONE services in the next 6-12 months. And there is some doubt > as to when they will offer it, if ever. > > If there is some kind soul that would be willing to send us a feed I > would greatly apreciate it. In addition, if there are any other MCI > customers dealing with this same problem, I will be more than happy to be > the central tunnel hub for these customers, at least until MCI can get > their act together. > > Thanks in advance. > > ------------------------------------------------------------------- > Steven Misrack (619) 623-1600 x325 (voice) > MillenniaNet (619) 623-1603 (fax) > Vice President, Technology. > steve@MillenniaNet.COM > > From list-mgr@ISI.EDU Mon Oct 30 08:45:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21453>; Mon, 30 Oct 1995 12:46:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21429>; Mon, 30 Oct 1995 12:45:32 -0800 Received: from charlie.acc.iit.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA21415>; Mon, 30 Oct 1995 12:45:28 -0800 Received: by charlie.acc.iit.edu (950215.SGI.8.6.10/940406.SGI) for mbone@isi.edu id OAA23262; Mon, 30 Oct 1995 14:45:04 -0600 From: vonb@charlie.acc.iit.edu (Robert Von Borstel) Message-Id: <199510302045.OAA23262@charlie.acc.iit.edu> Subject: subscribe To: mbone Date: Mon, 30 Oct 1995 14:45:04 -0600 (CST) Content-Type: text Content-Length: 238 subscribe Robert Von Borstel . email:vonb@iit.edu Illinois Institute of Technology . NeXTmail:vonb@fred.iit.edu Information Technologies (312) 567 5809 (fax) x5968 10 West 31st Street Chicago, Ill 60616 From list-mgr@ISI.EDU Wed Nov 1 02:18:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26863>; Tue, 31 Oct 1995 02:20:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26823>; Tue, 31 Oct 1995 02:18:28 -0800 Received: from solar.cc.nus.sg by venera.isi.edu (5.65c/5.61+local-22) id <AA26806>; Tue, 31 Oct 1995 02:18:19 -0800 Received: (from ccetky@localhost) by solar.cc.nus.sg (8.6.9/8.6.9) id SAA12529 for mbone@isi.edu; Tue, 31 Oct 1995 18:18:22 +0800 From: ccetky@solar.cc.nus.sg Message-Id: <199510311018.SAA12529@solar.cc.nus.sg> Subject: MBONE over ATM To: mbone Date: Tue, 31 Oct 1995 18:18:22 +0800 (SGT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 197 Hi, Would appreciate if somebody gives me some references on MBONE over ATM. Thanks in advance. Regards, Kwong-Yeong Tung Computer Centre National University of Singapore E-mail: ccetky@nus.sg From list-mgr@ISI.EDU Tue Oct 31 12:43:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05030>; Tue, 31 Oct 1995 08:45:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04839>; Tue, 31 Oct 1995 08:43:23 -0800 Received: from di.ufpe.br (recife.di.ufpe.br) by venera.isi.edu (5.65c/5.61+local-22) id <AA04809>; Tue, 31 Oct 1995 08:43:08 -0800 Received: by di.ufpe.br (4.1/SMI-4.1) id AA24131; Tue, 31 Oct 95 14:43:59 EDT Date: Tue, 31 Oct 1995 14:43:58 -0200 (EDT) From: Fernando Jose de Aguiar Sodre <fjas@di.ufpe.br> Subject: Re: MBONE over ATM To: ccetky@solar.cc.nus.sg Cc: mbone In-Reply-To: <199510311018.SAA12529@solar.cc.nus.sg> Message-Id: <Pine.3.89.9510311425.D20687-0100000@recife> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Mboners, I'm in a research about Mbone & ATM, so I would appreciatte some references about it, too. Fernando Sodre. On Tue, 31 Oct 1995 ccetky@solar.cc.nus.sg wrote: > Hi, > > Would appreciate if somebody gives me some references on MBONE over ATM. > Thanks in advance. > > Regards, > > Kwong-Yeong Tung > Computer Centre > National University of Singapore > E-mail: ccetky@nus.sg > > From list-mgr@ISI.EDU Tue Oct 31 01:47:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07606>; Tue, 31 Oct 1995 09:49:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07515>; Tue, 31 Oct 1995 09:47:24 -0800 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA07497>; Tue, 31 Oct 1995 09:47:22 -0800 Received: from icsib8.ICSI.Berkeley.EDU (icsib8.ICSI.Berkeley.EDU [128.32.201.23]) by icsia.ICSI.Berkeley.EDU (8.6.12/HUB+V8$Revision: 1.23 $) with ESMTP id JAA20019; Tue, 31 Oct 1995 09:47:08 -0800 From: whd@ICSI.Berkeley.EDU (Wieland Holfelder) Received: (whd@localhost) by icsib8.ICSI.Berkeley.EDU (8.6.12/1.8) id JAA24736; Tue, 31 Oct 1995 09:47:06 -0800 Message-Id: <199510311747.JAA24736@icsib8.ICSI.Berkeley.EDU> Subject: Re: MBONE over ATM To: ccetky@solar.cc.nus.sg Date: Tue, 31 Oct 1995 09:47:05 -0800 (PST) Cc: fjas@di.ufpe.br, mbone (Multicast Backbone) In-Reply-To: <199510311018.SAA12529@solar.cc.nus.sg> from "ccetky@solar.cc.nus.sg" at Oct 31, 95 06:18:22 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 669 ccetky@solar.cc.nus.sg writes: > Would appreciate if somebody gives me some references on MBONE over ATM. > Thanks in advance. There is e.g. the BAGNet Project which uses the MBone tools over ATM. See http://george.lbl.gov/BAGNet.html for details. -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder International Computer Science Institute Email: whd@icsi.berkeley.edu 1947 Center Street Suite 600 Fax : +1-510-642-6865 Berkeley, CA 94704-1198 Phone: +1-510-642-4274 Ext. 302 URL: http://www.icsi.berkeley.edu/~whd ------------------------------------------------------------------------------- From list-mgr@ISI.EDU Tue Oct 31 02:14:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09223>; Tue, 31 Oct 1995 10:16:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09146>; Tue, 31 Oct 1995 10:14:31 -0800 Received: from coral.llnl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA09135>; Tue, 31 Oct 1995 10:14:29 -0800 Message-Id: <199510311814.AA09135@venera.isi.edu> Received: by coral.llnl.gov (1.38.110.45/16.2) id AA232093263; Tue, 31 Oct 1995 10:14:23 -0800 Date: Tue, 31 Oct 1995 10:14:23 -0800 From: David P Wiltzius <wiltzius@coral.llnl.gov> To: ccetky@solar.cc.nus.sg, list-mgr Subject: Re: MBONE over ATM Cc: mbone Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit BAGNet uses the Mbone tools over multicast ATM. Of likely interest: http://www.llnl.gov/bagnet/bagbone.html http://chocolate.pa.dec.com/status.html BAGNet home page: http://george.lbl.gov/BAGNet.html Dave From list-mgr@ISI.EDU Mon Oct 30 06:19:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24212>; Tue, 31 Oct 1995 14:43:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24110>; Tue, 31 Oct 1995 14:42:52 -0800 Received: from gw2.att.com by venera.isi.edu (5.65c/5.61+local-22) id <AA24102>; Tue, 31 Oct 1995 14:42:37 -0800 Received: from mtgpfs1.mt.att.com by ig1.att.att.com id AA14622; Mon, 30 Oct 95 11:16:39 EST Received: from mtgpdf12.gp (mtgpdf12.mt.att.com) by mtgpfs1.mt.att.com (4.1/EMS-1.1.1 SunOS) id AA29115; Mon, 30 Oct 95 11:19:20 EST Date: Mon, 30 Oct 95 11:19:20 EST Message-Id: <9510301619.AA29115@mtgpfs1.mt.att.com> From: ldo@mtgpfs1.mt.att.com (Lawrence D Odell) To: mbone Subject: unsubscribe Unsubscribe please From list-mgr@ISI.EDU Wed Nov 1 00:33:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23660>; Tue, 31 Oct 1995 14:34:58 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23625>; Tue, 31 Oct 1995 14:34:29 -0800 Received: from artemis.rus.uni-stuttgart.de by venera.isi.edu (5.65c/5.61+local-22) id <AA23612>; Tue, 31 Oct 1995 14:34:19 -0800 Received: from kssun9.rus.uni-stuttgart.de (kssun9.rus.uni-stuttgart.de [129.69.30.19]) by artemis.rus.uni-stuttgart.de with SMTP id XAA14823 (8.6.12/IDA-1.6); Tue, 31 Oct 1995 23:34:13 +0100 Received: by kssun9.rus.uni-stuttgart.de (5.0/SVR4/BelWue-1.0) id AA06172; Tue, 31 Oct 1995 23:33:35 --100 From: "Peter Feil" <Peter.Feil@RUS.Uni-Stuttgart.DE> Message-Id: <9510312333.ZM6170@kssun9.rus.uni-stuttgart.de> Date: Tue, 31 Oct 1995 23:33:34 +0100 In-Reply-To: ccetky@solar.cc.nus.sg "MBONE over ATM" (Oct 31, 6:18pm) References: <199510311018.SAA12529@solar.cc.nus.sg> X-Mailer: Z-Mail (3.2.1 10apr95) To: ccetky@solar.cc.nus.sg, mbone Subject: Re: MBONE over ATM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 1446 On Oct 31, 6:18pm, ccetky@solar.cc.nus.sg wrote: > Subject: MBONE over ATM > Hi, > > Would appreciate if somebody gives me some references on MBONE over ATM. > Thanks in advance. > > Regards, > > Kwong-Yeong Tung > Computer Centre > National University of Singapore > E-mail: ccetky@nus.sg > >-- End of excerpt from ccetky@solar.cc.nus.sg The TERENA ATM Task Force has set up a mayor part of the international European MBONE using a CBR ATM overlay network within the European PNO ATM Pilot. This part of the MBONE has been operational for some months now, where the number of involved national and international ATM links is increasing continuously. Next week there will be the 2nd National Hosts Conference (an event co-organized by the European Commission) in Vienna where this network will be extended to the conference site. The ATM-based European MBONE will be presented to the public. More infos about this conference are available at: http://www.proin.via.at/nathost.html The WWW pages of the TERENA TF-ATM are here: http://www.terena.nl/terena/working-groups/wg-llt/task-forces/tf-atm/ Regards --------------------------------------------------------------- Peter Feil University of Stuttgart Computing Center phone : ++49-711-685 5735 Allmandring 30 fax : ++49-711-678 7626 70550 Stuttgart e-mail: feil@rus.uni-stuttgart.de Germany --------------------------------------------------------------- From list-mgr@ISI.EDU Tue Oct 31 14:42:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02170>; Tue, 31 Oct 1995 16:42:06 -0800 Received: from all-purpose-gunk.near.net by venera.isi.edu (5.65c/5.61+local-22) id <AA02162>; Tue, 31 Oct 1995 16:42:04 -0800 Received: (from jhawk@localhost) by all-purpose-gunk.near.net (8.7.1/8.7.1) id TAA10176; Tue, 31 Oct 1995 19:42:00 -0500 (EST) Date: Tue, 31 Oct 1995 19:42:00 -0500 (EST) Message-Id: <199511010042.TAA10176@all-purpose-gunk.near.net> To: mbone-na Cc: pls@astro.caltech.edu, heather@piccolo.cco.caltech.edu Subject: Today's dvmrp surge From: John Hawkinson <jhawk@bbnplanet.com> Starting at 17:23 EST (GMT-5) and ending at 19:18, a cisco at Caltech inadvertantly advertised 12k routes into the mbone. We found the source via mtrace and got it shut down. It ended up taking quite a while for dvmrp to time out once the tunnel was shut down, though--a lot more than I expected (10-20 minutes, I guess, I didn't keep careful count). Anyway, this was not the source of the problems of the previous weeks, just an isolated incident. --jhawk@bbnplanet.com John Hawkinson [all-purpose-gunk!jhawk] /var/tmp> mtrace 192.100.181.1 Mtrace from 192.100.181.1 to 198.114.157.114 via group 224.2.0.1 Querying full reverse path... 0 all-purpose-gunk.near.net (198.114.157.114) -1 all-purpose-gunk.near.net (198.114.157.114) DVMRP thresh^ 1 -18 ms -2 mbone1.ner.bbnplanet.net (199.94.207.2) DVMRP thresh^ 16 -1 ms -3 oday.psc.edu (192.88.114.10) DVMRP thresh^ 64 240773 ms -4 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 64 353 ms -5 elxr-fddi.jpl.nasa.gov (137.78.160.8) DVMRP thresh^ 32 86766 ms -6 charybdis.ipac.caltech.edu (134.4.20.89) DVMRP thresh^ 48 1219 ms -7 malibu.caltech.edu (131.215.240.186) DVMRP thresh^ 48 118771 ms Next router no mtrace -8 ? (131.215.240.127) [cisco 10.3] didn't respond [some time afterward] mbone1.ner.bbnplanet.net#sh ip d r 192.100.181.0 DVMRP Routing Table - 11053 entries 192.100.181.0/24 [0/22] uptime 00:00:55, expires 0:02:04 via 192.88.114.10, Tunnel3, [version mrouted 3.4] [flags: ] [and some time after that:] mbone1.ner.bbnplanet.net#sh ip d r 192.100.181.0 DVMRP Routing Table - 8222 entries 192.100.181.0/24 [0/28] uptime 00:00:03, expires 0:02:56 via 204.70.64.29, Tunnel7, [version mrouted 3.6] [flags: GPM] From list-mgr@ISI.EDU Tue Oct 31 14:49:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10221>; Tue, 31 Oct 1995 19:00:46 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10063>; Tue, 31 Oct 1995 18:58:28 -0800 Received: from exclusive.exclusive.com by venera.isi.edu (5.65c/5.61+local-22) id <AA10052>; Tue, 31 Oct 1995 18:58:26 -0800 From: rgarza@exclusive.com Date: Tue, 31 Oct 95 20:49 CST Message-Id: <9510312049.AA10556@exclusive.exclusive.com> Received: from exclusive.com by exclusive.exclusive.com; Tue, 31 Oct 95 20:49 CST X-Sender: rgarza@exclusive.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Length: 13 Content-Type: text/plain; charset="us-ascii" To: mbone >From: exclusive.com!rgarza (Rudy Garza) Subject: Unsubscribe unsubscribe From list-mgr@ISI.EDU Wed Nov 1 09:52:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15050>; Wed, 1 Nov 1995 12:07:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14924>; Wed, 1 Nov 1995 12:05:19 -0800 Received: from sinclair (sinclair.mathcs.duq.edu) by venera.isi.edu (5.65c/5.61+local-22) id <AA14917>; Wed, 1 Nov 1995 12:05:17 -0800 Received: from fenchel (fenchel [165.190.112.5]) by sinclair (8.6.12/8.6.12) with ESMTP id PAA08599 for <mbone@isi.edu>; Wed, 1 Nov 1995 15:04:24 -0500 From: "Matthew T. Churilla" <churilla@mathcs.duq.edu> Received: (churilla@localhost) by fenchel (8.6.12/8.6.12) id OAA13036; Wed, 1 Nov 1995 14:52:28 -0500 Date: Wed, 1 Nov 1995 14:52:28 -0500 Message-Id: <199511011952.OAA13036@fenchel> To: mbone Subject: Connecting Questions/Tunnel Setup I have just installed mrouted and other multicasting programs on a system here to establish a multicasting router. I am just wondering what steps I need to take from here to connect to the mbone. Also becuase we are a campus I tried to talk to someone at our networking provider(Prepnet) but they seem to have just lost thier networking engineer and coulnt provide me with much information as to whether they had a multicasting router that we could tunnel ours to. So I was wondering who I should get in touch with about getting a tunnel to our router. I would apperciate any help possible and am hoping to get up on the mbone soon. For some general information the campus is Duquesne University located in Pittsburgh, Pa, we are running the mrouted program from the 3.2.4v distribued on playground.sun.com for sun sparc stations. If you need any other information feel free to ask. -- Matthew Churilla Duquesne University CCIT User Consultant / Student of Computer Science E-Mail Addresses ------------------------------------------------------------------------------- churilla@noether.mathcs.duq.edu Math\Computer Science Account churilla@next.duq.edu CCIT Next Account churill5624@duq3.cc.duq.edu Duquesne University E-Mail Account ------------------------------------------------------------------------------- "The difference between the right word and the almost right word is the difference between lightning and a lightning bug." -Mark Twain ------------------------------------------------------------------------------- From list-mgr@ISI.EDU Thu Nov 2 19:01:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02003>; Thu, 2 Nov 1995 09:04:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01927>; Thu, 2 Nov 1995 09:01:42 -0800 Received: from bordeaux.nijenrode.nl by venera.isi.edu (5.65c/5.61+local-22) id <AA01916>; Thu, 2 Nov 1995 09:01:40 -0800 Received: from bordeaux.nijenrode.nl (steven@localhost [127.0.0.1]) by bordeaux.nijenrode.nl (8.7.1/8.7.1) with ESMTP id SAA13568; Thu, 2 Nov 1995 18:01:38 +0100 (MET) Message-Id: <199511021701.SAA13568@bordeaux.nijenrode.nl> X-Mailer: exmh version 1.6.4 10/10/95 To: mbone, rem-conf@es.net Subject: Broadcast of the Hewlett-Packard conference: 'Managing the Unmanagable'. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Nov 1995 18:01:37 +0100 From: Steven Hessing <steven@nijenrode.nl> Thursday, November 30th 1995, the Hewlett-Packard conference: Industrial Round Table: `Managing the Unmanagable' will take place at Nijenrode University. We would like to broadcast this conference over the Mbone. We hope the broadcast will not conflict with any other planned broadcasts. We've entered our broadcast into the agenda's on: http://www.cilea.it/MBone/agenda.html http://www.msri.org/mbone/ The broadcast will take place on 30 Nov 95 from 12:00 GMT until 19:00 GMT. Information about the conference can be found on http://www.nijenrode.nl/conference/ The schedule for the conference (all times in GMT): MANAGING THE UNMANAGEABLE November, 30th 1995 - Nijenrode University "The future organization will have a home base, to be sure, but few, if any of its staff or managers will actually be there". One day soon, everybody will have a personal phone, a personal mobile computer and work will not belong to a certain place. Management will learn to handle and manage those whom they do not see. Like it or not, the mixture of economics and technology will mean that more of us will be spending time in this virtual space. Will this vision become reality? Will the virtual organization take off? How will it be managed? How will the teams be motivated? What will it mean to the leadership? What new skills will be called for? If notions of space and distance diasppear, everybody has access to unlimited information, the world will be shaped by globalization and information. Will this lead to chaos and order? How do we manage the unmanageable? THE PARTICIPANTS His Excellency Dr. Hans Wijers, Minister of Economic Affairs Keynote speaker Professor Nicholas Negroponte, Director of MIT's Media Laboratory Keynote speaker Karel van Miert, Member of the European Commission Member of the Panel Alex Sozonoff, Vice President Hewlett-Packard Company Member of the Panel Ben Verwayen, President PTT Telecom, Member of the Board of Royal PTT Nederland N.V. Member of the Panel Steve Ballmer, Executive Vice President Microsoft Corporation Participating via video conferencing Dr. Vinton G. Cerf, Senior Vice President Data Architecture Data Services MCI Telecommunications, Co-developer of the Internet Participating via video conferencing 12.30 Arrival of guests at Nijenrode University 13.00 Welcome and introductions by Mrs. Neelie Kroes, President of Nijenrode University and Mr. Hans van der Velde, Managing Director of Hewlett-Packard Nederland B.V. 13.10 Keynote address by His Excellency Dr. Hans Wijers 13.40 Keynote address by Professor Nicholas Negroponte 14.20 Tea Break 14.45 Panel discussion Moderator: Michiel Bicker Caarten Participants: - Peter Booone - Professor Stephane Garelli - Karel van Miert - Prefessor Nicholas Negroponte - Alex Sozonoff - Ben Verwayen 16.15 Video conferencing with: - Steve Ballmer - Dr. Vinton Cerf 17.00 Cocktails 18.00 End of program -- Steven From list-mgr@ISI.EDU Thu Nov 2 02:29:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07487>; Thu, 2 Nov 1995 10:41:51 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06824>; Thu, 2 Nov 1995 10:29:51 -0800 Received: from sgi.sgi.com (SGI.COM) by venera.isi.edu (5.65c/5.61+local-22) id <AA06817>; Thu, 2 Nov 1995 10:29:49 -0800 Received: from tree.engr.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for <@sgi.engr.sgi.com:mbone@ISI.EDU> id KAA24551; Thu, 2 Nov 1995 10:29:48 -0800 Received: by tree.engr.sgi.com (940816.SGI.8.6.9/911001.SGI) for mbone@ISI.EDU id KAA07240; Thu, 2 Nov 1995 10:29:47 -0800 From: "Bill Nowicki" <nowicki@tree.engr.sgi.com> Message-Id: <9511021029.ZM7238@tree.engr.sgi.com> Date: Thu, 2 Nov 1995 10:29:44 -0800 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: mbone Subject: mrouted 3.6 for Silicon Graphics Computers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Just wanted to remind people that mrouted 3.6 is an officially supported standard part of the IRIX 6.2 operating system from Silicon Graphics. Thanks to James Yarbrough, we also have a back-port to IRIX 5.3 available. Here are details: ----------------------------- Last updated: October 30, 1995 Located in ftp://ftp.sgi.com/sgi/ipmcast/IRIX5/5.3/mrouted3.6.tar.Z This is a set of changes to the multicast routing support for IRIX 5.3 to include the release 3.5 of the kernel modules, and 3.6 of mrouted. Copy the correct bsd.a and ip_mroute.o to your /var/sysgen/boot, copy mrouted, and reboot. There is also a new netstat needed for the -M and -Ms options to work. Note the -C option of netstat and screen "8" to get detailed statistics. cp bsd.a.<type> /var/sysgen/boot/bsd.a cp ip_mroute.o.<type> /var/sysgen/boot/ip_mroute.o cp mrouted netstat /usr/etc autoconfig reboot Where the <type> is: IP19 Challenge L and XL, Onyx L and XL IP20 Indigo with R4000 IP22 Indy, Indigo 2, and Challenge S IP5 Older R3000 machines, including IP7 (not tested) IP12 Original R3000 Indigo (not tested) For example, for IP22: cp bsd.a.IP22 /var/sysgen/boot/bsd.a cp ip_mroute.o.IP22 /var/sysgen/boot/ip_mroute.o cp mrouted netstat /usr/etc autoconfig reboot Limitations: The new features have not been extensively tested. In a network with mrouted 3.4, you will messages complaining about "duplicate prunes", due to 3.4 bugs. These are limited to one every ten minutes, and can be safely ignored, or upgrade the offending routers to mrouted 3.6. This bsd.a includes the fixes in Patch 317 and Patch 530 to fix some TCP and UDP problems on busy servers. If you are NOT running patch 530, then tpisocket.a might be incompatible (i.e. svr4net programs might hang). If you get an error about "somaxconn" not being defined, it means you have not installed patch 317 or 530. Copy the "bsd" file here into the /var/sysgen/master.d directory. If you get an error about "swinput" etc. being undefined then you need to copy if_sw into /var/sysge/master.d (from Patch 639) and add a "USE: if_sw" line to irix.sm. The IRIX 6.1 release already includes mrouted 3.4 so use the installed binaries if you are running IRIX 6.1. The IRIX 6.2 release has mrouted 3.6, so just use the installed binaries. Please report any problems to nowicki@SGI.COM From list-mgr@ISI.EDU Thu Nov 2 22:10:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12731>; Thu, 2 Nov 1995 12:12:47 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12524>; Thu, 2 Nov 1995 12:11:09 -0800 Received: from bordeaux.nijenrode.nl by venera.isi.edu (5.65c/5.61+local-22) id <AA12482>; Thu, 2 Nov 1995 12:10:35 -0800 Received: from bordeaux.nijenrode.nl (steven@localhost [127.0.0.1]) by bordeaux.nijenrode.nl (8.7.1/8.7.1) with ESMTP id VAA15319 for <mbone@isi.edu>; Thu, 2 Nov 1995 21:10:05 +0100 (MET) Message-Id: <199511022010.VAA15319@bordeaux.nijenrode.nl> To: mbone Subject: NV on a HP 715/100 with Paralex grabber Date: Thu, 02 Nov 1995 21:10:04 +0100 From: Steven Hessing <steven@nijenrode.nl> As you may have read earlier tonight, we're going to broadcast an HP conference over the Mbone. For this purpose, HP has made available an HP 715/100 with a Paralex Graphics Power Video 700. The OS version is 9.07. With this machine we have two problems: - nv-3.3beta does not seem to support the Paralex card. - the color recovery hardware in the 715/100 messes up the nv output. With vat we didn't have any problems although the Vat www-page indicated that we might have some trouble. Does anyone have a solution to the nv problems we experience? -- Steven From list-mgr@ISI.EDU Thu Nov 2 11:08:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04471>; Thu, 2 Nov 1995 19:09:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04429>; Thu, 2 Nov 1995 19:08:15 -0800 Received: from trout.nosc.mil by venera.isi.edu (5.65c/5.61+local-22) id <AA04422>; Thu, 2 Nov 1995 19:08:13 -0800 Received: from marlin.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA23769; Thu, 2 Nov 95 19:08:12 PST Received: by marlin.nosc.mil (4.1/SMI-4.1) id AA16534; Thu, 2 Nov 95 19:08:19 PST From: ganzer@marlin.nosc.mil (Mark T. Ganzer) Message-Id: <9511030308.AA16534@marlin.nosc.mil> Subject: Re: NV on a HP 715/100 with Paralex grabber To: steven@nijenrode.nl (Steven Hessing) Date: Thu, 2 Nov 1995 19:08:18 -0800 (PST) Cc: mbone In-Reply-To: <199511022010.VAA15319@bordeaux.nijenrode.nl> from "Steven Hessing" at Nov 2, 95 09:10:04 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 807 > As you may have read earlier tonight, we're going to broadcast > an HP conference over the Mbone. For this purpose, HP has made > available an HP 715/100 with a Paralex Graphics Power Video 700. > The OS version is 9.07. > > With this machine we have two problems: > - nv-3.3beta does not seem to support the Paralex card. Our experience has been the same as yours. Parallax said the card was compatable with the VideoLive card, however it did not work as they advertised. The only suggestion I have is to see if the new VIC 2.7alpha has added Parallax support for the HP (I know Parallax support for the Sun was added). Mark Ganzer Naval Command, Control & Ocean Surveillance Center, ganzer@nosc.mil RDT&E Div (NRaD), Code 4123, San Diego, CA Ph: (619) 553-1186 FAX: (619) 553-4808 From list-mgr@ISI.EDU Fri Nov 3 10:24:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13729>; Fri, 3 Nov 1995 00:28:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13704>; Fri, 3 Nov 1995 00:27:13 -0800 Received: from tuminfo2.informatik.tu-muenchen.de by venera.isi.edu (5.65c/5.61+local-22) id <AA13678>; Fri, 3 Nov 1995 00:26:30 -0800 Received: from hpschlichter8.informatik.tu-muenchen.de ([131.159.24.23]) by tuminfo2.informatik.tu-muenchen.de with SMTP id <26539-2>; Fri, 3 Nov 1995 09:26:06 +0100 Received: by hpschlichter8.informatik.tu-muenchen.de id <49409>; Fri, 3 Nov 1995 09:26:02 +0100 Subject: Re: NV on a HP 715/100 with Paralex grabber From: Tristan Daude <daude@informatik.tu-muenchen.de> To: steven@nijenrode.nl (Steven Hessing) Date: Fri, 3 Nov 1995 09:24:36 +0100 Cc: mbone In-Reply-To: <199511022010.VAA15319@bordeaux.nijenrode.nl> from "Steven Hessing" at Nov 2, 95 09:10:04 pm Organization: Technische Universitaet Muenchen, Institut fuer Informatik, (West Germany) Reply-To: daude@informatik.tu-muenchen.de X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1496 Message-Id: <95Nov3.092602mesz.49409@hpschlichter8.informatik.tu-muenchen.de> > > As you may have read earlier tonight, we're going to broadcast > an HP conference over the Mbone. For this purpose, HP has made > available an HP 715/100 with a Paralex Graphics Power Video 700. > The OS version is 9.07. > > With this machine we have two problems: > - nv-3.3beta does not seem to support the Paralex card. > - the color recovery hardware in the 715/100 messes up the nv > output. > > With vat we didn't have any problems although the Vat www-page > indicated that we might have some trouble. > > Does anyone have a solution to the nv problems we experience? > > -- Steven > Hi, there is another videoconferencing tool, namend "vic", that suppports the Parallax hardware on SUNs in its latest version (2.7) which is currently available in an alpha release. Parallax support was integrated into vic using the Xlib extension API from Parallax Graphics which is supported on the HP plattform as well. So if you have access to the Parallax VDE software package (containing all necessary libraries and headers) you should simply try to recompile vic under HP-UX (GNUs g++ should work ok). Information, source code and some vic binaries can be found at: http://www-nrg.ee.lbl.gov/vic/ Hope that helps, Tristan -- Tristan Daude, Technische Universitaet Muenchen, Institut fuer Informatik Arcisstr. 21, D-80290 Muenchen, Germany, +49 89 450552-24 Email: daude@informatik.tu-muenchen.de WWW: http://www11.informatik.tu-muenchen.de/local/persons/daude.html From list-mgr@ISI.EDU Fri Nov 3 10:12:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16537>; Fri, 3 Nov 1995 02:13:09 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16520>; Fri, 3 Nov 1995 02:12:19 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA16512>; Fri, 3 Nov 1995 02:12:11 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id KAA10951; Fri, 3 Nov 1995 10:12:08 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id KAA13943; Fri, 3 Nov 1995 10:12:01 GMT Date: Fri, 3 Nov 1995 10:12:00 +0000 (GMT) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Steven Hessing <steven@nijenrode.nl> Cc: mbone Subject: Re: NV on a HP 715/100 with Paralex grabber In-Reply-To: <199511022010.VAA15319@bordeaux.nijenrode.nl> Message-Id: <Pine.SV4.3.91.951103100914.13753A-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 2 Nov 1995, Steven Hessing wrote: > As you may have read earlier tonight, we're going to broadcast > an HP conference over the Mbone. For this purpose, HP has made > available an HP 715/100 with a Paralex Graphics Power Video 700. > The OS version is 9.07. > > With this machine we have two problems: > - nv-3.3beta does not seem to support the Paralex card. It does but maybe the HP binary does not contain support. The SunOS versions do. If you have the Parallax development environment then you should be able to compile up nv from source with the Parallax option. > - the color recovery hardware in the 715/100 messes up the nv > output. Cannot help you with this I am afraid - don't know much about HPs > With vat we didn't have any problems although the Vat www-page > indicated that we might have some trouble. > > Does anyone have a solution to the nv problems we experience? > > -- Steven > ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Fri Nov 3 12:40:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13513>; Fri, 3 Nov 1995 14:41:32 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13500>; Fri, 3 Nov 1995 14:41:03 -0800 Received: from clone4.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA13493>; Fri, 3 Nov 1995 14:41:00 -0800 Received: from localhost (localhost.mci.net [127.0.0.1]) by clone4.reston.mci.net (8.6.12/8.6.6) with ESMTP id RAA00231; Fri, 3 Nov 1995 17:40:47 -0500 Message-Id: <199511032240.RAA00231@clone4.reston.mci.net> To: mbone Cc: young@mci.net Subject: kernel panics in sunos 4.1.4 mrouted kernel Date: Fri, 03 Nov 1995 17:40:46 -0500 From: "Jeff Young" <young@mci.net> running sunos 4.1.4 with bpf and multicast support, i've been having a problem about once a day for the last few days. dmesg shows: DMA_SETUP failed in play! DMA_SETUP failed in play! DMA_SETUP failed in record! DMA_SETUP failed in record! and the machine is suddenly unresponsive. everything continues to function, the machines becomes a television set (which would be ok with me except that the screen saver kicks in:-)). No input is possible, mouse works, no keyboard. the same kernel has been working flawlessly for a week in a similar sparc5. this machine is a sparc5. i'm thinking that this is a hardware problem. any thoughts? Jeff Young young@mci.net From list-mgr@ISI.EDU Sun Nov 5 05:54:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16053>; Sun, 5 Nov 1995 11:07:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16039>; Sun, 5 Nov 1995 11:07:05 -0800 Received: from shellx.best.com by venera.isi.edu (5.65c/5.61+local-22) id <AA16032>; Sun, 5 Nov 1995 11:07:04 -0800 Received: from prince.vip.best.com (prince.vip.best.com [204.156.152.199]) by shellx.best.com (950911.SGI.8.6.12.PATCH825/8.6.5) with SMTP id TAA20110; Sun, 5 Nov 1995 19:06:56 GMT Message-Id: <199511051906.TAA20110@shellx.best.com> X-Sender: prince@pop.best.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 05 Nov 1995 09:54:56 -0400 To: mbone From: vinay@mbone.com (Vinay Kumar) Subject: An FYI: First MBone book available Cc: vinay@mbone.com X-Mailer: <PC Eudora Version 1.4b22> [Just an FYI] The first MBone book is now available at book stores near you. The book is called "MBone: Interactive Multimedia On The Internet", Macmillan Publishing, Simon & Schuster, ISBN: 1-56205-397-3. The book mainly focusses on helping organizations who have heard about the mystical MBone and want to experience it but don't know how ? The book should help popularise the MBone more in the right way, atleast that is my hope. Read the book for more details, and please feel free to send in your comments back to me at: vinay@mbone.com. Thanks to all my partners who helped me in this project, their names are quite clearly acknowledged in the book as well. Regards --- Vinay Kumar vinay@mbone.com http://www.mbone.com/techinfo/ From list-mgr@ISI.EDU Sun Nov 5 13:40:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14444>; Sun, 5 Nov 1995 21:37:50 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14424>; Sun, 5 Nov 1995 21:36:46 -0800 Received: from fawn.cs.wwu.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA14417>; Sun, 5 Nov 1995 21:36:45 -0800 Received: (from phil@localhost) by fawn.cs.wwu.edu (8.6.10/8.6.10) id VAA02055; Sun, 5 Nov 1995 21:40:23 -0800 Date: Sun, 5 Nov 1995 21:40:23 -0800 From: Phil Nelson <phil@cs.wwu.edu> Message-Id: <199511060540.VAA02055@fawn.cs.wwu.edu> To: vinay@mbone.com Cc: mbone, vinay@mbone.com In-Reply-To: <199511051906.TAA20110@shellx.best.com> (vinay@mbone.com) Subject: Re: An FYI: First MBone book available >[Just an FYI] > >The first MBone book is now available at book stores near you. The book is >called "MBone: Interactive Multimedia On The Internet", Macmillan >Publishing, Simon & Schuster, ISBN: 1-56205-397-3. The book mainly focusses >on helping organizations who have heard about the mystical MBone and want to You can order it on-line at http://www.mcp.com. -- Phil Nelson e-mail: phil@cs.wwu.edu http://www.cs.wwu.edu/~phil From list-mgr@ISI.EDU Sun Nov 5 18:11:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21666>; Mon, 6 Nov 1995 02:13:55 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21653>; Mon, 6 Nov 1995 02:11:48 -0800 Received: from blob.best.net by venera.isi.edu (5.65c/5.61+local-22) id <AA21646>; Mon, 6 Nov 1995 02:11:45 -0800 Received: from rsf.vip.best.com (rsf.vip.best.com [204.156.129.162]) by blob.best.net (8.6.12/8.6.5) with SMTP id CAA07238; Mon, 6 Nov 1995 02:11:43 -0800 Date: Mon, 6 Nov 1995 02:11:43 -0800 Message-Id: <199511061011.CAA07238@blob.best.net> X-Sender: rsf@pop.best.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: vinay@mbone.com (Vinay Kumar), mbone From: Ross Finlayson <finlayson@live.com> Subject: Re: An FYI: First MBone book available At 09:54 AM 11/5/95 -0400, Vinay Kumar wrote: >The first MBone book is now available at book stores near you. The book is >called "MBone: Interactive Multimedia On The Internet", Macmillan >Publishing, Simon & Schuster, ISBN: 1-56205-397-3. The book mainly focusses >on helping organizations who have heard about the mystical MBone and want to >experience it but don't know how ? The book should help popularise the MBone >more in the right way, atleast that is my hope. I took a quick look at the cover of the book (which is online at http://www.mcp.com/56517862763006/bookstore/computer/nrp/isbn3_5/graphics/n3 973f.gif), and I have to say that I'm disturbed by the prominent heading: "Discover how you can broadcast, advertise, and display your products on the Internet" This is at best misleading, and at worst irresponsible. While I'm sure that significant commercial use of the MBone will occur in the future, I'm not sure how loudly we should be encouraging this at this time, given the bandwidth limitations of the current infrastructure. Ross (who's dreading the arrival of the first spammed "MBone informercial") From list-mgr@ISI.EDU Mon Nov 6 02:00:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27257>; Mon, 6 Nov 1995 07:12:54 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27239>; Mon, 6 Nov 1995 07:12:30 -0800 Received: from shellx.best.com by venera.isi.edu (5.65c/5.61+local-22) id <AA27232>; Mon, 6 Nov 1995 07:12:28 -0800 Received: from prince.vip.best.com (prince.vip.best.com [204.156.152.199]) by shellx.best.com (950911.SGI.8.6.12.PATCH825/8.6.5) with SMTP id PAA13930; Mon, 6 Nov 1995 15:12:18 GMT Message-Id: <199511061512.PAA13930@shellx.best.com> X-Sender: prince@pop.best.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Nov 1995 06:00:41 -0400 To: Ross Finlayson <finlayson@live.com> From: vinay@mbone.com (Vinay Kumar) Subject: Re: An FYI: First MBone book available Cc: mbone X-Mailer: <PC Eudora Version 1.4b22> I wish i had that much control over the cover design of the book. If you read the book, you will know that i have made every attempt to highlight the BW limitations, BW fair use, and fair pricing issues....so go buy a copy !:) Regards --- Vinay Kumar vinay@mbone.com > >I took a quick look at the cover of the book (which is online at >http://www.mcp.com/56517862763006/bookstore/computer/nrp/isbn3_5/graphics/n3 >973f.gif), and I have to say that I'm disturbed by the prominent heading: > > "Discover how you can broadcast, advertise, and display your products > on the Internet" > >This is at best misleading, and at worst irresponsible. While I'm sure that >significant commercial use of the MBone will occur in the future, I'm not >sure how loudly we should be encouraging this at this time, given the >bandwidth limitations of the current infrastructure. > > Ross (who's dreading the arrival of the first spammed "MBone >informercial") > > From list-mgr@ISI.EDU Mon Nov 6 07:47:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14043>; Mon, 6 Nov 1995 11:49:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13990>; Mon, 6 Nov 1995 11:48:26 -0800 Received: from piglet.coe.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA13973>; Mon, 6 Nov 1995 11:48:18 -0800 Received: from most.coe.missouri.edu (most.coe.missouri.edu [128.206.59.186]) by piglet.coe.missouri.edu (8.7.1/8.7.1) with SMTP id NAA00647; Mon, 6 Nov 1995 13:47:54 -0600 (CST) Date: Mon, 6 Nov 1995 13:47:54 -0600 (CST) From: Tymm Twillman <tymm@tie.missouri.edu> X-Sender: tymm@most.coe.missouri.edu To: Vinay Kumar <vinay@mbone.com> Cc: Ross Finlayson <finlayson@live.com>, mbone Subject: Re: An FYI: First MBone book available In-Reply-To: <199511061512.PAA13930@shellx.best.com> Message-Id: <Pine.SGI.3.91.951106134607.4843B-100000@most.coe.missouri.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 6 Nov 1995, Vinay Kumar wrote: > I wish i had that much control over the cover design of the book. If you > read the book, you will know that i have made every attempt to highlight the > BW limitations, BW fair use, and fair pricing issues....so go buy a copy !:) > Regards > --- > Vinay Kumar > vinay@mbone.com > > > > >I took a quick look at the cover of the book (which is online at > >http://www.mcp.com/56517862763006/bookstore/computer/nrp/isbn3_5/graphics/n3 > >973f.gif), and I have to say that I'm disturbed by the prominent heading: > > > > "Discover how you can broadcast, advertise, and display your products > > on the Internet" > > > >This is at best misleading, and at worst irresponsible. While I'm sure that > >significant commercial use of the MBone will occur in the future, I'm not > >sure how loudly we should be encouraging this at this time, given the > >bandwidth limitations of the current infrastructure. > > > > Ross (who's dreading the arrival of the first spammed "MBone > >informercial") > > > > ... Did you also make every attempt to highlight the severe adversion that the members of the MBone community have to advertisement spamming? :) (speaking, at least, for myself)... -Tymm From list-mgr@ISI.EDU Mon Nov 6 04:17:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16476>; Mon, 6 Nov 1995 12:18:32 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16420>; Mon, 6 Nov 1995 12:17:51 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA16413>; Mon, 6 Nov 1995 12:17:49 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16650(4)>; Mon, 6 Nov 1995 12:17:22 PST Received: by crevenia.parc.xerox.com id <177479>; Mon, 6 Nov 1995 12:17:17 -0800 From: Bill Fenner <fenner@parc.xerox.com> To: mbone Subject: Black holes caused by aggregation Message-Id: <95Nov6.121717pst.177479@crevenia.parc.xerox.com> Date: Mon, 6 Nov 1995 12:17:16 PST As I described in a message to the MBONE mailing list in October, injecting both a general route and more-specific routes will cause black holes for traffic originating from hosts that are covered by the more specific routes. What follows is a list of networks that are affected by this problem. The responsible people for these networks should either: a) Configure whatever router is injecting the general route to only inject specific routes b) Configure your topology in such a way that you can configure a single router to inject a single general route without requiring any more-specific routes. As I said before, of course, the proper solution is to get the MBONE to support longest-match routing; however, mrouted versions previous to 3.5 do not support longest-match routing and will cause black holes. Bill IANA (RESERVED-6) 10.1.1/24 is covered by 10/8 10.1.2/24 is covered by 10/8 10.1.3/24 is covered by 10/8 10.1.4/24 is covered by 10/8 10.1.5/24 is covered by 10/8 10.1.6/24 is covered by 10/8 10.1.7/24 is covered by 10/8 10.1.8/24 is covered by 10/8 10.1.9/24 is covered by 10/8 10.1.11/24 is covered by 10/8 10.1.12/24 is covered by 10/8 10.1.13/24 is covered by 10/8 10.1.14/24 is covered by 10/8 10.1.15/24 is covered by 10/8 Stanford University (NET-SU-NET-TEMP) Networking Systems Pine Hall 115 Stanford, CA 94305 36.18/16 is covered by 36/8 36.53/16 is covered by 36/8 36.56/16 is covered by 36/8 36.103/16 is covered by 36/8 36.153/16 is covered by 36/8 36.224/16 is covered by 36/8 University of California (NET-UCB-ETHER) EECS Division 573 Evans Hall Berkeley, CA 94720 128.32.226/24 is covered by 128.32/16 Ohio State Univeristy (NET-OHIO-STATE) Academic Tecnology Services 1971 Neil Avenue - Room 406 Columbus, OH 43210-1210 128.146.2/24 is covered by 128.146/16 128.146.25/24 is covered by 128.146/16 128.146.111/24 is covered by 128.146/16 128.146.112/24 is covered by 128.146/16 128.146.116/24 is covered by 128.146/16 128.146.222/24 is covered by 128.146/16 University of Illinois, CCSO (NET-UIUC-CAMPUS-B) 1304 West Springfield Avenue Urbana, IL 61801-2910 US 128.174.212.0/25 is covered by 128.174/16 128.174.240/24 is covered by 128.174/16 RedIRIS (NET-IRIS) RedIRIS/CSIC Serrano 142 28006 Madrid SPAIN 130.206.0/23 is covered by 130.206/16 130.206.193/24 is covered by 130.206/16 Naval Research Laboratory (NET-NRL-NETS) 4555 Overlook Avenue, SW Washington, DC 20375-5000 132.250.88.170/32 is covered by 132.250.88.160/28 Jet Propulsion Laboratory (NET-JPL-NET2) Communications and Computing Network Services Section 4800 Oak Grove Drive Pasadena, CA 91109 137.78.32/24 is covered by 137.78/16 137.78.80.0/25 is covered by 137.78/16 137.78.80.128/25 is covered by 137.78/16 137.78.96/24 is covered by 137.78/16 137.78.160/24 is covered by 137.78/16 137.78.252/24 is covered by 137.78/16 Telecom Paris (NET-FNET-ESNET) Centre de Calcul 46, rue Barrault 75634 Paris Cedex 13 FRANCE 137.194.98/23 is covered by 137.194/16 137.194.224/23 is covered by 137.194/16 137.194.230/23 is covered by 137.194/16 137.194.232/23 is covered by 137.194/16 NASA/Johnson Space Center (NET-JIN) Mail Code FD32 Houston, TX 77058 139.169.162/24 is covered by 139.169/16 LSI Logic Corporation (NET-LSIL) 1501 McCarthy Boulevard Milpitas, CA 95035 147.145.99/24 is covered by 147.145/16 inetnum: 194.104.0.0 netname: SN-IP-ATM descr: SURFnet IP-over-ATM network descr: Europe country: NL admin-c: Victor Reijs tech-c: Victor Reijs changed: Erik-Jan.Bos@surfnet.nl 950320 source: RIPE 194.104.0.52/30 is covered by 194.104.0/24 From list-mgr@ISI.EDU Tue Nov 7 11:41:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18558>; Tue, 7 Nov 1995 13:53:17 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18359>; Tue, 7 Nov 1995 13:49:28 -0800 Received: from liman.rutgers.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA18349>; Tue, 7 Nov 1995 13:49:24 -0800 Received: from winlab8.rutgers.edu by liman.rutgers.edu (5.x/SMI-SVR4) id AA06089; Tue, 7 Nov 1995 16:36:14 -0500 Received: by winlab8.rutgers.edu (5.x/SMI-SVR4) id AA06666; Tue, 7 Nov 1995 16:41:56 -0500 Date: Tue, 7 Nov 1995 16:41:56 -0500 From: bcshin@winlab.rutgers.edu (Byung-Cheol Shin) Message-Id: <9511072141.AA06666@winlab8.rutgers.edu> To: mbone Subject: unsubscribe Cc: bcshin@winlab.rutgers.edu X-Sun-Charset: US-ASCII unsubscribe From list-mgr@ISI.EDU Tue Nov 7 06:32:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21043>; Tue, 7 Nov 1995 14:35:15 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20875>; Tue, 7 Nov 1995 14:32:22 -0800 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA20868>; Tue, 7 Nov 1995 14:32:20 -0800 Received: from icsib8.ICSI.Berkeley.EDU (whd@icsib8.ICSI.Berkeley.EDU [128.32.201.23]) by icsia.ICSI.Berkeley.EDU (8.6.12/HUB+V8$Revision: 1.23 $) with ESMTP id OAA25645; Tue, 7 Nov 1995 14:32:18 -0800 From: whd@ICSI.Berkeley.EDU (Wieland Holfelder) Received: (whd@localhost) by icsib8.ICSI.Berkeley.EDU (8.6.12/1.8) id OAA00545; Tue, 7 Nov 1995 14:32:16 -0800 Message-Id: <199511072232.OAA00545@icsib8.ICSI.Berkeley.EDU> Subject: ACM Multimedia Transmission To: mbone (Multicast Backbone), rem-conf@es.net (Remote Conferencing) Date: Tue, 7 Nov 1995 14:32:15 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 671 We'd like to get some feedback on how the ACM MM95 audio/video feed on the MBone is received outside the conference's local net. If you have any comments, please send them either to the list, to whd@icsi.berkeley.edu or to redell@pa.dec.com. Thanks, -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder International Computer Science Institute Email: whd@icsi.berkeley.edu 1947 Center Street Suite 600 Fax : +1-510-642-6865 Berkeley, CA 94704-1198 Phone: +1-510-642-4274 Ext. 302 URL: http://www.icsi.berkeley.edu/~whd ------------------------------------------------------------------------------- From list-mgr@ISI.EDU Tue Nov 7 11:46:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26067>; Tue, 7 Nov 1995 15:50:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25931>; Tue, 7 Nov 1995 15:47:06 -0800 Received: from sunkiller.isdn.uiuc.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA25923>; Tue, 7 Nov 1995 15:47:03 -0800 Received: from [128.174.33.159] (tobago.cso.uiuc.edu [128.174.33.159]) by sunkiller.isdn.uiuc.edu (8.7.1/8.7.1) with ESMTP id RAA00677; Tue, 7 Nov 1995 17:47:48 -0600 X-Sender: kline@tampico.cso.uiuc.edu Message-Id: <v03003b0aacc5a00b40db@[128.174.33.159]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 7 Nov 1995 17:46:56 -0600 To: Bill Fenner <fenner@parc.xerox.com>, mbone From: Charley Kline <kline@uiuc.edu> Subject: Re: Black holes caused by aggregation Hi, I'm responsible for the 128.174 stuff. I used to inject just 128.174/16 as my local multicast fabric was all Proteon MOSPF. But I'm replacing the Proteon routers with Ciscos and using tunnels from the MOSPF-mbone gateway to far points on the net to preserve connectivity. Apparently Proteon's multicast routing code isn't smart enough to aggregate the tunnels into the main MOSPF advertisement. I'll take care of this as soon as I can. /cvk From list-mgr@ISI.EDU Thu Nov 9 08:38:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28216>; Wed, 8 Nov 1995 06:39:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28206>; Wed, 8 Nov 1995 06:38:54 -0800 Received: from eekaist.kaist.ac.kr by venera.isi.edu (5.65c/5.61+local-22) id <AA28198>; Wed, 8 Nov 1995 06:38:49 -0800 Received: by eekaist.kaist.ac.kr (8.6.9H1/8.6.4) id XAA05057 From: Byung-Cheol Shin <bcshin@eekaist.kaist.ac.kr> Message-Id: <199511081438.XAA05057@eekaist.kaist.ac.kr> Subject: unsubscribe To: mbone Date: Wed, 8 Nov 1995 23:38:13 +0900 (JST) Cc: bcshin@eekaist.kaist.ac.kr (Byung-Cheol Shin ) X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 13 unsubscribe From list-mgr@ISI.EDU Sun Nov 8 19:08:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03255>; Wed, 8 Nov 1995 09:12:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02860>; Wed, 8 Nov 1995 09:09:51 -0800 Received: from sun-rise.sikt.hk-r.se by venera.isi.edu (5.65c/5.61+local-22) id <AA02848>; Wed, 8 Nov 1995 09:09:48 -0800 Received: from clark.hk-r.se (clark [194.47.159.24]) by sun-rise.sikt.hk-r.se (8.6.11/8.6.11) with SMTP id SAA04306; Wed, 8 Nov 1995 18:09:03 +0100 Received: by clark.hk-r.se (5.x/SMI-SVR4) id AA01220; Wed, 8 Nov 1995 18:08:33 +0100 Sender: mpt95aes@clark.pt.hk-r.se To: mbone Cc: sinji-t@is.aist-nara.ac.jp Subject: Re: vat problem on BSDI+SOUNDBLASTER References: <9511081658.AA19470@alpha211.aist-nara.ac.jp> From: Andy (Flognat) Eskilsson <mpt95aes@pt.hk-r.se> Date: 08 Nov 1995 18:08:32 +0100 In-Reply-To: =?ISO-2022-JP?B?GyRCRFhMbhsoQg==?= =?ISO-2022-JP?B?GyRCPzUbKEI=?= =?ISO-2022-JP?B?GyRCPCMbKEI=?='s message of Thu, 09 Nov 1995 01:58:50 +0900 Message-Id: <lv3fbz825r.fsf@clark.pt.hk-r.se> Organization: Flognatronik Lines: 17 / =?ISO-2022-JP?B?GyRCRFhMbhsoQg==?= =?ISO-2022-JP?B?GyRCPzUbKEI=?= =?ISO-2022-JP?B?GyRCPCMbKEI=?= <sinji-t@is.aist-nara.ac.jp> wrote: | | I am in trouble with vat-3.4 on | BSD/OS2.0, | ipmulti-3.5-bsdos2.0.tar.gz, | soundblaster audio board, | | We can't both input and output audio. | | Do you know some patches or drivers? | I don't think soundblaster can sample and play samples at the same time, could this be the problem?? /andy From list-mgr@ISI.EDU Thu Nov 9 10:58:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02253>; Wed, 8 Nov 1995 08:59:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02232>; Wed, 8 Nov 1995 08:58:57 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp) by venera.isi.edu (5.65c/5.61+local-22) id <AA02220>; Wed, 8 Nov 1995 08:58:53 -0800 Received: from alpha211.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id BAA11846; Thu, 9 Nov 1995 01:58:51 +0900 Return-Path: <sinji-t@is.aist-nara.ac.jp> Received: from localhost by alpha211.aist-nara.ac.jp (5.67+1.6W[kuis-17]/2.8Wb/NAIST-1.3[is]) id AA19470; Thu, 9 Nov 95 01:58:50 GMT+0900 Message-Id: <9511081658.AA19470@alpha211.aist-nara.ac.jp> To: mbone Subject: vat problem on BSDI+SOUNDBLASTER X-Mailer: Mew version 1.00.4 on Emacs 18.59.1, Mule 1.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 09 Nov 1995 01:58:50 +0900 From: =?ISO-2022-JP?B?GyRCRFhMbhsoQg==?= =?ISO-2022-JP?B?GyRCPzUbKEI=?= =?ISO-2022-JP?B?GyRCPCMbKEI=?= <sinji-t@is.aist-nara.ac.jp> I am in trouble with vat-3.4 on BSD/OS2.0, ipmulti-3.5-bsdos2.0.tar.gz, soundblaster audio board, We can't both input and output audio. Do you know some patches or drivers? With kind regards. -- Shinji Tsubakino, E-mail: sinji-t@is.aist-nara.ac.jp // Graduate School of Information Science Nara Institute of Science and Technology, Japan // From list-mgr@ISI.EDU Wed Nov 8 03:14:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09929>; Wed, 8 Nov 1995 11:18:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09909>; Wed, 8 Nov 1995 11:18:01 -0800 Received: from mercury.Sun.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA09900>; Wed, 8 Nov 1995 11:17:58 -0800 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id LAA07343; Wed, 8 Nov 1995 11:17:53 -0800 Received: from jurassic.Eng.Sun.COM (camilla.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB13580; Wed, 8 Nov 1995 11:17:49 -0800 Received: from offshore.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id LAA02152; Wed, 8 Nov 1995 11:17:45 -0800 Received: by offshore.Eng.Sun.COM (5.x/SMI-SVR4) id AA06712; Wed, 8 Nov 1995 11:14:18 -0800 Date: Wed, 8 Nov 1995 11:14:18 -0800 From: Allyn.Romanow@Eng.Sun.COM (Allyn Romanow) Message-Id: <9511081914.AA06712@offshore.Eng.Sun.COM> To: mbone Subject: Multicast version 3.5/3.6 available for Solaris 2.4 X-Sun-Charset: US-ASCII The multicast 3.5 kernel and 3.6 mrouted is available via ftp from playground.sun.com:/pub/multicast /README /Solaris_mc35.2.4.tar[.Z] There are installation instructions and an install script included. Unfortunately playground is going to be offline from Nov. 14 - Nov. 20 because we're moving to a new campus. Sorry for the inconvenience. From list-mgr@ISI.EDU Wed Nov 8 03:45:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11767>; Wed, 8 Nov 1995 11:49:01 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11388>; Wed, 8 Nov 1995 11:45:24 -0800 Received: from icsia.ICSI.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA11381>; Wed, 8 Nov 1995 11:45:22 -0800 Received: from icsib8.ICSI.Berkeley.EDU (whd@icsib8.ICSI.Berkeley.EDU [128.32.201.23]) by icsia.ICSI.Berkeley.EDU (8.6.12/HUB+V8$Revision: 1.23 $) with ESMTP id LAA19336 for <mbone@isi.edu>; Wed, 8 Nov 1995 11:45:21 -0800 From: whd@ICSI.Berkeley.EDU (Wieland Holfelder) Received: (whd@localhost) by icsib8.ICSI.Berkeley.EDU (8.6.12/1.8) id LAA09305 for mbone@isi.edu; Wed, 8 Nov 1995 11:45:19 -0800 Message-Id: <199511081945.LAA09305@icsib8.ICSI.Berkeley.EDU> Subject: wb feedback for ACM MM95 To: mbone (Multicast Backbone) Date: Wed, 8 Nov 1995 11:45:18 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 624 Hi: some of you noticed already that we set up a feedback session (wb) for the ACM MM95 on 224.2.232.214/58171 ttl 128 It's also announced in sd. Please feel free to use it and give us feedback! Thanks, -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder International Computer Science Institute Email: whd@icsi.berkeley.edu 1947 Center Street Suite 600 Fax : +1-510-642-6865 Berkeley, CA 94704-1198 Phone: +1-510-642-4274 Ext. 302 URL: http://www.icsi.berkeley.edu/~whd ------------------------------------------------------------------------------- From list-mgr@ISI.EDU Thu Nov 9 14:37:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14978>; Wed, 8 Nov 1995 12:38:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14954>; Wed, 8 Nov 1995 12:37:26 -0800 Received: from mailgate.aist-nara.ac.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA14941>; Wed, 8 Nov 1995 12:37:18 -0800 Received: from alpha211.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id FAA16917; Thu, 9 Nov 1995 05:37:15 +0900 Return-Path: <sinji-t@is.aist-nara.ac.jp> Received: from localhost by alpha211.aist-nara.ac.jp (5.67+1.6W[kuis-17]/2.8Wb/NAIST-1.3[is]) id AA19727; Thu, 9 Nov 95 05:37:14 GMT+0900 Message-Id: <9511082037.AA19727@alpha211.aist-nara.ac.jp> To: cbrown@thor.lostnet.org Cc: mbone Subject: Re: vat problem on BSDI+SOUNDBLASTER In-Reply-To: Your message of "Wed, 8 Nov 1995 19:46:01 +0000 (GMT)" References: <199511081946.TAA00545@thor.lostnet.org> X-Mailer: Mew version 1.00.4 on Emacs 18.59.1, Mule 1.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 09 Nov 1995 05:37:13 +0900 From: =?ISO-2022-JP?B?GyRCRFhMbhsoQg==?= =?ISO-2022-JP?B?GyRCPzUbKEI=?= =?ISO-2022-JP?B?GyRCPCMbKEI=?= <sinji-t@is.aist-nara.ac.jp> > > > > I am in trouble with vat-3.4 on > > BSD/OS2.0, > > ipmulti-3.5-bsdos2.0.tar.gz, > > soundblaster audio board, > > > > We can't both input and output audio. > > > > Do you know some patches or drivers? > > > > If you are trying to input AND output sound at the same time, > don't. The soundblaster card is not full duplex. It cannot > do both at once. If you nee full duplex audio get a PAS 16. > No, not at the same time, I'm trying to input OR output sound. I am simply looking for the drivers which is available for vat. -- Shinji Tsubakino, E-mail: sinji-t@is.aist-nara.ac.jp // Graduate School of Information Science Nara Institute of Science and Technology, Japan // From list-mgr@ISI.EDU Wed Nov 8 04:54:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15779>; Wed, 8 Nov 1995 12:55:29 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15745>; Wed, 8 Nov 1995 12:54:45 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA15737>; Wed, 8 Nov 1995 12:54:40 -0800 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id MAA04349; Wed, 8 Nov 1995 12:54:19 -0800 Message-Id: <199511082054.MAA04349@rah.star-gate.com> To: =?ISO-2022-JP?B?GyRCRFhMbhsoQg==?= =?ISO-2022-JP?B?GyRCPzUbKEI=?= =?ISO-2022-JP?B?GyRCPCMbKEI=?= <sinji-t@is.aist-nara.ac.jp> Cc: mbone Subject: Re: vat problem on BSDI+SOUNDBLASTER In-Reply-To: Your message of "Thu, 09 Nov 1995 05:37:13 +0900." <9511082037.AA19727@alpha211.aist-nara.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <4346.815864057.1@rah.star-gate.com> Date: Wed, 08 Nov 1995 12:54:18 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Look around for the VoxWare sound driver for BSDI also you can check with your BSDI software support. A quick net search with netscape should be able to point you to the nearest ftp site which carries it. Voxware is a sound driver for many popular PC Unix systems. I run FreeBSD ..... Enjoy, Amancio >>> =?ISO-2022-JP?B?GyRCRFhMbhsoQg==?= =?ISO-2022-JP?B?GyRCPzUbKEI=?= =?ISO-202 2-JP?B?GyRCPCMbKEI=?= said: > > > > > > I am in trouble with vat-3.4 on > > > BSD/OS2.0, > > > ipmulti-3.5-bsdos2.0.tar.gz, > > > soundblaster audio board, > > > > > > We can't both input and output audio. > > > > > > Do you know some patches or drivers? > > > > > > > If you are trying to input AND output sound at the same time, > > don't. The soundblaster card is not full duplex. It cannot > > do both at once. If you nee full duplex audio get a PAS 16. > > > > No, not at the same time, I'm trying to input OR output sound. > I am simply looking for the drivers which is available for vat. > > > -- > Shinji Tsubakino, > E-mail: sinji-t@is.aist-nara.ac.jp > // Graduate School of Information Science > Nara Institute of Science and Technology, Japan // > > From list-mgr@ISI.EDU Wed Nov 8 09:27:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00765>; Wed, 8 Nov 1995 17:29:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00712>; Wed, 8 Nov 1995 17:27:52 -0800 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA00704>; Wed, 8 Nov 1995 17:27:48 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id RAA15630; Wed, 8 Nov 1995 17:27:46 -0800 X-Sender: fred@stilton.cisco.com Message-Id: <v02130500acc7019e6995@[171.69.128.114]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Nov 1995 17:27:48 -0800 To: rsvp From: fred@cisco.com (Fred Baker) Subject: RSVP Interim Meeting MBONE broadcast schedule Cc: mbone I have scheduled an MBONE Broadcast of the RSVP Working Group interim meeting November 10 from 9-4 on the MBONE. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell From list-mgr@ISI.EDU Wed Nov 8 09:27:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00765>; Wed, 8 Nov 1995 17:29:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00712>; Wed, 8 Nov 1995 17:27:52 -0800 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA00704>; Wed, 8 Nov 1995 17:27:48 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id RAA15630; Wed, 8 Nov 1995 17:27:46 -0800 X-Sender: fred@stilton.cisco.com Message-Id: <v02130500acc7019e6995@[171.69.128.114]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Nov 1995 17:27:48 -0800 To: rsvp From: fred@cisco.com (Fred Baker) Subject: RSVP Interim Meeting MBONE broadcast schedule Cc: mbone I have scheduled an MBONE Broadcast of the RSVP Working Group interim meeting November 10 from 9-4 on the MBONE. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell From list-mgr@ISI.EDU Fri Nov 10 06:49:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01521>; Fri, 10 Nov 1995 14:52:10 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01478>; Fri, 10 Nov 1995 14:50:36 -0800 Received: from huey.csun.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA01471>; Fri, 10 Nov 1995 14:50:34 -0800 Received: (hbrtv231@localhost) by huey.csun.edu (8.6.12/8.6.4) id OAA10123; Fri, 10 Nov 1995 14:49:42 -0800 Date: Fri, 10 Nov 1995 14:49:41 -0800 (PST) From: lacuion johnson <hbrtv231@huey.csun.edu> To: mbone Subject: mbone files from ftp Message-Id: <Pine.HPP.3.91.951110144607.9582A-100000@huey.csun.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII How do I get the vmtp-ip directory on host gregorio.stanford.edu to read out the file in english so I can print it or download it. every file says <no such file or directory> How do I download if necessary? Having a problem in reading files such as vat.tar.Z, pub/nevot directory <gaia.cs.umass.edu>, and all others. Please help! regards From list-mgr@ISI.EDU Mon Nov 13 10:06:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05705>; Sun, 12 Nov 1995 08:07:08 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05697>; Sun, 12 Nov 1995 08:06:29 -0800 Received: from mailgate.aist-nara.ac.jp ([163.221.76.12]) by venera.isi.edu (5.65c/5.61+local-22) id <AA05689>; Sun, 12 Nov 1995 08:06:26 -0800 Received: from alpha211.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id BAA29968; Mon, 13 Nov 1995 01:06:15 +0900 Return-Path: <sinji-t@is.aist-nara.ac.jp> Received: from localhost by alpha211.aist-nara.ac.jp (5.67+1.6W[kuis-17]/2.8Wb/NAIST-1.3[is]) id AA21735; Mon, 13 Nov 95 01:06:14 GMT+0900 Message-Id: <9511121606.AA21735@alpha211.aist-nara.ac.jp> To: mbone, rem-conf@es.net Cc: Apec-PT@pingu.kiis.or.jp, tuneki-k@is.aist-nara.ac.jp, taira@ics.es.osaka-u.ac.jp Subject: Re: Session announce ``ASIA PACIFIC MUSIC FESTIVAL'' In-Reply-To: Your message of "Fri, 20 Oct 1995 12:26:52 +0900" References: <9510200326.AA06098@dec300.aist-nara.ac.jp> X-Mailer: Mew version 1.00.4 on Emacs 18.59.1, Mule 1.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Date: Mon, 13 Nov 1995 01:06:14 +0900 From: =?ISO-2022-JP?B?GyRCRFhMbhsoQg==?= =?ISO-2022-JP?B?GyRCPzUbKEI=?= =?ISO-2022-JP?B?GyRCPCMbKEI=?= <sinji-t@is.aist-nara.ac.jp> We'll present this event to you as following. Session (with TTL=127) Video (nv,128kbps) from Asia Trading Center at Osaka, Japan Audio (dvi4,32kbps) Time-Table Live - "Asia Pacific Music Festival" from Nov. 14 18:30 JST (Nov. 14 9:30 UTC) > Hi MBoner, > welcome to Osaka, Japan, Asia. > > We are preparing to broadcast the following event, being held on > November 14, 9:30 UCT. I'll announce about mbone session in detail > later. > > > ====================================================== It's so nice!! > ASIA PACIFIC MUSIC FESTIVAL > Presented by PANASONIC > > Don't miss this rare opportunity to see Asia's hottest international > stars in one show! Scheduled to take place just before the Osaka APEC > meeting, the Asia Pacific Music Festival,bringing together performers > of several nationalities, will demonstrate the borderless nature of > music. Now, if you can't make it to the concert hall of Osaka's Asia > Pacific Trade Center on November 14, you can still catch the event's > live broadcast on the Internet!! So remember to plug in on November > 14, 18:30 (Japan time) for this extraordinary event. > (http://www.apec.or.jp/ck/event/event.html) > > > PERFORMERS LIST > > Dick Lee - Singapore > > L$B"+"*(BR - Japan > > Tracy Huang - Taiwan > > Shirly Kwan - Hong Kong > > Tamura Naomi - Japan > ===================================================================== > > -- Shinji Tsubakino, E-mail: sinji-t@is.aist-nara.ac.jp // Graduate School of Information Science Nara Institute of Science and Technology, Japan // APEC(Asia Pacific Economic Cooperation)'95 Osaka Internet NOC. From list-mgr@ISI.EDU Sun Nov 12 14:09:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16678>; Sun, 12 Nov 1995 16:12:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16621>; Sun, 12 Nov 1995 16:08:17 -0800 Received: from dns1.uga.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA16614>; Sun, 12 Nov 1995 16:08:16 -0800 Received: from moe.coe.uga.edu (moe.coe.uga.edu [128.192.22.3]) by dns1.uga.edu (8.7.1/8.7.1) with ESMTP id TAA13748 for <mbone@isi.edu>; Sun, 12 Nov 1995 19:08:14 -0500 Received: from [192.0.2.1] (moe.coe.uga.edu [128.192.22.3]) by moe.coe.uga.edu (8.6.10/8.6.10) with SMTP id TAA01439 for <mbone@isi.edu>; Sun, 12 Nov 1995 19:07:03 -0500 X-Sender: camselle@moe.coe.uga.edu Message-Id: <v01530503accc3a7dd275@[192.0.2.1]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Nov 1995 19:09:35 -0500 To: mbone From: camselle@coe.uga.edu (Chris Amsellem) Subject: Instructional design using MBone My name is Chris Amsellem. I'm a Master's student of Instructional Technology at the University of Georgia. My current project is to discuss the real-time audio and/or video communications technologies currently available (and the near future) and their applicable attributes toward distance education. In particular, I will focus on the technologies being used for audio and video conferencing on the Internet and their potential uses within a virtual music classroom. I was wondering if someone there could answer a couple of questions about MBone and its current, past, or future uses in distance education. I want to know if there are (were, will be, etc. . .) regular classes held using MBone (by "regular" I mean the participants meet at predesignated times at regular intervals). If the cost is too high for such a project, how can the costs be lowered, and at what point do the costs become managable? What are the current costs per site in both man hours used and time lost to other users? If someone could please take the time to answer these questions and maybe refer me to other sources I would really appreciate it. Thank you in advance. Sincerely, Chris Amsellem From list-mgr@ISI.EDU Mon Nov 13 06:01:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07649>; Mon, 13 Nov 1995 08:04:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07449>; Mon, 13 Nov 1995 08:01:20 -0800 Received: from trystero.radio.com by venera.isi.edu (5.65c/5.61+local-22) id <AA07442>; Mon, 13 Nov 1995 08:01:17 -0800 Received: (carl@localhost) by trystero.radio.com (8.7.1/940816.06ccg) id LAA24658 for mbone@isi.edu; Mon, 13 Nov 1995 11:01:15 -0500 (EST) From: "Carl Malamud [IMS]" <carl@radio.com> Message-Id: <199511131601.LAA24658@trystero.radio.com> Subject: Multicast FTP To: mbone Date: Mon, 13 Nov 1995 11:01:15 -0500 (EST) Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Does anybody have any experience with a product from Starburst Communications which does multicast-based FTP? Private responses would be appreciated ... I'll summarize to the list if there are interesting experiences. Carl From list-mgr@ISI.EDU Mon Nov 13 07:09:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10813>; Mon, 13 Nov 1995 09:13:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10668>; Mon, 13 Nov 1995 09:10:38 -0800 Received: from UTKUX4.UTCC.UTK.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA10661>; Mon, 13 Nov 1995 09:10:30 -0800 Received: by utkux4.utcc.utk.edu (5.x/2.7c-UTK) id AA11570; Mon, 13 Nov 1995 12:09:37 -0500 Date: Mon, 13 Nov 1995 12:09:32 -0500 (EST) From: Nair Venugopal <venu@utkux.utcc.utk.edu> X-Sender: venu@utkux4.utcc.utk.edu To: mbone Subject: nv3.3beta with SunVideo/Solaris2.4 Message-Id: <Pine.SOL.3.91.951113120126.9601Q-100000@utkux4.utcc.utk.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I still have to select greyscale and then switch back to color to get NV native encoding to work with nv3.3 beta and Solaris2.4. Ron, is the fix you mentioned a part of the nv3.3 distribution now? Thanks --venu >From: Ron Frederick <frederic@parc.xerox.com> > >> A side effect is that NV native encoding doesn't work - all I >> get is a black picture (sometimes a few scan lines of static on top). >> When I switch to CellB encoding, no problem. I tried to rebuild >> NV in case it's just some call/structure change and am missing xil.h. >> >Yes - there have been incompatible changes to XIL between 2.3 FCS and a later >2.3/early 2.4 release, and that's why you are seeing problems with nv. I now >have a new SunVideo grab routine which should work around the problem, but I >haven't had a chance to fully test it & package it up yet. It should be >available soon. > >In the meantime, I believe that sending greyscale works around the problem. >I've also heard it rumored that switching to greyscale and then back to color >works, but I don't know for sure whether that's the case. -------------------------------------------------------------------------------- Nair Venugopal(Venu) Network Services Email: venu@utkux.utcc.utk.edu 2339 Dunford Hall, Knoxville TN-37996 Phone: (423) 974 6616 University of Tennessee, Knoxville From list-mgr@ISI.EDU Mon Nov 13 21:02:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16783>; Mon, 13 Nov 1995 11:04:15 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16735>; Mon, 13 Nov 1995 11:03:11 -0800 Received: from pat.uio.no by venera.isi.edu (5.65c/5.61+local-22) id <AA16728>; Mon, 13 Nov 1995 11:03:05 -0800 Received: from ulrik.uio.no by pat.uio.no with local-SMTP (PP) id <14868-0@pat.uio.no>; Mon, 13 Nov 1995 20:02:49 +0100 Received: from monet by monet.uio.no ; Mon, 13 Nov 1995 19:02:48 GMT Message-Id: <199511131902.TAA29540@monet.uio.no> X-Mailer: exmh version 1.6.2 7/18/95 To: mbone Subject: imm for linux Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Nov 1995 20:02:47 +0100 From: Gorm Haug Eriksen <g.h.eriksen@usit.uio.no> Hi, Someone ported, or know of a port, of imm -> linux? Thanks, - Gorm From list-mgr@ISI.EDU Mon Nov 13 04:26:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21233>; Mon, 13 Nov 1995 12:29:14 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA21223>; Mon, 13 Nov 1995 12:29:13 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16932(2)>; Mon, 13 Nov 1995 12:26:36 PST Received: by crevenia.parc.xerox.com id <177478>; Mon, 13 Nov 1995 12:26:15 -0800 From: Bill Fenner <fenner@parc.xerox.com> To: mbone-na, sob@owlman.academ.com Subject: Rice: Baker Institute Symposium video hosing the MBONE Cc: fenner@parc.xerox.com Message-Id: <95Nov13.122615pst.177478@crevenia.parc.xerox.com> Date: Mon, 13 Nov 1995 12:26:01 PST The video stream from the 'Rice: Baker Institute Symposium' session appears to be being transmitted at approximately 500kbps. The whole MBONE has approximately 500kbps of bandwidth to be shared between all users; it is extremely anti-social for a scheduled event to transmit at such a high rate. Please reduce your video bandwidth to the default of 128kbps; that is an appropriate value for sharing the resources of the MBONE. Bill From list-mgr@ISI.EDU Mon Nov 13 08:43:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22043>; Mon, 13 Nov 1995 12:43:42 -0800 Received: from ACADEM.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA22036>; Mon, 13 Nov 1995 12:43:39 -0800 Received: (from sob@localhost) by academ.com (8.7.1/8.7.1) id OAA23385; Mon, 13 Nov 1995 14:43:29 -0600 (CST) Message-Id: <199511132043.OAA23385@academ.com> From: sob@academ.com (Stan Barber) Date: Mon, 13 Nov 1995 14:43:29 CST X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Bill Fenner <fenner@parc.xerox.com>, mbone-na, sob@owlman.academ.com Subject: Re: Rice: Baker Institute Symposium video hosing the MBONE Bill, Your public request (which could have been made privately to the same result) is my command. Have a nice day. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From list-mgr@ISI.EDU Mon Nov 13 05:51:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26113>; Mon, 13 Nov 1995 13:57:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26083>; Mon, 13 Nov 1995 13:56:37 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA26076>; Mon, 13 Nov 1995 13:56:35 -0800 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <16741(8)>; Mon, 13 Nov 1995 13:51:54 PST Received: from localhost ([127.0.0.1]) by ecco.parc.xerox.com with SMTP id <16136>; Mon, 13 Nov 1995 13:51:42 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: Nair Venugopal <venu@utkux.utcc.utk.edu> Cc: mbone Subject: Re: nv3.3beta with SunVideo/Solaris2.4 In-Reply-To: Your message of "Mon, 13 Nov 1995 09:09:32 PST." <Pine.SOL.3.91.951113120126.9601Q-100000@utkux4.utcc.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Nov 1995 13:51:35 PST From: Ron Frederick <frederic@parc.xerox.com> Message-Id: <95Nov13.135142pst.16136@ecco.parc.xerox.com> In message <Pine.SOL.3.91.951113120126.9601Q-100000@utkux4.utcc.utk.edu>you wri te: > I still have to select greyscale and then switch back to color to get NV > native encoding to work with nv3.3 beta and Solaris2.4. Ron, is the fix > you mentioned a part of the nv3.3 distribution now? > No - I haven't updated the stuff on the FTP site yet. The version that's there is still the one for Solaris 2.3. However, a binary with the change is out in: ftp://ftp.parc.xerox.com/transient/frederick/nv-3.3beta-sunos5.4 -- Ron Frederick frederick@parc.xerox.com From list-mgr@ISI.EDU Mon Nov 13 14:47:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18286>; Mon, 13 Nov 1995 22:57:16 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18045>; Mon, 13 Nov 1995 22:47:12 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA18038>; Mon, 13 Nov 1995 22:47:10 -0800 Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id WAA00518 for <mbone@isi.edu>; Mon, 13 Nov 1995 22:47:06 -0800 Message-Id: <199511140647.WAA00518@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: mbone Subject: tunnel request for aimnet.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Nov 1995 22:47:05 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> I am posting this on Aimnet.com behalf... Can anyone provide a tunnel for Aimnet.com (204.247.21.21) ? If so please contact me, hasty@star-gate.com Geographically we are located in Cupertino, California. Tnks! ---- Amancio Hasty Hasty Software Consulting Services Tel: 415-495-3046 Fax: 415-495-3046 Cellular: 415-309-8434 e-mail: hasty@star-gate.com Powered by FreeBSD From list-mgr@ISI.EDU Tue Nov 14 01:49:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24501>; Tue, 14 Nov 1995 03:54:49 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24452>; Tue, 14 Nov 1995 03:49:52 -0800 Received: from foghorn.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA24445>; Tue, 14 Nov 1995 03:49:49 -0800 Received: from localhost (young@localhost) by foghorn.reston.mci.net (8.6.12/8.6.9) with SMTP id GAA00531; Tue, 14 Nov 1995 06:49:13 -0500 Message-Id: <199511141149.GAA00531@foghorn.reston.mci.net> X-Authentication-Warning: foghorn.reston.mci.net: young owned process doing -bs X-Authentication-Warning: foghorn.reston.mci.net: Host localhost didn't use HELO protocol To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: mbone Subject: Re: tunnel request for aimnet.com In-Reply-To: Your message of "Mon, 13 Nov 1995 22:47:05 PST." <199511140647.WAA00518@rah.star-gate.com> Date: Tue, 14 Nov 1995 06:49:12 -0500 From: "Jeff Young" <young@mci.net> looks like aimnet is an mci customer, we'd be happy to provide the feed. Jeff Young young@mci.net mbone@mci.net > To: mbone@ISI.EDU > Subject: tunnel request for aimnet.com > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Date: Mon, 13 Nov 1995 22:47:05 -0800 > From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> > > > I am posting this on Aimnet.com behalf... > > Can anyone provide a tunnel for Aimnet.com (204.247.21.21) ? > If so please contact me, hasty@star-gate.com > > Geographically we are located in Cupertino, California. > > > Tnks! > ---- > Amancio Hasty > Hasty Software Consulting Services > Tel: 415-495-3046 > Fax: 415-495-3046 > Cellular: 415-309-8434 > e-mail: hasty@star-gate.com Powered by FreeBSD > From list-mgr@ISI.EDU Tue Nov 14 16:02:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26482>; Tue, 14 Nov 1995 06:06:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26441>; Tue, 14 Nov 1995 06:03:34 -0800 Received: from nez-perce.inria.fr by venera.isi.edu (5.65c/5.61+local-22) id <AA26434>; Tue, 14 Nov 1995 06:03:30 -0800 Received: from electre.inria.fr (electre.inria.fr [128.93.2.11]) by nez-perce.inria.fr (8.7.1/8.6.9) with SMTP id PAA12211; Tue, 14 Nov 1995 15:02:34 +0100 (MET) Received: by electre.inria.fr; Tue, 14 Nov 1995 15:02:33 +0100 From: Christian DONOT <Christian.Donot@inria.fr> Message-Id: <199511141402.AA24154@electre.inria.fr> Subject: Status of mae-bone.psi.net on MBone To: fedor@noc.psi.net Date: Tue, 14 Nov 1995 15:02:33 +0100 (MET) Cc: mbone X-Mailer: ELM [version 2.4 PL22] Content-Type: text Dear Mark, Which is the status of mae-bone.psi.net on the MBone ? I thought this station had a tunnel with fmroute1-1.exp.edf.fr as you can show from a mrinfo extract : 192.70.92.133 -> 192.41.177.247 (mae-bone.psi.net) [2/64/tunnel] Some others mrouters have a tunnel with mae-mbone.psi.net : VINEGAR.SESQUI.NET stockholm.mbone.ebone.net MBONE1.UU.NET wtn-ms1.sura.net stockholm.mbone.ebone.net mae-mbone.psi.net don't answer at the mrinfo and ping. Best regards. Christian -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Christian Donot Direction of Research Promotion and its Transfer =+=+=+=+=+=+=+= * INRIA's Activities Demonstrations Manager (DPRT) * French Multicast Bone Co-ordinator (mbone-fr@inria.fr) (ARISTOTE) To get "mbone-fr" map : ftp anonymous from electre.inria.fr:pub/mbone ftp anonymous from ftp.inria.fr:network/mbone/map * To get "ivs" : (INRIA) ftp anonymous from zenon.inria.fr:rodeo/ivs/last_version http://www.inria.fr/rodeo/ivs.html * To get "telesia" : (Aristote) ftp anonymous from electre.inria.fr:pub/videoconf/last_version =+=+=+=+=+=+=+= Tel : +33 1 39 63 57 75 | INRIA/DPRT/ARISTOTE Fax : +33 1 39 63 55 34/53 30 | BP 105 Email : Christian.Donot@inria.fr | 78153 LE CHESNAY CEDEX : chd@inria.fr | FRANCE =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= From list-mgr@ISI.EDU Tue Nov 14 04:29:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27789>; Tue, 14 Nov 1995 06:36:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27755>; Tue, 14 Nov 1995 06:34:59 -0800 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA27748>; Tue, 14 Nov 1995 06:34:57 -0800 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA16522; Tue, 14 Nov 1995 09:29:54 +0500 Message-Id: <9511141429.AA16522@msf.psi.net.> To: Christian DONOT <Christian.Donot@inria.fr> Cc: fedor@noc.psi.net, mbone Subject: Re: Status of mae-bone.psi.net on MBone In-Reply-To: Your message of "Tue, 14 Nov 1995 15:02:33 +0100." <199511141402.AA24154@electre.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <16520.816359393.1@msf.psi.net> Date: Tue, 14 Nov 1995 09:29:54 -0500 From: "Mark S. Fedor" <fedor@msf.psi.net> Content-Length: 2676 mae-bone.psi.net looks fine. Here is an mrinfo (note the first 4 listed are native multicast speakers on mae-east): mae-bone.psi.net# mrinfo 192.41.177.247 192.41.177.247 (192.41.177.247) [version 3.6]: 192.41.177.247 -> 192.41.177.25 (192.41.177.25) [1/64] 192.41.177.247 -> 192.41.177.115 (mae-east.digex.net) [1/64] 192.41.177.247 -> 192.41.177.197 (wtn-ms1.sura.net) [1/64] 192.41.177.247 -> 192.41.177.199 (wtn-mp1-mae-east-pe.sura.net) [1/64] 192.41.177.247 -> 149.127.6.110 (skunkworks.psi.com) [1/10/tunnel] 192.41.177.247 -> 38.145.250.3 (rambone.psi.net) [1/10/tunnel] 192.41.177.247 -> 192.36.148.206 (192.36.148.206) [1/64/tunnel] 192.41.177.247 -> 128.241.0.91 (VINEGAR.SESQUI.NET) [1/64/tunnel] 192.41.177.247 -> 204.70.74.61 (dec3800-2-fddi-0.Washington.mci.net) [1/64/tunnel] 192.41.177.247 -> 192.70.92.133 (fmroute1-1.exp.edf.fr) [1/64/tunnel] 192.41.177.247 -> 137.39.43.34 (MBONE1.UU.NET) [1/64/tunnel] mae-bone does not have a full routing table. It has no default route. It only has routes for the machines it has tunnels with. Routing tables are all hand crafted and static. mae-bone does support mtrace. mf ----------------------------- > Dear Mark, > > Which is the status of mae-bone.psi.net on the MBone ? > I thought this station had a tunnel with fmroute1-1.exp.edf.fr as you > can show from a mrinfo extract : > > 192.70.92.133 -> 192.41.177.247 (mae-bone.psi.net) [2/64/tunnel] > > Some others mrouters have a tunnel with mae-mbone.psi.net : > > VINEGAR.SESQUI.NET > stockholm.mbone.ebone.net > MBONE1.UU.NET > wtn-ms1.sura.net > stockholm.mbone.ebone.net > > mae-mbone.psi.net don't answer at the mrinfo and ping. > > Best regards. > > Christian > > > -- > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= > Christian Donot > Direction of Research Promotion and its Transfer > =+=+=+=+=+=+=+= > * INRIA's Activities Demonstrations Manager (DPRT) > * French Multicast Bone Co-ordinator (mbone-fr@inria.fr) (ARISTOTE) > To get "mbone-fr" map : > ftp anonymous from electre.inria.fr:pub/mbone > ftp anonymous from ftp.inria.fr:network/mbone/map > * To get "ivs" : (INRIA) > ftp anonymous from zenon.inria.fr:rodeo/ivs/last_version > http://www.inria.fr/rodeo/ivs.html > * To get "telesia" : (Aristote) > ftp anonymous from electre.inria.fr:pub/videoconf/last_version > =+=+=+=+=+=+=+= > Tel : +33 1 39 63 57 75 | INRIA/DPRT/ARISTOTE > Fax : +33 1 39 63 55 34/53 30 | BP 105 > Email : Christian.Donot@inria.fr | 78153 LE CHESNAY CEDEX > : chd@inria.fr | FRANCE > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= From list-mgr@ISI.EDU Tue Nov 14 14:59:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29168>; Tue, 14 Nov 1995 07:16:16 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29093>; Tue, 14 Nov 1995 07:14:51 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AB29086>; Tue, 14 Nov 1995 07:14:49 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA01240>; Tue, 14 Nov 1995 07:14:48 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.21767-0@bells.cs.ucl.ac.uk>; Tue, 14 Nov 1995 14:59:44 +0000 From: Mark Handley <M.Handley@cs.ucl.ac.uk> X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Christian DONOT <Christian.Donot@inria.fr> Cc: fedor@noc.psi.net, mbone Subject: Re: Status of mae-bone.psi.net on MBone In-Reply-To: Your message of "Tue, 14 Nov 95 15:02:33 +0100." <199511141402.AA24154@electre.inria.fr> Date: Tue, 14 Nov 95 14:59:43 +0000 Message-Id: <9165.816361183@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >Which is the status of mae-bone.psi.net on the MBone ? >I thought this station had a tunnel with fmroute1-1.exp.edf.fr as you >can show from a mrinfo extract : > >192.70.92.133 -> 192.41.177.247 (mae-bone.psi.net) [2/64/tunnel] > >Some others mrouters have a tunnel with mae-mbone.psi.net : > >VINEGAR.SESQUI.NET >stockholm.mbone.ebone.net >MBONE1.UU.NET >wtn-ms1.sura.net >stockholm.mbone.ebone.net > >mae-mbone.psi.net don't answer at the mrinfo and ping. I believe mae-bone has no routes other than to the other ends of its tunnels. You should be able to mtrace through it, and mrinfo/ping it from fmroute1-1.exp.edf.fr. Mark From list-mgr@ISI.EDU Tue Nov 14 17:48:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01416>; Tue, 14 Nov 1995 08:08:17 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01148>; Tue, 14 Nov 1995 08:05:19 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA01141>; Tue, 14 Nov 1995 08:05:18 -0800 Received: from nez-perce.inria.fr by quark.isi.edu (5.65c/5.61+local-20) id <AA01489>; Tue, 14 Nov 1995 07:57:38 -0800 Received: from electre.inria.fr (electre.inria.fr [128.93.2.11]) by nez-perce.inria.fr (8.7.1/8.6.9) with SMTP id QAA13180; Tue, 14 Nov 1995 16:48:24 +0100 (MET) Received: by electre.inria.fr; Tue, 14 Nov 1995 16:48:23 +0100 From: Christian DONOT <Christian.Donot@inria.fr> Message-Id: <199511141548.AA24408@electre.inria.fr> Subject: Re: Status of mae-bone.psi.net on MBone To: fedor@msf.psi.net (Mark S. Fedor) Date: Tue, 14 Nov 1995 16:48:23 +0100 (MET) Cc: mbone In-Reply-To: <9511141429.AA16522@msf.psi.net.> from "Mark S. Fedor" at Nov 14, 95 09:29:54 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Quoting > Mark S. Fedor wrote, > > mae-bone.psi.net looks fine. Here is an mrinfo (note the first 4 listed > are native multicast speakers on mae-east): > > mae-bone.psi.net# mrinfo 192.41.177.247 > 192.41.177.247 (192.41.177.247) [version 3.6]: > 192.41.177.247 -> 192.41.177.25 (192.41.177.25) [1/64] > 192.41.177.247 -> 192.41.177.115 (mae-east.digex.net) [1/64] > 192.41.177.247 -> 192.41.177.197 (wtn-ms1.sura.net) [1/64] > 192.41.177.247 -> 192.41.177.199 (wtn-mp1-mae-east-pe.sura.net) [1/64] > 192.41.177.247 -> 149.127.6.110 (skunkworks.psi.com) [1/10/tunnel] > 192.41.177.247 -> 38.145.250.3 (rambone.psi.net) [1/10/tunnel] > 192.41.177.247 -> 192.36.148.206 (192.36.148.206) [1/64/tunnel] > 192.41.177.247 -> 128.241.0.91 (VINEGAR.SESQUI.NET) [1/64/tunnel] > 192.41.177.247 -> 204.70.74.61 (dec3800-2-fddi-0.Washington.mci.net) [1/64/tunnel] > 192.41.177.247 -> 192.70.92.133 (fmroute1-1.exp.edf.fr) [1/64/tunnel] > 192.41.177.247 -> 137.39.43.34 (MBONE1.UU.NET) [1/64/tunnel] > > mae-bone does not have a full routing table. It has no default route. It > only has routes for the machines it has tunnels with. Routing tables are > all hand crafted and static. > mra='mr -S mwatch.cl.cam.ac.uk:mwatch.cs.ucl.ac.uk:mwatch.cmf.nrl.navy.mil' mra is an alias. At 16:15 (In France) : mra -s fmroute1-1.exp.edf.fr -d mae-east.digex.net fmroute1-1.exp.edf.fr -> 171.69.4.139 [1/1][1/1] 171.69.4.139 -> sj-eng-corp2.cisco.com [1/0][2/1] sj-eng-corp2.cisco.com -> sj-wall-2.cisco.com [1/0][3/3] sj-wall-2.cisco.com -> barrnet-gw.cisco.com [1/32][4/35] barrnet-gw.cisco.com -> su-tk.wr.bbnplanet.net [1/0][5/35] su-tk.wr.bbnplanet.net -> morgul.barrnet.net [1/0][6/35] morgul.barrnet.net -> mbone.nsi.nasa.gov [1/64][7/70] mbone.nsi.nasa.gov -> oday.psc.edu [1/64][8/71] oday.psc.edu -> mbone1.ner.bbnplanet.net [1/64][9/72] mbone1.ner.bbnplanet.net -> MBONE3.UU.NET [1/32][10/72] MBONE3.UU.NET -> MBONE1.UU.NET [1/64][11/74] MBONE1.UU.NET -> mbone.sura.net [1/32][12/74] mbone.sura.net -> cpk-ms1.sura.net [1/32][13/74] cpk-ms1.sura.net -> wtn-ms1.sura.net [1/32][14/74] wtn-ms1.sura.net -> mae-east.digex.net [1/32][15/74] fmroute1-1.exp.edf.fr don't have any tunnel with 171.69.4.139 !! mrinfo 171.69.4.139 171.69.4.139 (sj-eng-f2.cisco.com) [version 10.3]: 171.69.48.2 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] 171.69.48.66 -> 0.0.0.0 (local) [1/0/pim/querier/disabled/down/leaf] 171.69.52.2 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] 171.69.52.66 -> 0.0.0.0 (local) [1/0/pim/querier/disabled/down/leaf] 171.69.56.130 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] 171.69.56.2 -> 171.69.56.3 (pride.cisco.com) [1/0/pim] 171.69.56.66 -> 171.69.56.67 (pride.cisco.com) [1/0/pim] 0.0.0.0 -> 0.0.0.0 (local) [1/0/pim/disabled/down/leaf] 171.69.56.194 -> 171.69.56.196 (pride.cisco.com) [1/0/pim] 171.69.60.2 -> 171.69.60.3 (pride.cisco.com) [1/0/pim] 171.69.60.130 -> 171.69.60.131 (pride.cisco.com) [1/0/pim] 171.69.60.194 -> 171.69.60.196 (pride.cisco.com) [1/0/pim] 171.69.4.139 -> 171.69.4.151 (sj-eng-woof1.cisco.com) [1/0/pim] 171.69.4.139 -> 171.69.4.136 (sj-eng-e1.cisco.com) [1/0/pim] 171.69.4.139 -> 171.69.4.143 (sj-eng-corp2.cisco.com) [1/0/pim] 171.69.4.139 -> 171.69.4.128 (eng-atm-gw.cisco.com) [1/0/pim] 171.69.4.139 -> 171.69.4.156 (sj-eng-f6.cisco.com) [1/0/pim] 171.69.4.139 -> 171.69.4.130 (sj-eng-b1.cisco.com) [1/0/pim] 171.69.4.139 -> 171.69.4.37 (zeus-gw.cisco.com) [1/0/pim] 171.69.4.139 -> 171.69.4.141 (sj-eng-cc3.cisco.com) [1/0/pim] 171.69.4.139 -> 171.69.4.32 (sj-eng-gnm1.cisco.com) [1/0/pim] 171.69.4.139 -> 171.69.4.133 (sj-ecs-lab2.cisco.com) [1/0/pim] 171.69.4.139 -> 171.69.4.135 (sj-eng-cc2.cisco.com) [1/0/pim] 171.69.4.139 -> 171.69.4.154 (sj-eng-f4.cisco.com) [1/0/pim] At 16:30 (In France). mra -s fmroute1-1.exp.edf.fr -d mae-east.digex.net fmroute1-1.exp.edf.fr -> oreste.inria.fr [1/32][1/32] oreste.inria.fr -> sobone.inria.fr [4/32][5/33] sobone.inria.fr -> MBONE.CIT.CORNELL.EDU [7/32][12/34] MBONE.CIT.CORNELL.EDU -> RASTRO.MIT.EDU [7/64][19/67] RASTRO.MIT.EDU -> mbone1.ner.bbnplanet.net [1/32][20/67] mbone1.ner.bbnplanet.net -> MBONE3.UU.NET [1/32][21/67] MBONE3.UU.NET -> MBONE1.UU.NET [1/64][22/70] MBONE1.UU.NET -> mbone.sura.net [1/32][23/70] mbone.sura.net -> cpk-ms1.sura.net [1/32][24/70] cpk-ms1.sura.net -> wtn-ms1.sura.net [1/32][25/70] wtn-ms1.sura.net -> mae-east.digex.net [1/32][26/70] mae-east.digex.net -> atlas.digex.net [1/0][27/70] mra -s mae-east.digex.net -d fmroute1-1.exp.edf.fr no route available mra -s mae-bone.psi.net -d fmroute1-1.exp.edf.fr no route available Christian From list-mgr@ISI.EDU Tue Nov 14 06:55:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03617>; Tue, 14 Nov 1995 08:55:18 -0800 Received: from relay.hp.com by venera.isi.edu (5.65c/5.61+local-22) id <AA03610>; Tue, 14 Nov 1995 08:55:16 -0800 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA178868111; Tue, 14 Nov 1995 08:55:12 -0800 Message-Id: <199511141655.AA178868111@relay.hp.com> Received: from dcetv.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA262138111; Tue, 14 Nov 1995 11:55:11 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: mbone-na Subject: MBONE troubles ?? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Nov 1995 11:55:11 -0500 From: John Brezak <brezak@apollo.hp.com> We seem to be getting very sporadic connectivity to the MBONE. This is as far as I can see - 15.255.176.33 (matmos.hpl.hp.com): <v3.2> 131.119.244.11 (utumno.barrnet.net) [2/64/tunnel] 15.255.176.33 (matmos.hpl.hp.com) [1/1/querier] Can someone trace this from outside of our firewall ?? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak Internet: brezak@ch.hp.com Hewlett Packard/Apollo Phone: (508) 436-4915 300 Apollo Drive Fax: (508) 436-5140 Chelmsford, Massachusetts, USA From list-mgr@ISI.EDU Tue Nov 14 01:16:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04949>; Tue, 14 Nov 1995 09:18:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04784>; Tue, 14 Nov 1995 09:17:29 -0800 Received: from huey.csun.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA04777>; Tue, 14 Nov 1995 09:17:27 -0800 Received: (hbrtv231@localhost) by huey.csun.edu (8.6.12/8.6.4) id JAA16021; Tue, 14 Nov 1995 09:16:10 -0800 Date: Tue, 14 Nov 1995 09:16:09 -0800 (PST) From: lacuion johnson <hbrtv231@huey.csun.edu> To: mbone Subject: How do I read this stuff?? Message-Id: <Pine.HPP.3.91.951114091159.15005A-100000@huey.csun.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I downloaded mrouted3.6-sparc-sunos41x.tar.gz. Can you help me view this? Do I need to use tar? Is there another utility? I am trying to get into vmtp-ip directory to get IP multicast software and mrouted program locations. Help! regards From list-mgr@ISI.EDU Tue Nov 14 02:44:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10350>; Tue, 14 Nov 1995 10:45:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10307>; Tue, 14 Nov 1995 10:44:47 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA10300>; Tue, 14 Nov 1995 10:44:45 -0800 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id KAA08530; Tue, 14 Nov 1995 10:44:28 -0800 Message-Id: <199511141844.KAA08530@rx7.ee.lbl.gov> To: Christian DONOT <Christian.Donot@inria.fr> Cc: fedor@msf.psi.net (Mark S. Fedor), mbone Subject: Re: Status of mae-bone.psi.net on MBone In-Reply-To: Your message of Tue, 14 Nov 95 16:48:23 N. Date: Tue, 14 Nov 95 10:44:28 PST From: Van Jacobson <van@ee.lbl.gov> > mra='mr -S mwatch.cl.cam.ac.uk:mwatch.cs.ucl.ac.uk:mwatch.cmf.nrl.navy.mil' > mra is an alias. > > At 16:15 (In France) : > mra -s fmroute1-1.exp.edf.fr -d mae-east.digex.net Christian, You should have interpreted the "mae-bone has no default route" comments from Mark F. & Mark H. as "mwatch will lie to you about routes through mae-east". Let me make it a bit more definite: Mwatch almost always lies to you. You *cannot* determine multicast routes using mwatch. The *only* reliable way to determine multicast routes is with mtrace. I'm not putting down mwatch -- it was a very useful tool and an essential part of getting the mbone to where it is today. But the world has changed -- there are a lot more mrouters on access controlled backbones & behind firewalls that mwatch can't query. Mwatch assumes routers it can't talk to doesn't exist and it leaves them out of its routing calculations. This means it omits major backbone routes (like mae-east) and entire organizations (like Xerox, Sun & HP). Mtrace was designed to work in today's mbone & works through firewalls and to routers with limitted unicast routing. You should use it. If you find it doesn't work because sites are running ciscos or ancient mrouted's that don't support mtrace, you should complain loudly until people fix these broken sites. But you won't have any luck reporting "problems" based on the lies that mwatch tells you. - Van From list-mgr@ISI.EDU Tue Nov 14 11:15:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12325>; Tue, 14 Nov 1995 11:21:26 -0800 Received: from cythera.unb.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA12314>; Tue, 14 Nov 1995 11:21:24 -0800 Received: from cythera.unb.ca (cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.6.12/8.6.5) with SMTP id PAA19651 for <mbone-na@isi.edu>; Tue, 14 Nov 1995 15:17:49 -0400 Date: Tue, 14 Nov 1995 15:15:37 -0400 (AST) From: "Dwight E. Spencer" <spencer@unb.ca> To: likavec@pc226.igd.fhg.de Cc: likavec@igd.fhg.de Subject: Your mic is on Message-Id: <Pine.SOL.3.91.951114151442.18553E-100000@cythera.unb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Date: Tue, 14 Nov 1995 15:17:42 -0400 (AST) Resent-From: "Dwight E. Spencer" <spencer@unb.ca> Resent-To: mbone-na Resent-Message-Id: <Pine.SOL.3.91.951114151742.18553G@cythera.unb.ca> Could you please mute your microphone on your MBONE Shuttle Mission session. dwight ---------------------------------------------------------------------------- Dwight E. Spencer Canada's Community Access Network eMail: spencer@unb.ca, Server Administrator UNB, Fredericton, NB, Canada Phone: +1 506 447 3153 Url: http://cnet.unb.ca/cspace/staff/dspencer/ From list-mgr@ISI.EDU Tue Nov 14 04:51:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18307>; Tue, 14 Nov 1995 13:00:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17774>; Tue, 14 Nov 1995 12:53:41 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA17765>; Tue, 14 Nov 1995 12:53:39 -0800 Received: from alpha.Xerox.COM by quark.isi.edu (5.65c/5.61+local-20) id <AA07987>; Tue, 14 Nov 1995 12:53:39 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15310(3)>; Tue, 14 Nov 1995 12:51:16 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177478>; Tue, 14 Nov 1995 12:51:07 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: Christian DONOT <Christian.Donot@inria.fr> Cc: mbone Subject: Re: Status of mae-bone.psi.net on MBone In-Reply-To: Your message of "Tue, 14 Nov 1995 10:44:28 PST." <199511141844.KAA08530@rx7.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Nov 1995 12:51:04 PST From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov14.125107pst.177478@crevenia.parc.xerox.com> In message <199511141844.KAA08530@rx7.ee.lbl.gov> Van said: > Mwatch almost always lies to you. > > You *cannot* determine multicast routes using mwatch. > > The *only* reliable way to determine multicast routes is with mtrace. Just to emphasize Van's points, I am attaching mtrace's of Christian's examples: (the "-t 127" is necessary to deal with various TTL problems) Christian: >At 16:15 (In France) : >mra -s fmroute1-1.exp.edf.fr -d mae-east.digex.net % mtrace -s -t 127 fmroute1-1.exp.edf.fr mae-east.digex.net Mtrace from 192.70.92.133 to 192.41.177.115 via group 224.2.0.1 Querying full reverse path... 0 mae-east.digex.net (192.41.177.115) -1 mae-bone.psi.net (192.41.177.247) DVMRP thresh^ 64 -2 fmroute1-1.exp.edf.fr (192.70.92.133) DVMRP thresh^ 64 -3 fmroute1-1.exp.edf.fr (192.70.92.133) Round trip time 373 ms Christian: >mra -s mae-east.digex.net -d fmroute1-1.exp.edf.fr >no route available % mtrace -s -t 127 mae-east.digex.net fmroute1-1.exp.edf.fr Mtrace from 192.41.177.115 to 192.70.92.133 via group 224.2.0.1 Querying full reverse path... * switching to hop-by-hop: 0 fmroute1-1.exp.edf.fr (192.70.92.133) -1 fmroute1-1.exp.edf.fr (192.70.92.133) DVMRP thresh^ 1 -2 * * mae-bone.psi.net (192.41.177.247) DVMRP thresh^ 64 -3 mae-east.digex.net (192.41.177.115) Round trip time 563 ms (Note that mtrace displays reverse paths; the first mtrace is for packets sourced at fmroute1-1, the second is for packets sourced at mae-east.digex.net...) Bill From list-mgr@ISI.EDU Tue Nov 14 04:59:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18219>; Tue, 14 Nov 1995 12:59:44 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA18212>; Tue, 14 Nov 1995 12:59:43 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15122(7)>; Tue, 14 Nov 1995 12:59:32 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177478>; Tue, 14 Nov 1995 12:59:23 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: John Brezak <brezak@apollo.hp.com> Cc: mbone-na Subject: Re: MBONE troubles ?? In-Reply-To: Your message of "Tue, 14 Nov 1995 08:55:11 PST." <199511141655.AA178868111@relay.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Nov 1995 12:59:10 PST From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov14.125923pst.177478@crevenia.parc.xerox.com> In message <199511141655.AA178868111@relay.hp.com> you write: >We seem to be getting very sporadic connectivity to the MBONE. This is as far > as I can see - > >15.255.176.33 (matmos.hpl.hp.com): <v3.2> > 131.119.244.11 (utumno.barrnet.net) [2/64/tunnel] > 15.255.176.33 (matmos.hpl.hp.com) [1/1/querier] > >Can someone trace this from outside of our firewall ?? utumno.barrnet.net has historically been very difficult to use mtrace through; I don't know if it's a bug in the cisco that is the previous hop for me, or if it is something else, but I have never had much luck with it. All I can tell right now is that utumno.barrnet.net thinks that its tunnel to matmos is down: 131.119.244.11 (utumno.barrnet.net) [version 3.4]: 131.119.244.11 -> 15.255.176.33 (matmos.hpl.hp.com) [1/64/tunnel/down] Perhaps you could run a tcpdump on a transit network in between matmos and utumno and see if you can figure out why utumno is not getting the neighbor probes and routing updates that it expects to be getting from matmos. If it helps, these are the times (with a resolution of about an hour) of your networks' routing flaps over the past 36 hours: Mon, 09:30:20 Mon, 10:47:27 Mon, 16:09:28 Mon, 17:04:23 Mon, 18:06:38 Mon, 19:05:15 Mon, 20:03:19 Mon, 21:04:15 Mon, 22:16:15 Mon, 23:02:51 Tue, 00:45:16 Tue, 01:14:19 Tue, 02:10:06 Tue, 03:03:40 Tue, 04:05:16 Tue, 07:16:27 Tue, 08:08:28 Tue, 11:10:32 Tue, 12:28:46 Bill From list-mgr@ISI.EDU Tue Nov 14 07:19:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25924>; Tue, 14 Nov 1995 15:22:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25891>; Tue, 14 Nov 1995 15:22:18 -0800 Received: from aimnet.com (aimnet.aimnet.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA25882>; Tue, 14 Nov 1995 15:22:16 -0800 Received: from aimnet4.aimnet.com (aimnet4.aimnet.com [204.247.0.120]) by aimnet.com (8.6.12/8.6.12) with SMTP id PAA19758 for <mbone@ISI.EDU>; Tue, 14 Nov 1995 15:17:36 -0800 Date: Tue, 14 Nov 1995 15:19:50 -0800 (PST) From: David Zhang <davidz@aimnet.com> To: mbone Subject: subscribe Message-Id: <Pine.SUN.3.91.951114151930.24386Z-100000@aimnet4.aimnet.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe From list-mgr@ISI.EDU Wed Nov 15 17:32:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26621>; Tue, 14 Nov 1995 15:33:40 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26597>; Tue, 14 Nov 1995 15:33:09 -0800 Received: from union.or.jp (nyanya.union.or.jp) by venera.isi.edu (5.65c/5.61+local-22) id <AA26588>; Tue, 14 Nov 1995 15:33:07 -0800 Received: (from koji@localhost) by union.or.jp (8.7.1+2.6Wbeta4/3.4W-10/26/95) id IAA05310; Wed, 15 Nov 1995 08:32:55 +0900 (JST) Date: Wed, 15 Nov 1995 08:32:55 +0900 (JST) From: Kjm"vandiemen"Takashi <koji@union.or.jp> Message-Id: <199511142332.IAA05310@union.or.jp> To: davidz@aimnet.com Cc: mbone In-Reply-To: <Pine.SUN.3.91.951114151930.24386Z-100000@aimnet4.aimnet.com> (message from David Zhang on Tue, 14 Nov 1995 15:19:50 -0800 (PST)) Subject: Re: subscribe You should send request to "mbone-requet@" Then choose your nearest local group. Takashi Kojima koji@union.or.jp From list-mgr@ISI.EDU Tue Nov 14 09:44:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06966>; Tue, 14 Nov 1995 17:49:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06880>; Tue, 14 Nov 1995 17:47:51 -0800 Received: from mercury.Sun.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA06873>; Tue, 14 Nov 1995 17:47:50 -0800 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id RAA19109; Tue, 14 Nov 1995 17:47:49 -0800 Received: from jurassic.Eng.Sun.COM (camilla.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04778; Tue, 14 Nov 1995 17:47:44 -0800 Received: from offshore.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id RAA12707; Tue, 14 Nov 1995 17:47:33 -0800 Received: by offshore.Eng.Sun.COM (5.x/SMI-SVR4) id AA00531; Tue, 14 Nov 1995 17:44:12 -0800 Date: Tue, 14 Nov 1995 17:44:12 -0800 From: Allyn.Romanow@Eng.Sun.COM (Allyn Romanow) Message-Id: <9511150144.AA00531@offshore.Eng.Sun.COM> To: mbone Subject: mirror for Multicast version 3.5/3.6 for Solaris 2.4 X-Sun-Charset: US-ASCII playground, the usual location, will be down Nov. 15-20, the files are mirrored on cnet.unb.ca:/pub/unix/solaris/multicast From list-mgr@ISI.EDU Tue Nov 14 12:05:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20733>; Tue, 14 Nov 1995 20:07:26 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20394>; Tue, 14 Nov 1995 20:05:39 -0800 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA20387>; Tue, 14 Nov 1995 20:05:38 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id UAA15413; Tue, 14 Nov 1995 20:05:36 -0800 Date: Tue, 14 Nov 1995 20:05:36 -0800 From: Dino Farinacci <dino@cisco.com> Message-Id: <199511150405.UAA15413@stilton.cisco.com> To: van@ee.lbl.gov Cc: Christian.Donot@inria.fr, fedor@msf.psi.net, mbone In-Reply-To: Van Jacobson's message of Tue, 14 Nov 95 10:44:28 PST <199511141844.KAA08530@rx7.ee.lbl.gov> Subject: Status of mae-bone.psi.net on MBone >> Mtrace was designed to work in today's mbone & works through firewalls >> and to routers with limitted unicast routing. You should use it. If >> you find it doesn't work because sites are running ciscos or ancient >> mrouted's that don't support mtrace, you should complain loudly until >> people fix these broken sites. But you won't have any luck reporting >> "problems" based on the lies that mwatch tells you. If you want mtrace in ciscos, you need to upgrade your routers to 11.0(3). If you want DVMRP pruning/grafting, you need to upgrade your routers to 11.0(3.1). Dino From list-mgr@ISI.EDU Wed Nov 15 10:22:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03620>; Wed, 15 Nov 1995 02:32:20 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03482>; Wed, 15 Nov 1995 02:24:23 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA03475>; Wed, 15 Nov 1995 02:24:22 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA23218>; Wed, 15 Nov 1995 02:23:48 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.06766-0@bells.cs.ucl.ac.uk>; Wed, 15 Nov 1995 10:22:25 +0000 From: Mark Handley <M.Handley@cs.ucl.ac.uk> X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Van Jacobson <van@ee.lbl.gov> Cc: Christian DONOT <Christian.Donot@inria.fr>, fedor@msf.psi.net (Mark S. Fedor), mbone Subject: Re: Status of mae-bone.psi.net on MBone In-Reply-To: Your message of "Tue, 14 Nov 95 10:44:28 PST." <199511141844.KAA08530@rx7.ee.lbl.gov> Date: Wed, 15 Nov 95 10:22:21 +0000 Message-Id: <11259.816430941@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >You should have interpreted the "mae-bone has no default route" >comments from Mark F. & Mark H. as "mwatch will lie to you about >routes through mae-east". Let me make it a bit more definite: > > Mwatch almost always lies to you. > > You *cannot* determine multicast routes using mwatch. > > The *only* reliable way to determine multicast routes is with mtrace. I agree entirely with Van's comments here. Don't use mr to find routes. Mr was written when there was no alternative - it's been useful, but its routes were always suspect. There are two occasions when I use the mwatch code now - when I get no result from mtrace because of obsolete V2 mrouteds, and using mri to find when an mrouted last was alive (after I've tried mrinfo). Even these two uses need to be read with a certain amount of scepticism. Mark From list-mgr@ISI.EDU Wed Nov 15 12:40:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03803>; Wed, 15 Nov 1995 02:55:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03757>; Wed, 15 Nov 1995 02:51:09 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA03750>; Wed, 15 Nov 1995 02:51:06 -0800 Received: from nez-perce.inria.fr by quark.isi.edu (5.65c/5.61+local-20) id <AA23262>; Wed, 15 Nov 1995 02:50:59 -0800 Received: from electre.inria.fr (electre.inria.fr [128.93.2.11]) by nez-perce.inria.fr (8.7.1/8.6.9) with SMTP id LAA19492; Wed, 15 Nov 1995 11:40:15 +0100 (MET) Received: by electre.inria.fr; Wed, 15 Nov 1995 11:40:14 +0100 From: Christian DONOT <Christian.Donot@inria.fr> Message-Id: <199511151040.AA25235@electre.inria.fr> Subject: Re: Assymetric mrouted tunnels To: bc@sunet.se (Bjorn Carlsson) Date: Wed, 15 Nov 1995 11:40:14 +0100 (MET) Cc: fedor@noc.psi.net, fenner@parc.xerox.com, van@ee.lbl.gov, Jacky.Thibault@ccr.jussieu.fr, mbone In-Reply-To: <199511142025.VAA22953@koff.pilsnet.sunet.se> from "Bjorn Carlsson" at Nov 14, 95 09:25:24 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Quoting > Bjorn Carlsson wrote, > > Well, the tunnel from mae-bone.psi.net to fmroute1-1 has metric 2 (this > one has assymetric metrics too, btw) and there's a metric 1 tunnel betwean > fmroute1-1 and r-jusren. This give a total metric of 3. In fact, that's the tunnel from fmroute1-1.exp.edf.fr to mae-bone.psi.net who is 2. > stockholm.mbone.ebone.net has a metric 1 tunnel from mae-bone.psi.net and > you suggest I change the metric of the tunnel to r-jusren to 1. This will > give a total metric of 2, which is lower than the path through fmroute1-1. No, in my previous mail I suggested you a metric 3 through fmroute1-1. ==>Please, could you put a metric 3 toward fmroute1-1.exp.edf.fr and a metric 1 ==>toward r-jusren.reseau.jussieu.fr. So, with the metric's game (let me know if I make a mistake), I propose the topologie following : stockholm.mbone.ebone.net / | \ / | \ <1> | <1> / | \ / | \ r-jusren.reseau.jussieu.fr <3> mae-bone.psi.net \ | / \ | / <1> | <2> \ | / \ | / fmroute1-1.exp.edf.fr Thanks Van, Bill for your explanation about mwatch and mtrace and on the necessity of the "-t 127". Christian From list-mgr@ISI.EDU Wed Nov 15 13:15:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04236>; Wed, 15 Nov 1995 03:26:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04104>; Wed, 15 Nov 1995 03:19:11 -0800 Received: from sunic.sunet.se by venera.isi.edu (5.65c/5.61+local-22) id <AA04097>; Wed, 15 Nov 1995 03:19:08 -0800 Received: from koff.pilsnet.sunet.se by sunic.sunet.se (8.6.8/2.03) id MAA27980; Wed, 15 Nov 1995 12:19:02 +0100 Received: from localhost.sunet.se by koff.pilsnet.sunet.se (8.6.10/6.0) id MAA24912; Wed, 15 Nov 1995 12:15:08 +0100 Message-Id: <199511151115.MAA24912@koff.pilsnet.sunet.se> To: Christian.Donot@inria.fr Cc: fedor@noc.psi.net, fenner@parc.xerox.com, van@ee.lbl.gov, Jacky.Thibault@ccr.jussieu.fr, mbone Subject: Re: Assymetric mrouted tunnels From: Bjorn Carlsson <bc@sunet.se> In-Reply-To: Your message of "Wed, 15 Nov 1995 11:40:14 +0100 (MET)" References: <199511151040.AA25235@electre.inria.fr> X-Mailer: Mew beta version 0.98 on Emacs 19.28.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 15 Nov 95 12:15:08 +0100 Sender: bc@sunet.se > No, in my previous mail I suggested you a metric 3 through fmroute1-1. > > ==>Please, could you put a metric 3 toward fmroute1-1.exp.edf.fr and a metric 1 > ==>toward r-jusren.reseau.jussieu.fr. > > So, with the metric's game (let me know if I make a mistake), I propose the topologie > following : > > stockholm.mbone.ebone.net > / | \ > / | \ > <1> | <1> > / | \ > / | \ > r-jusren.reseau.jussieu.fr <3> mae-bone.psi.net > \ | / > \ | / > <1> | <2> > \ | / > \ | / > fmroute1-1.exp.edf.fr Well, correct me if I'm wrong, I'm not really an expert on this mrouted stuff, but with the topology above, there is a metric of 2 from r-jusren (via stockholm) to mae-bone (1+1), and a metric of 3 via the fmroute1-1 path (1+2). So wouldn't receivers behind r-jusren get their mbone feed from US sources through stockholm and not through fmroute1-1 which I guess is intended? --BC From list-mgr@ISI.EDU Wed Nov 15 11:19:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04293>; Wed, 15 Nov 1995 03:30:08 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04139>; Wed, 15 Nov 1995 03:20:31 -0800 Received: from swan.cl.cam.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA04131>; Wed, 15 Nov 1995 03:20:14 -0800 Received: from cl.cam.ac.uk (actually pb@dean.cl.cam.ac.uk (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Wed, 15 Nov 1995 11:19:34 +0000 X-Mailer: exmh version 1.6.4+cl+patch 10/10/95 X-Uri: <URL:http://www.cl.cam.ac.uk/users/pb> X-Face: &@N3QE9h|>f`igFCkZ'a1`z=nNLXb}k>H(79G"V?@!&*yn)uhPBctF1vc}LD'{OA%$bs X+l[wN,I^G8kKj2NFxQrr@1C4QBC]hq5-%ZkV,^Zl/qE<0`zCQ1nM+]-N<^WG[H)]?d) A:L9AFgOU[BjbaY)uBAMz}h!fm^O0# To: mbone Subject: Re: Status of mae-bone.psi.net on MBone In-Reply-To: Your message of Wed, 15 Nov 1995 10:22:21 +0000. <11259.816430941@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 1995 11:19:17 +0000 From: Piete Brooks <Piete.Brooks@cl.cam.ac.uk> Message-Id: <"swan.cl.cam.:047800:951115111951"@cl.cam.ac.uk> > I agree entirely with Van's comments here. Don't use mr to find routes. I have been thinking of withdrawing the facility -- sounds like others agree. However, another use that people might care to make of the system (with Mark's scepticism of course!) is for looking at a crude approximation to the stats on the versions of MC routers running in various domains. http://www.cl.cam.ac.uk:80/cgi-bin/mr-vers gives the lot, while (e.g.) http://www.cl.cam.ac.uk:80/cgi-bin/mr-vers?sub=fi just looks at fi [[ Interesting reading .... MBone mrouted version info for fi as of 95/11/15 11:08:43 GMT Version hosts percent ------- ----- ------- 11.0PM 11 28.2% 3.3 6 15.4% 11.0M 6 15.4% 10.3 5 12.8% 3.6PGM 4 10.3% 3.4 4 10.3% 3.5PGM 1 2.6% 10.2 1 2.6% 2.2 1 2.6% ------- ----- ------- Total 39 vs: MBone mrouted version info for uk as of 95/11/15 11:08:43 GMT Version hosts percent ------- ----- ------- 3.6PGM 29 32.2% 3.2 26 28.9% 3.4 14 15.6% 3.3 14 15.6% 3.5PGM 6 6.7% 3.1 1 1.1% ------- ----- ------- Total 90 ]] Also, a look at http://www.cl.cam.ac.uk:80/cgi-bin/mr-asym may (possibly) show up some anomilies you may care to look at. From list-mgr@ISI.EDU Wed Nov 15 16:05:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04893>; Wed, 15 Nov 1995 04:07:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04874>; Wed, 15 Nov 1995 04:05:37 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA04867>; Wed, 15 Nov 1995 04:05:32 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id OAA07817; Wed, 15 Nov 1995 14:05:16 +0200 Date: Wed, 15 Nov 1995 14:05:16 +0200 Message-Id: <199511151205.OAA07817@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Piete Brooks <Piete.Brooks@cl.cam.ac.uk> Cc: mbone Subject: Re: Status of mae-bone.psi.net on MBone In-Reply-To: <"swan.cl.cam.:047800:951115111951"@cl.cam.ac.uk> References: <11259.816430941@cs.ucl.ac.uk> <"swan.cl.cam.:047800:951115111951"@cl.cam.ac.uk> Piete Brooks writes: > > However, another use that people might care to make of the system (with Mark's > scepticism of course!) is for looking at a crude approximation to the stats on > the versions of MC routers running in various domains. > http://www.cl.cam.ac.uk:80/cgi-bin/mr-vers gives the lot, while (e.g.) > http://www.cl.cam.ac.uk:80/cgi-bin/mr-vers?sub=fi just looks at fi > > [[ Interesting reading .... I think this utility is of most importance when trying to get all boxes up to the required functionality. In the meanwhile, I'm against limiting unicast connectivity of boxes running mrouteds because that limits the ability of individual to see the state of the tunnels via mrinfo. Maybe the day will come when everything supports mtrace but we are not there just yet. Pete From list-mgr@ISI.EDU Wed Nov 15 00:50:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06645>; Wed, 15 Nov 1995 08:52:18 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06543>; Wed, 15 Nov 1995 08:51:03 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA06536>; Wed, 15 Nov 1995 08:51:02 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14946(1)>; Wed, 15 Nov 1995 08:50:58 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 15 Nov 1995 08:50:47 -0800 To: Allyn.Romanow@eng.sun.com (Allyn Romanow) Cc: mbone Subject: Re: mirror for Multicast version 3.5/3.6 for Solaris 2.4 In-Reply-To: Your message of "Tue, 14 Nov 95 17:44:12 PST." <9511150144.AA00531@offshore.Eng.Sun.COM> Date: Wed, 15 Nov 1995 08:50:43 PST Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov15.085047pst.177478@crevenia.parc.xerox.com> In message <9511150144.AA00531@offshore.Eng.Sun.COM> you write: >playground, the usual location, will be down Nov. 15-20 The files are also now available from ftp.parc.xerox.com:/pub/net-research/ipmulti/Solaris/ . Bill From list-mgr@ISI.EDU Wed Nov 15 17:06:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08847>; Wed, 15 Nov 1995 09:22:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08826>; Wed, 15 Nov 1995 09:21:58 -0800 Received: from darkstar.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA08803>; Wed, 15 Nov 1995 09:21:37 -0800 Received: from cancer.ucs.ed.ac.uk by darkstar.isi.edu (5.65c/5.61+local-20) id <AA28687>; Wed, 15 Nov 1995 09:19:21 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id RAA06286; Wed, 15 Nov 1995 17:06:28 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id RAA21313; Wed, 15 Nov 1995 17:06:22 GMT Date: Wed, 15 Nov 1995 17:06:20 +0000 (GMT) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Bill Fenner <fenner@parc.xerox.com> Cc: Allyn Romanow <Allyn.Romanow@eng.sun.com>, mbone Subject: Re: mirror for Multicast version 3.5/3.6 for Solaris 2.4 In-Reply-To: <95Nov15.085047pst.177478@crevenia.parc.xerox.com> Message-Id: <Pine.SV4.3.91.951115170221.20249Q-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Nov 1995, Bill Fenner wrote: > In message <9511150144.AA00531@offshore.Eng.Sun.COM> you write: > >playground, the usual location, will be down Nov. 15-20 > > The files are also now available from > ftp.parc.xerox.com:/pub/net-research/ipmulti/Solaris/ . ...and all of the MICE National Support Centres' ftp servers. See http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/vconf.html for an index to one of them. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Wed Nov 15 07:52:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10754>; Wed, 15 Nov 1995 09:56:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10671>; Wed, 15 Nov 1995 09:55:47 -0800 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA10663>; Wed, 15 Nov 1995 09:55:45 -0800 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA20254; Wed, 15 Nov 1995 12:52:50 +0500 Message-Id: <9511151752.AA20254@msf.psi.net.> To: mbone Subject: MAE-BONE.psi.net is down! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <20252.816457969.1@msf.psi.net> Date: Wed, 15 Nov 1995 12:52:50 -0500 From: "Mark S. Fedor" <fedor@msf.psi.net> Content-Length: 295 You see what you did! You people start talking about my machine and it breaks. Thanks a lot.... :^) MAE-BONE is not reachable on the network. The machine is fine, however, network connectivity is non-existant. It might be its port to mae-east. We are working on it now. mark fedor PSINet From list-mgr@ISI.EDU Wed Nov 15 16:05:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04893>; Wed, 15 Nov 1995 04:07:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04874>; Wed, 15 Nov 1995 04:05:37 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA04867>; Wed, 15 Nov 1995 04:05:32 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id OAA07817; Wed, 15 Nov 1995 14:05:16 +0200 Date: Wed, 15 Nov 1995 14:05:16 +0200 Message-Id: <199511151205.OAA07817@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Piete Brooks <Piete.Brooks@cl.cam.ac.uk> Cc: mbone Subject: Re: Status of mae-bone.psi.net on MBone In-Reply-To: <"swan.cl.cam.:047800:951115111951"@cl.cam.ac.uk> References: <11259.816430941@cs.ucl.ac.uk> <"swan.cl.cam.:047800:951115111951"@cl.cam.ac.uk> Piete Brooks writes: > > However, another use that people might care to make of the system (with Mark's > scepticism of course!) is for looking at a crude approximation to the stats on > the versions of MC routers running in various domains. > http://www.cl.cam.ac.uk:80/cgi-bin/mr-vers gives the lot, while (e.g.) > http://www.cl.cam.ac.uk:80/cgi-bin/mr-vers?sub=fi just looks at fi > > [[ Interesting reading .... I think this utility is of most importance when trying to get all boxes up to the required functionality. In the meanwhile, I'm against limiting unicast connectivity of boxes running mrouteds because that limits the ability of individual to see the state of the tunnels via mrinfo. Maybe the day will come when everything supports mtrace but we are not there just yet. Pete From list-mgr@ISI.EDU Wed Nov 15 03:59:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18376>; Wed, 15 Nov 1995 12:08:30 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18165>; Wed, 15 Nov 1995 12:02:13 -0800 Received: from aimnet.com (aimnet.aimnet.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA18158>; Wed, 15 Nov 1995 12:02:11 -0800 Received: from aimnet4.aimnet.com (aimnet4.aimnet.com [204.247.0.120]) by aimnet.com (8.6.12/8.6.12) with SMTP id LAA15220; Wed, 15 Nov 1995 11:57:31 -0800 Date: Wed, 15 Nov 1995 11:59:44 -0800 (PST) From: David Zhang <davidz@aimnet.com> To: KjmvandiemenTakashi <koji@union.or.jp> Cc: mbone Subject: Re: subscribe In-Reply-To: <199511142332.IAA05310@union.or.jp> Message-Id: <Pine.SUN.3.91.951115115834.525S-100000@aimnet4.aimnet.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks, David On Wed, 15 Nov 1995, KjmvandiemenTakashi wrote: > You should send request to "mbone-requet@" > Then choose your nearest local group. > > Takashi Kojima > koji@union.or.jp > From list-mgr@ISI.EDU Wed Nov 15 05:06:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21057>; Wed, 15 Nov 1995 13:09:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21017>; Wed, 15 Nov 1995 13:08:47 -0800 Received: from decu13.triumf.ca ([142.90.100.8]) by venera.isi.edu (5.65c/5.61+local-22) id <AA21010>; Wed, 15 Nov 1995 13:08:46 -0800 Received: by decu13.triumf.ca (5.65/DEC-Ultrix/4.3) id AA13132; Wed, 15 Nov 1995 13:06:45 -0800 Date: Wed, 15 Nov 1995 13:06:44 -0800 (PST) From: Andrew Daviel <andrew@andrew.triumf.ca> To: Gorm Haug Eriksen <g.h.eriksen@usit.uio.no> Cc: mbone Subject: Re: imm for linux In-Reply-To: <199511131902.TAA29540@monet.uio.no> Message-Id: <Pine.LNX.3.91.951115130504.28724E-100000@andrew.triumf.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 13 Nov 1995, Gorm Haug Eriksen wrote: > > Someone ported, or know of a port, of imm -> linux? I've got one at ftp://andrew.triumf.ca/pub/packages/imm.linux.tar.gz I was trying to see Meteosat images that keep popping up on my sd, but never saw one. I haven't really tried imm properly. Andrew Daviel email: advax@triumf.ca TRIUMF voice: 604-222-7376 4004 Wesbrook Mall fax: 604-222-7307 Vancouver BC http://andrew.triumf.ca/~andrew Canada V6T 2A3 49D14.7N 123D13.6W From list-mgr@ISI.EDU Wed Nov 15 05:03:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20849>; Wed, 15 Nov 1995 13:05:21 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20782>; Wed, 15 Nov 1995 13:04:39 -0800 Received: from huey.csun.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA20773>; Wed, 15 Nov 1995 13:04:38 -0800 Received: (hbrtv231@localhost) by huey.csun.edu (8.6.12/8.6.4) id NAA18285; Wed, 15 Nov 1995 13:03:33 -0800 Date: Wed, 15 Nov 1995 13:03:29 -0800 (PST) From: lacuion johnson <hbrtv231@huey.csun.edu> To: mbone Subject: how to broadcast Message-Id: <Pine.HPP.3.91.951115125322.16304A-100000@huey.csun.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I want to know how to broadcast my videos over the mbone broadcasting system. I need to know what to do and what is needed. I have access to hp-unix at csun.edu. This is news to me and interesting to try. It beats bicycling. regards From list-mgr@ISI.EDU Wed Nov 15 11:49:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24154>; Wed, 15 Nov 1995 13:53:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24119>; Wed, 15 Nov 1995 13:52:29 -0800 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA24111>; Wed, 15 Nov 1995 13:52:27 -0800 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA21194; Wed, 15 Nov 1995 16:49:43 +0500 Message-Id: <9511152149.AA21194@msf.psi.net.> To: mbone Subject: mae-bone is back up Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <21192.816472182.1@msf.psi.net> Date: Wed, 15 Nov 1995 16:49:42 -0500 From: "Mark S. Fedor" <fedor@msf.psi.net> Content-Length: 135 mae-bone came back up @ 14:15 EST. The port for mae-bone on mae-east was hung. MFS restored the connectivity. Thanks, mark fedor From list-mgr@ISI.EDU Wed Nov 15 11:30:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02816>; Wed, 15 Nov 1995 19:49:14 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02250>; Wed, 15 Nov 1995 19:30:41 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA02243>; Wed, 15 Nov 1995 19:30:39 -0800 Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id TAA00817 for <mbone@ISI.EDU>; Wed, 15 Nov 1995 19:30:26 -0800 Message-Id: <199511160330.TAA00817@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: mbone Subject: IRIX 5.3 and mrouted 3.6? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 1995 19:30:24 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> I just got this new Indy with Irix 5.3 and I am wondering what I have to do to get mrouted 3.6 running on it. Just a bit lost here since I don't have sources like in FreeBSD 8) Tnks! Amancio From list-mgr@ISI.EDU Wed Nov 15 14:15:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07793>; Wed, 15 Nov 1995 22:33:40 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07185>; Wed, 15 Nov 1995 22:16:05 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA07178>; Wed, 15 Nov 1995 22:16:02 -0800 Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id WAA00256 for <mbone@ISI.EDU>; Wed, 15 Nov 1995 22:15:58 -0800 Message-Id: <199511160615.WAA00256@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 Cc: mbone Subject: Re: IRIX 5.3 and mrouted 3.6? In-Reply-To: Your message of "Wed, 15 Nov 1995 19:30:24 PST." <199511160330.TAA00817@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 1995 22:15:57 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Sorry guys , I managed to sort it out over here and I was able to run mrouted 3.6. Amancio >>> "Amancio Hasty Jr." said: > > I just got this new Indy with Irix 5.3 and I am wondering what I have to > do to get mrouted 3.6 running on it. Just a bit lost here since I don't > have sources like in FreeBSD 8) > > Tnks! > Amancio > > > From list-mgr@ISI.EDU Thu Nov 16 06:35:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20349>; Thu, 16 Nov 1995 08:37:16 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20321>; Thu, 16 Nov 1995 08:36:06 -0800 Received: from mailer.jhuapl.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA20312>; Thu, 16 Nov 1995 08:36:01 -0800 Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA18090; Thu, 16 Nov 1995 11:35:55 -0500 Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA22879; Thu, 16 Nov 1995 11:35:54 -0500 Date: Thu, 16 Nov 1995 11:35:53 -0500 (EST) From: Jim Bogard BIX <jimbo@aplcomm.jhuapl.edu> To: mbone <mbone> Subject: Help w/ versions Message-Id: <Pine.SOL.3.91.951116112346.18856C-100000@aplcomm.jhuapl.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 611 I'm a little confused with this version business. 1. Is there any way to run anything other than mrouted 2.2 on a Solaris 2.3 machine? (I know I should upgrade, but it really isn't feasible at the moment.) Some of you may recall, I've had problems with Suns running Sol2.3/mrouted2.2 but not with SGIs (irix5.2/mrouted2.2). I'm hoping it will go away if I use 3.6 - unfortunately, in this instance, I need to use a Sun. Groan. Thanks. J-. ---- Jim Bogard JHU/APL BIX Group "This is my banjo. There are many Backbone Network Engineer like it, but this one is mine." From list-mgr@ISI.EDU Thu Nov 16 07:16:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22188>; Thu, 16 Nov 1995 09:18:46 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22086>; Thu, 16 Nov 1995 09:17:04 -0800 Received: from panix3.panix.com by venera.isi.edu (5.65c/5.61+local-22) id <AA22078>; Thu, 16 Nov 1995 09:17:02 -0800 Received: (from kenf@localhost) by panix3.panix.com (8.7/8.7/PanixU1.3) id MAA26175; Thu, 16 Nov 1995 12:16:55 -0500 (EST) Date: Thu, 16 Nov 1995 12:16:54 -0500 (EST) From: Ken Feingold <kenf@panix.com> To: mbone Subject: vat / hostname problem Message-Id: <Pine.SUN.3.91.951116121126.25178A-100000@panix3.panix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Perhaps someone can help with this problem: On only one of the SGI's in our LAN (named belle) - which also happens to be doing DNS and is the nishost- when launching vat from sd I get the error "vat: unknown host belle" vic, nv, etc work fine, and vat works with the same .sd.tcl on the other sgi's in the lan. Any answers or suggestions would be most appreciated. Ken Feingold Faculty Advisor MFA Computer Art Dept. School of Visual Arts, NY From list-mgr@ISI.EDU Thu Nov 16 23:13:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12441>; Thu, 16 Nov 1995 15:14:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12397>; Thu, 16 Nov 1995 15:13:36 -0800 Received: from gizmo.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA12387>; Thu, 16 Nov 1995 15:13:32 -0800 Received: from localhost (martin@localhost) by gizmo.lut.ac.uk (8.7.1/8.6.9) with SMTP id XAA21365; Thu, 16 Nov 1995 23:13:30 GMT Message-Id: <199511162313.XAA21365@gizmo.lut.ac.uk> To: mbone, rem-conf@es.net X-Uri: <URL:http://www.roads.lut.ac.uk/~martin> Subject: MBONE & WWW Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <21363.816563605.1@mrrl.lut.ac.uk> Date: Thu, 16 Nov 1995 23:13:25 +0000 From: Martin Hamilton <martin@mrrl.lut.ac.uk> I've created a mailing list for discussions/hacking on WWW and IP multicast integration. If this sounds like your cup of tea, feel free to join in the fun - just send an email message to w-bone-request@mrrl.lut.ac.uk with a message body consisting of the word "subscribe" on its own The current topic of conversation is multicast ICP (Harvest's Internet Cache Protocol - cf. <URL:http://excalibur.usc.edu/>) Cheerio, Martin From list-mgr@ISI.EDU Fri Nov 17 13:06:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04988>; Fri, 17 Nov 1995 03:11:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04977>; Fri, 17 Nov 1995 03:10:06 -0800 Received: from basil.cdt.luth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA04970>; Fri, 17 Nov 1995 03:10:02 -0800 Received: from ganymede.cdt.luth.se (root@ganymede.cdt.luth.se [130.240.34.6]) by basil.cdt.luth.se (8.6.12/8.6.12) with ESMTP id MAA24776 for <mbone@ISI.EDU>; Fri, 17 Nov 1995 12:06:28 +0100 Received: from ganymede.cdt.luth.se (hakanl@localhost [127.0.0.1]) by ganymede.cdt.luth.se (8.6.12/8.6.12) with ESMTP id MAA04766 for <mbone@ISI.EDU>; Fri, 17 Nov 1995 12:06:17 +0100 Message-Id: <199511171106.MAA04766@ganymede.cdt.luth.se> X-Mailer: exmh version 1.6.2 7/18/95 To: mbone Subject: Video coding question Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 17 Nov 1995 12:06:13 +0100 From: Hakan Lennestal <hakanl@cdt.luth.se> Hi all ! I have a question. Why does almost all "global" mbone events use nv as video coding method ? If h261 would be used instead we would be able to get much higher frame rate with almost the same quality and without higher bandwidth demands. Regards. /Hekan From list-mgr@ISI.EDU Sat Nov 18 05:12:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05058>; Fri, 17 Nov 1995 03:17:32 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05046>; Fri, 17 Nov 1995 03:16:42 -0800 Received: from sol.nuri.net by venera.isi.edu (5.65c/5.61+local-22) id <AA05039>; Fri, 17 Nov 1995 03:16:38 -0800 Received: from sosaria.inet.co.kr (sosaria.inet.co.kr [203.255.113.40]) by sol.nuri.net (8.6.12H1/8.6.9) with SMTP id UAA24222 for <mbone@ISI.EDU>; Fri, 17 Nov 1995 20:12:51 +0900 Date: Fri, 17 Nov 1995 20:12:51 +0900 Message-Id: <199511171112.UAA24222@sol.nuri.net> X-Sender: sosarian@nuri.net X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: "Kyung Soon, Park" <sosarian@nuri.net> Subject: video conferencing hardware device Is there any video conferencing hardware device on WIndows95 platform via MBONE? Camera and video board like that. I don't know any related product except Creative Lab's one. How's Creative Lab's products? ====================================================== I*NET Technologies, Inc. (http://www.iworld.net) Member of Technical Staff Mr. Kyung Soon, Park Email : mailto://sosarian@nuri.net URL : http://sol.nuri.net/~sosarian TEL : +82-2-538-6941 FAX : +82-2-508-5679 ====================================================== From list-mgr@ISI.EDU Fri Nov 17 00:25:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11362>; Fri, 17 Nov 1995 08:26:35 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11335>; Fri, 17 Nov 1995 08:25:22 -0800 Received: from camel.jpl.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA11325>; Fri, 17 Nov 1995 08:25:19 -0800 Received: from aeolus (aeolus.jpl.nasa.gov [137.79.7.22]) by camel.jpl.nasa.gov (8.6.10/8.6.6) with ESMTP id IAA04475 for <@camel:mbone@isi.edu>; Fri, 17 Nov 1995 08:25:09 -0800 Received: by aeolus (940816.SGI.8.6.9/920502.SGI.AUTO) for mbone@isi.edu id IAA21917; Fri, 17 Nov 1995 08:25:07 -0800 Date: Fri, 17 Nov 1995 08:25:07 -0800 From: elson@aeolus.jpl.nasa.gov (Lee Elson) Message-Id: <199511171625.IAA21917@aeolus> To: mbone Subject: multicast to unicast audio Does anyone know how to transfer audio from a multicasting machine to one that doesn't have multicast? Both machines have vat but I need to be able to connect the audio input from one vat session to the audio output of another. TIA From list-mgr@ISI.EDU Sat Nov 18 10:48:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12195>; Fri, 17 Nov 1995 08:48:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12158>; Fri, 17 Nov 1995 08:48:07 -0800 Received: from aohakobe.ipc.chiba-u.ac.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA12151>; Fri, 17 Nov 1995 08:48:04 -0800 Received: from aohakobe (localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.6.12/3.4Wbeta3 (-: 95041617) with ESMTP id BAA05345 for <mbone@ISI.EDU>; Sat, 18 Nov 1995 01:48:59 +0900 Message-Id: <199511171648.BAA05345@aohakobe.ipc.chiba-u.ac.jp> To: mbone Subject: Re: multicast to unicast audio In-Reply-To: Your message of "Fri, 17 Nov 1995 08:25:07 PST." <199511171625.IAA21917@aeolus> Date: Sat, 18 Nov 1995 01:48:58 +0900 From: Yozo Toda (TELEPHONE +81-43-290-3539) <yozo@aohakobe.ipc.chiba-u.ac.jp> > Does anyone know how to transfer audio from a multicasting machine to one that > doesn't have multicast? Both machines have vat but I need to be able to conne how about using CU-SeeMe reflector? you can configure a reflector to join some multicast session, and users of unicast machine connect to the reflector. -- yozo. From list-mgr@ISI.EDU Fri Nov 17 01:13:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13490>; Fri, 17 Nov 1995 09:14:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13421>; Fri, 17 Nov 1995 09:13:48 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA13413>; Fri, 17 Nov 1995 09:13:45 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14767(7)>; Fri, 17 Nov 1995 09:13:38 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177478>; Fri, 17 Nov 1995 09:13:26 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: elson@aeolus.jpl.nasa.gov (Lee Elson) Cc: mbone Subject: Re: multicast to unicast audio In-Reply-To: Your message of "Fri, 17 Nov 1995 08:25:07 PST." <199511171625.IAA21917@aeolus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Nov 1995 09:13:20 PST From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov17.091326pst.177478@crevenia.parc.xerox.com> In message <199511171625.IAA21917@aeolus> Lee Elson wrote: >Does anyone know how to transfer audio from a multicasting machine to one that >doesn't have multicast? Both machines have vat Check out the '-m' switch on the vat man page. It's basically: on the multicast host: vat -m unicasthost/unicastport conferenceaddr/conferenceport on the unicast host: vat multicasthost/unicastport Bill From list-mgr@ISI.EDU Fri Nov 17 17:12:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13618>; Fri, 17 Nov 1995 09:18:14 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13529>; Fri, 17 Nov 1995 09:15:56 -0800 Received: from v6.ph.gla.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA13522>; Fri, 17 Nov 1995 09:15:48 -0800 Received: from v2.ph.gla.ac.uk by v2.ph.gla.ac.uk with SMTP; Fri, 17 Nov 1995 17:12:42 GMT Date: Fri, 17 Nov 1995 17:12:05 +0000 From: "Alan J. Flavell" <FLAVELL@v2.ph.gla.ac.uk> Reply-To: A.Flavell@physics.gla.ac.uk To: Lee Elson <elson@aeolus.jpl.nasa.gov> Cc: mbone Subject: Re: multicast to unicast audio In-Reply-To: <199511171625.IAA21917@aeolus> Message-Id: <Pine.VMS.3.91-vms-b4.951117165135.5144A-100000@v2.ph.gla.ac.uk> Organization: Glasgow University Particle Physics Group Phone: +44 141 330 5454 - fax 334 9029 Organization: Legio Carborundum Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 17 Nov 1995, Lee Elson wrote: > Does anyone know how to transfer audio from a multicasting machine to one that > doesn't have multicast? Both machines have vat but I need to be able to connect > the audio input from one vat session to the audio output of another. TIA Yes, check out the -m option of vat. However, as I recall there is an error in the vat.1 man page where it shows an example of this being used. (Apologies if this has already been fixed in recent versions of the manpage). This example comes under "Bandwidth adaptation", but that is only a special case of relaying from multicast to unicast. The manpage says At work: vat -m home/5678/lpc4 At home: vat work/5678/lpc4 I think it's supposed to say (for relaying a typical Mbone conference e.g 224.2.223.54/62577/60811) At work: vat -m home/5678/lpc4 224.2.223.54/62577/60811 At home: vat work/5678/60811 at least, it worked for me with something like that (well I used gsm, instead of lpc4 which crashed for me). I'm only a smalltime player in this Mbone game, I hope I'm not too far wrong. From list-mgr@ISI.EDU Fri Nov 17 01:13:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13503>; Fri, 17 Nov 1995 09:15:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13447>; Fri, 17 Nov 1995 09:14:10 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA13440>; Fri, 17 Nov 1995 09:14:09 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14624(8)>; Fri, 17 Nov 1995 09:13:48 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177478>; Fri, 17 Nov 1995 09:13:42 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: Hakan Lennestal <hakanl@cdt.luth.se> Cc: mbone Subject: Re: Video coding question In-Reply-To: Your message of "Fri, 17 Nov 1995 03:06:13 PST." <199511171106.MAA04766@ganymede.cdt.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Nov 1995 09:13:39 PST From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov17.091342pst.177478@crevenia.parc.xerox.com> In message <199511171106.MAA04766@ganymede.cdt.luth.se> Hakan Lennestal wrote: >[Why do most sessions use nv coding instead of h.261?] Well, one reason is that the nv format is significantly less CPU-intensive on the receiver side. When I had a sparc2 on my desk, I had lots of trouble receiving some h.261 streams that were only 128kbps. The renderer couldn't keep up with the packets, so I got packet loss on my workstation. When they switched to sending nv it was fine. Since many people want to allow the least common denominator to view their video, they still use nv to transmit. Bill From list-mgr@ISI.EDU Fri Nov 17 17:35:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15676>; Fri, 17 Nov 1995 09:52:51 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15579>; Fri, 17 Nov 1995 09:50:50 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA15572>; Fri, 17 Nov 1995 09:50:48 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA01445>; Fri, 17 Nov 1995 09:50:00 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.29417-0@bells.cs.ucl.ac.uk>; Fri, 17 Nov 1995 17:35:50 +0000 From: Mark Handley <M.Handley@cs.ucl.ac.uk> X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Bill Fenner <fenner@parc.xerox.com> Cc: Hakan Lennestal <hakanl@cdt.luth.se>, mbone Subject: Re: Video coding question In-Reply-To: Your message of "Fri, 17 Nov 95 09:13:39 PST." <95Nov17.091342pst.177478@crevenia.parc.xerox.com> Date: Fri, 17 Nov 95 17:35:46 +0000 Message-Id: <4110.816629746@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >In message <199511171106.MAA04766@ganymede.cdt.luth.se> Hakan Lennestal wrote: >>[Why do most sessions use nv coding instead of h.261?] > >Well, one reason is that the nv format is significantly less CPU-intensive on >the receiver side. When I had a sparc2 on my desk, I had lots of trouble >receiving some h.261 streams that were only 128kbps. The renderer couldn't >keep up with the packets, so I got packet loss on my workstation. When they >switched to sending nv it was fine. nv is currently giving 1-1.5fps at 128Kbps. My guess is that 2fps H.261 would be considerably less bandwidth than 128Kbps, and would still be decodable on sparc 2 class machines. Of course if you didn't limit the frame rate and set the bandwidth to 128Kbps, then you may get high enough frame rates that you'd have problems. Generally I reckon most boxes cope with "normal" size H.261 up to about 4fps. If you've a *really* slow bow, then you can always display the image small and/or greyscale which does help low powered machines considerably. We've been using H.261 for all the MICE events for years with very few problems (unless I crank up an SS20 and send 15-20fps, CIF, but then I don't expect everyone to keep up). Mark From list-mgr@ISI.EDU Fri Nov 17 08:16:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17170>; Fri, 17 Nov 1995 10:18:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17118>; Fri, 17 Nov 1995 10:16:51 -0800 Received: from prom.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA17111>; Fri, 17 Nov 1995 10:16:47 -0800 Received: (dschluss@localhost) by prom.engin.umich.edu (8.6.12/8.6.4) id NAA12372; Fri, 17 Nov 1995 13:16:33 -0500 Date: Fri, 17 Nov 1995 13:16:32 -0500 (EST) From: "david a. schlussel" <dschluss@engin.umich.edu> To: Yozo Toda <yozo@aohakobe.ipc.chiba-u.ac.jp> Cc: mbone Subject: Re: multicast to unicast audio In-Reply-To: <199511171648.BAA05345@aohakobe.ipc.chiba-u.ac.jp> Message-Id: <Pine.SOL.3.91.951117131525.11233B-100000@prom.engin.umich.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII see my homepage. i put up a mail message on how to do it, but I haven't tried it yet. Good Luck +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ On Sat, 18 Nov 1995, Yozo Toda wrote: > > > Does anyone know how to transfer audio from a multicasting machine to one that > > doesn't have multicast? Both machines have vat but I need to be able to conne > > how about using CU-SeeMe reflector? > you can configure a reflector to join some multicast session, > and users of unicast machine connect to the reflector. > > -- yozo. > > From list-mgr@ISI.EDU Fri Nov 17 08:52:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18746>; Fri, 17 Nov 1995 10:51:56 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18711>; Fri, 17 Nov 1995 10:50:44 -0800 Received: from maelstrom.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA18704>; Fri, 17 Nov 1995 10:50:42 -0800 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.7.1/8.6.6) id NAA23707 for mbone@isi.edu; Fri, 17 Nov 1995 13:52:33 -0500 (EST) Message-Id: <199511171852.NAA23707@maelstrom.cc.mcgill.ca> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Yves Lepage <yves@CC.McGill.CA> Date: Fri, 17 Nov 95 13:52:31 -0500 To: mbone Subject: SD question Reply-To: yves@cc.mcgill.ca Hello, I was wondering why only one copy of SD can run per machine? What is so different in SD advertisements from the ordinary mcast traffic that SD can't share the port? Thanks. Yves Lepage From list-mgr@ISI.EDU Fri Nov 17 02:55:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19052>; Fri, 17 Nov 1995 10:56:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18998>; Fri, 17 Nov 1995 10:56:03 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA18991>; Fri, 17 Nov 1995 10:56:02 -0800 Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id KAA08491; Fri, 17 Nov 1995 10:55:11 -0800 Message-Id: <199511171855.KAA08491@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Bill Fenner <fenner@parc.xerox.com> Cc: Hakan Lennestal <hakanl@cdt.luth.se>, mbone Subject: Re: Video coding question In-Reply-To: Your message of "Fri, 17 Nov 1995 09:13:39 PST." <95Nov17.091342pst.177478@crevenia.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Nov 1995 10:55:10 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> >>> Bill Fenner said: > In message <199511171106.MAA04766@ganymede.cdt.luth.se> Hakan Lennestal wrot e: > >[Why do most sessions use nv coding instead of h.261?] > > Well, one reason is that the nv format is significantly less CPU-intensive o n > the receiver side. When I had a sparc2 on my desk, I had lots of trouble > receiving some h.261 streams that were only 128kbps. The renderer couldn't > keep up with the packets, so I got packet loss on my workstation. When they > switched to sending nv it was fine. > > Since many people want to allow the least common denominator to view their > video, they still use nv to transmit. I see however how many people do we expect nowdays to have sparc 2 class machines? Amancio From list-mgr@ISI.EDU Sat Nov 18 13:32:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21681>; Fri, 17 Nov 1995 11:36:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21515>; Fri, 17 Nov 1995 11:32:33 -0800 Received: from union.or.jp (nyanya.union.or.jp) by venera.isi.edu (5.65c/5.61+local-22) id <AA21508>; Fri, 17 Nov 1995 11:32:30 -0800 Received: from nyanya.union.or.jp (kool@localhost) by union.or.jp (8.7.1+2.6Wbeta4/3.4W-10/26/95) with ESMTP id EAA11565 for <mbone@ISI.edu>; Sat, 18 Nov 1995 04:32:18 +0900 (JST) Message-Id: <199511171932.EAA11565@union.or.jp> To: mbone Subject: Forward: Sun FastEthernet X-Mailer: Mew version 1.00.4 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sat_Nov_18_04:32:09_1995)--" Date: Sat, 18 Nov 1995 04:32:18 +0900 From: Yoshihiro Hirai <kool@union.or.jp> ----Next_Part(Sat_Nov_18_04:32:09_1995)-- Content-Type: Message/rfc822 Return-Path: mbone-jp-errorsto@sh.wide.ad.jp Received: from sh.wide.ad.jp (sh.wide.ad.jp [133.4.2.1]) by union.or.jp (8.7.1+2.6Wbeta4/3.4W-10/26/95) with SMTP id TAA25073 for <kool@union.or.jp>; Tue, 14 Nov 1995 19:51:52 +0900 (JST) Received: from union.or.jp by sh.wide.ad.jp (8.6.11+2.5Wb2/6.0) with ESMTP id TAA06939; Tue, 14 Nov 1995 19:34:12 +0900 Received: (from koji@localhost) by union.or.jp (8.7.1+2.6Wbeta4/3.4W-10/26/95) id TAA24800; Tue, 14 Nov 1995 19:36:27 +0900 (JST) Date: Tue, 14 Nov 1995 19:36:27 +0900 (JST) From: Kjm"vandiemen"Takashi <koji@union.or.jp> Message-Id: <199511141036.TAA24800@union.or.jp> To: mbone-jp@wide.ad.jp Subject: Sun FastEthernet Hi Mboners. I found ipmulticast release3.5 dose not work on SunOS4.1.4+JLE with SunFastEthernet(bqe). For the first thing, whata do I do about it? Please tell any information about it or if any,THE solution. Thanks advance... ----Next_Part(Sat_Nov_18_04:32:09_1995)---- From list-mgr@ISI.EDU Fri Nov 17 07:29:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21451>; Fri, 17 Nov 1995 11:31:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21388>; Fri, 17 Nov 1995 11:30:21 -0800 Received: from piglet.coe.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA21377>; Fri, 17 Nov 1995 11:30:06 -0800 Received: from focus.coe.missouri.edu (focus.coe.missouri.edu [128.206.59.187]) by piglet.coe.missouri.edu (8.7.1/8.7.1) with SMTP id NAA02907; Fri, 17 Nov 1995 13:29:09 -0600 (CST) Date: Fri, 17 Nov 1995 13:29:09 -0600 (CST) From: Mark Donnelly <mark@coe.missouri.edu> To: "Kyung Soon, Park" <sosarian@nuri.net> Cc: mbone Subject: Re: video conferencing hardware device In-Reply-To: <199511171112.UAA24222@sol.nuri.net> Message-Id: <Pine.SGI.3.91.951117132136.15788A-100000@focus.coe.missouri.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Is there any video conferencing hardware device on WIndows95 platform via MBONE? > Camera and video board like that. Well, I know of at least two other products that serve as hardware, although I don't know of any drivers written for them: 1. Pro Media Vision's Thunder board. Locally in Columbia, Mo. they're selling for about $99, so I know you can get a MUCH better deal elsewhere. 2. Connectix QuickCam. This is a camera that hooks up through your parallel port, but renders 360 x 240 (or thereabouts) frames. Currently they are B/W only, but the company says that when color comes out, the'll offer an upgrade path. A third alternative that has since been discontinued is the Intel video capture board. Intel came out with it about two or three years ago, which was way too early for the market. I know someone who's gotten at least 15 FPS, and I believe upwards of 30 FPS capture on it. Unfortunately, you can only find them used, they're expensive, and chances are that, even though they made ISA too, it might be microchannel. > I don't know any related product except Creative Lab's one. > How's Creative Lab's products? I've seen a demo in a store once, which looked decent, but I'm not sure that it can be converted. (I.E., the board advertised as one of those "TV in your computer" borads, but it had no capability for video capture, which may or may not be needed for MBone work.) --Mark "How may I be honest with you today?" Tuvok, ST:VOY From list-mgr@ISI.EDU Fri Nov 17 03:43:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22353>; Fri, 17 Nov 1995 11:45:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22284>; Fri, 17 Nov 1995 11:44:20 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA22269>; Fri, 17 Nov 1995 11:44:15 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15550(7)>; Fri, 17 Nov 1995 11:44:04 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Fri, 17 Nov 1995 11:43:53 -0800 To: yves@cc.mcgill.ca Cc: mbone Subject: Re: SD question In-Reply-To: Your message of "Fri, 17 Nov 95 10:52:31 PST." <199511171852.NAA23707@maelstrom.cc.mcgill.ca> Date: Fri, 17 Nov 1995 11:43:49 PST Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov17.114353pst.177478@crevenia.parc.xerox.com> In message <199511171852.NAA23707@maelstrom.cc.mcgill.ca> you write: >What is so different in SD advertisements from the ordinary mcast traffic that >SD can't share the port? Nothing. In fact, I have two programs running right now that receive the SD advertisements on the same machine. It's just the way the 'sd' application was written that causes this behavior. Bill From list-mgr@ISI.EDU Fri Nov 17 22:36:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25729>; Fri, 17 Nov 1995 12:43:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25372>; Fri, 17 Nov 1995 12:37:55 -0800 Received: from cismsun.univ-lyon1.fr by venera.isi.edu (5.65c/5.61+local-22) id <AA25364>; Fri, 17 Nov 1995 12:37:42 -0800 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id VAA28066; Fri, 17 Nov 1995 21:36:29 +0100 Message-Id: <199511172036.VAA28066@cismsun.univ-lyon1.fr> Subject: Re: Video coding question To: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Fri, 17 Nov 1995 21:36:28 +0100 (MET) From: "Lucia Gradinariu" <lucia@univ-lyon1.fr> Cc: mbone In-Reply-To: <4110.816629746@cs.ucl.ac.uk> from "Mark Handley" at Nov 17, 95 05:35:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 719 > > nv is currently giving 1-1.5fps at 128Kbps. My guess is that 2fps > H.261 would be considerably less bandwidth than 128Kbps, and would > still be decodable on sparc 2 class machines. > > Of course if you didn't limit the frame rate and set the bandwidth to > 128Kbps, then you may get high enough frame rates that you'd have > problems. Generally I reckon most boxes cope with "normal" size H.261 > up to about 4fps. If you've a *really* slow bow, then you can always > display the image small and/or greyscale which does help low powered > machines considerably. > I was convinced the choice of nv is a matter of image definition and image degradation with packet loss %. Lucia.Gradinariu@univ-lyon1.fr From list-mgr@ISI.EDU Fri Nov 17 23:55:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00776>; Fri, 17 Nov 1995 14:03:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00733>; Fri, 17 Nov 1995 14:02:42 -0800 Received: from basil.cdt.luth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA00720>; Fri, 17 Nov 1995 14:02:38 -0800 Received: from basil (localhost [127.0.0.1]) by basil.cdt.luth.se (8.6.12/8.6.12) with ESMTP id WAA05333; Fri, 17 Nov 1995 22:55:53 +0100 Message-Id: <199511172155.WAA05333@basil.cdt.luth.se> To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: Bill Fenner <fenner@parc.xerox.com>, Hakan Lennestal <hakanl@cdt.luth.se>, mbone Subject: Re: Video coding question In-Reply-To: Your message of "Fri, 17 Nov 1995 10:55:10 PST." <199511171855.KAA08491@rah.star-gate.com> Date: Fri, 17 Nov 1995 22:55:52 +0100 From: Hakan Lennestal <hakanl@cdt.luth.se> In message <199511171855.KAA08491@rah.star-gate.com>, "Amancio Hasty Jr." write s: > I see however how many people do we expect nowdays to have sparc 2 class > machines? > > Amancio I agree with your question. We are using a mixture of SS20 and SS5 machines locally on a constantly ongoing mbone session. The SS5 machines (75 Mhz) are able to both transmit and receive up to 15 f/s simultaneously (only one 1/4 NTSC screen at a time though). We are using h261 coding with VIC 2.7a27. Also, to be able to simultaneously send and receive with high frame rate, two instances of VIC has to be started. One for the transmission and one for the reception (otherwise will "packet-loss" occur). To my experience, assuming SS5-class machines as being the "low-end" would possibly allow h261 with 10 f/s (and 128kb/s) to be used. Regards. o /Hakan From list-mgr@ISI.EDU Fri Nov 17 10:37:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14161>; Fri, 17 Nov 1995 18:39:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14079>; Fri, 17 Nov 1995 18:38:24 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA14008>; Fri, 17 Nov 1995 18:38:18 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14463(2)>; Fri, 17 Nov 1995 18:38:04 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Fri, 17 Nov 1995 18:37:58 -0800 To: Yoshihiro Hirai <kool@union.or.jp> Cc: mbone Subject: Re: Forward: Sun FastEthernet In-Reply-To: Your message of "Fri, 17 Nov 95 11:32:18 PST." <199511171932.EAA11565@union.or.jp> Date: Fri, 17 Nov 1995 18:37:44 PST Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov17.183758pst.177478@crevenia.parc.xerox.com> In message <199511171932.EAA11565@union.or.jp> Yoshihiro Hirai wrote: >I found ipmulticast release3.5 dose not work on SunOS4.1.4+JLE with SunFastEth > ernet(bqe). What exactly doesn't work? I've only talked to one person who had tried 3.5 on a FastEthernet card, but he had it working no problem. Bill From list-mgr@ISI.EDU Fri Nov 17 12:27:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15718>; Fri, 17 Nov 1995 19:29:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15706>; Fri, 17 Nov 1995 19:29:02 -0800 Received: from atg.apple.com by venera.isi.edu (5.65c/5.61+local-22) id <AA15699>; Fri, 17 Nov 1995 19:28:59 -0800 Received: from [17.255.9.143] (jpallas.atg.apple.com [17.255.9.143]) by atg.apple.com (8.6.12/8.6.9) with SMTP id TAA01793; Fri, 17 Nov 1995 19:24:28 -0800 Message-Id: <v02130502acd2f4a80f77@[17.255.9.143]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Nov 1995 19:27:56 -0700 To: Hakan Lennestal <hakanl@cdt.luth.se>, "Amancio Hasty Jr." <hasty@rah.star-gate.com> From: Pallas@Apple.COM (Joe Pallas) Subject: Re: Video coding question Cc: Bill Fenner <fenner@parc.xerox.com>, Hakan Lennestal <hakanl@cdt.luth.se>, mbone At 10:55 PM 11/17/95, Hakan Lennestal wrote: >To my experience, assuming SS5-class machines as being the "low-end" >would possibly allow h261 with 10 f/s (and 128kb/s) to be used. Fine. What if we assume Quadra-class machines as being the "low-end"? joe -- Joe Pallas Apple Computer, Advanced Technology Group, Lab X From list-mgr@ISI.EDU Fri Nov 17 15:31:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15936>; Fri, 17 Nov 1995 19:33:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15900>; Fri, 17 Nov 1995 19:32:02 -0800 Received: from piglet.coe.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA15893>; Fri, 17 Nov 1995 19:31:59 -0800 Received: from most.coe.missouri.edu (most.coe.missouri.edu [128.206.59.186]) by piglet.coe.missouri.edu (8.7.1/8.7.1) with SMTP id VAA03996; Fri, 17 Nov 1995 21:31:37 -0600 (CST) Date: Fri, 17 Nov 1995 21:31:36 -0600 (CST) From: Tymm Twillman <tymm@tie.missouri.edu> X-Sender: tymm@most.coe.missouri.edu To: Mark Donnelly <mark@coe.missouri.edu> Cc: "Kyung Soon, Park" <sosarian@nuri.net>, mbone Subject: Re: video conferencing hardware device In-Reply-To: <Pine.SGI.3.91.951117132136.15788A-100000@focus.coe.missouri.edu> Message-Id: <Pine.SGI.3.91.951117212700.3171A-100000@most.coe.missouri.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Just thought I would point this out-- the Intel boards are still being made :)... The video capture board down in 109 is an Intel (It's a scaled down version of the one I have, but it's same idea)... and I *BELIEVE* that a few Action Media II boards are in production, although I'm not sure how many. Also, yes, capture would be neccessary for MBONE-ing. Most of the TV boards are just pass-through, and never actually digitize the video-- although I think Creative Labs has a "Video Blaster" or something which does work as a vieo capture card... but I'm not overly sure of that. Tymm On Fri, 17 Nov 1995, Mark Donnelly wrote: > > > Is there any video conferencing hardware device on WIndows95 platform via MBONE? > > Camera and video board like that. > > Well, I know of at least two other products that serve as hardware, > although I don't know of any drivers written for them: > > 1. Pro Media Vision's Thunder board. Locally in Columbia, Mo. they're > selling for about $99, so I know you can get a MUCH better deal elsewhere. > > 2. Connectix QuickCam. This is a camera that hooks up through your > parallel port, but renders 360 x 240 (or thereabouts) frames. Currently > they are B/W only, but the company says that when color comes out, > the'll offer an upgrade path. > > A third alternative that has since been discontinued is the Intel video > capture board. Intel came out with it about two or three years ago, > which was way too early for the market. I know someone who's gotten at > least 15 FPS, and I believe upwards of 30 FPS capture on it. > Unfortunately, you can only find them used, they're expensive, and > chances are that, even though they made ISA too, it might be microchannel. > > > I don't know any related product except Creative Lab's one. > > How's Creative Lab's products? > > I've seen a demo in a store once, which looked decent, but I'm not sure > that it can be converted. (I.E., the board advertised as one of those > "TV in your computer" borads, but it had no capability for video capture, > which may or may not be needed for MBone work.) > > > --Mark > > "How may I be honest with you today?" > Tuvok, ST:VOY > From list-mgr@ISI.EDU Fri Nov 17 13:44:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19533>; Fri, 17 Nov 1995 21:47:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19365>; Fri, 17 Nov 1995 21:45:34 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA19358>; Fri, 17 Nov 1995 21:45:33 -0800 Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id VAA01723; Fri, 17 Nov 1995 21:44:41 -0800 Message-Id: <199511180544.VAA01723@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Pallas@Apple.COM (Joe Pallas) Cc: Hakan Lennestal <hakanl@cdt.luth.se>, Bill Fenner <fenner@parc.xerox.com>, mbone Subject: Re: Video coding question In-Reply-To: Your message of "Fri, 17 Nov 1995 19:27:56 MST." <v02130502acd2f4a80f77@[17.255.9.143]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Nov 1995 21:44:35 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> >>> Joe Pallas said: > At 10:55 PM 11/17/95, Hakan Lennestal wrote: > >To my experience, assuming SS5-class machines as being the "low-end" > >would possibly allow h261 with 10 f/s (and 128kb/s) to be used. > > Fine. What if we assume Quadra-class machines as being the "low-end"? so how many frames per second can a Quadra-class machines handle for h.261? Amancio From list-mgr@ISI.EDU Sat Nov 18 04:39:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28238>; Sat, 18 Nov 1995 08:41:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28222>; Sat, 18 Nov 1995 08:40:03 -0800 Received: from piglet.coe.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA28215>; Sat, 18 Nov 1995 08:40:01 -0800 Received: from most.coe.missouri.edu (most.coe.missouri.edu [128.206.59.186]) by piglet.coe.missouri.edu (8.7.1/8.7.1) with SMTP id KAA04869; Sat, 18 Nov 1995 10:39:41 -0600 (CST) Date: Sat, 18 Nov 1995 10:39:41 -0600 (CST) From: Tymm Twillman <tymm@tie.missouri.edu> X-Sender: tymm@most.coe.missouri.edu To: Mark Donnelly <mark@coe.missouri.edu>, "Kyung Soon, Park" <sosarian@nuri.net>, mbone Subject: Re: video conferencing hardware device In-Reply-To: <Pine.SGI.3.91.951117212700.3171A-100000@most.coe.missouri.edu> Message-Id: <Pine.SGI.3.91.951118103523.4829A-100000@most.coe.missouri.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Whoops; I apologize. I was over-zealous in my reply-- the message was s'posed to just go to Mark. (Good thing it didn't concern any of my current scandals :) )... Anyhow, the info should be pretty accurate notwithstanding... -Tymm From list-mgr@ISI.EDU Sun Nov 19 13:26:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03161>; Sat, 18 Nov 1995 11:27:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03027>; Sat, 18 Nov 1995 11:27:07 -0800 Received: from union.or.jp (nyanya.union.or.jp) by venera.isi.edu (5.65c/5.61+local-22) id <AA03018>; Sat, 18 Nov 1995 11:27:02 -0800 Received: (from koji@localhost) by union.or.jp (8.7.1+2.6Wbeta4/3.4W-10/26/95) id EAA29315; Sun, 19 Nov 1995 04:26:41 +0900 (JST) Date: Sun, 19 Nov 1995 04:26:41 +0900 (JST) From: Takashi Kojima <koji@union.or.jp> Message-Id: <199511181926.EAA29315@union.or.jp> To: fenner@parc.xerox.com Cc: kool@union.or.jp, mbone In-Reply-To: <95Nov17.183758pst.177478@crevenia.parc.xerox.com> (message from Bill Fenner on Fri, 17 Nov 1995 18:37:44 PST) Subject: Re: Forward: Sun FastEthernet Thanks your reply. >>I found ipmulticast release3.5 dose not work on SunOS4.1.4+JLE with SunFastEth >> ernet(bqe). > >What exactly doesn't work? I've only talked to one person who had tried >3.5 on a FastEthernet card, but he had it working no problem. > > Bill My problem in some detail is; Usig ipmulticast release3.5 on SS5 110Mhz SunOS4.1.4JLE(Japanese Language Extention) After usual installation (multicast_install), our be interface was slowing down into a few Kb speed and our NFS went to death. We hard the rumour on SS5 SBus problem and there's some patches to FDDI drivers but not for be. That is my infomation over the thing. And if you can, please tell me the person who had tried 3.5 on a FastEthernet card. Thanks with respect to your remakable work. Takashi Kojima koji@union.or.jp From list-mgr@ISI.EDU Sat Nov 18 10:35:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13670>; Sat, 18 Nov 1995 18:48:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13329>; Sat, 18 Nov 1995 18:35:20 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA13322>; Sat, 18 Nov 1995 18:35:14 -0800 Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id SAA00274; Sat, 18 Nov 1995 18:35:01 -0800 Message-Id: <199511190235.SAA00274@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: mbone, rem-conf@es.net Subject: Jefferson Starship in Concert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Nov 1995 18:35:00 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Howdy, We are broacasting the Jefferson Starship Cybership Concert this Saturday starting at 20:00 PST it will probably last to about 1:15 Pacific Standard Time. Jefferson Starship Concert Broadcast out of San Francisco today Saturday starting at 8:00 Pacific Standard Time Session Cybership 224.2.195.92 ttl 127 audio@62693/11239 video@58671/40417 On behalf of Aimnet and I Have A Ball! Amancio Hasty Hasty Software Consulting Services Tel: 415-495-3046 Fax: 415-495-3046 Cellular: 415-309-8434 e-mail: hasty@star-gate.com Powered by FreeBSD From list-mgr@ISI.EDU Mon Nov 20 00:52:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07303>; Sun, 19 Nov 1995 14:53:46 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07287>; Sun, 19 Nov 1995 14:53:09 -0800 Received: from insanus.matematik.su.se by venera.isi.edu (5.65c/5.61+local-22) id <AA07280>; Sun, 19 Nov 1995 14:53:07 -0800 Received: from localhost (wizkids.matematik.su.se [130.237.198.20]) by insanus.matematik.su.se (8.7.1/8.6.9) with ESMTP id XAA20181; Sun, 19 Nov 1995 23:52:44 +0100 (MET) Message-Id: <199511192252.XAA20181@insanus.matematik.su.se> X-Address: Department of Mathematics, Stockholm University S-106 91 Stockholm SWEDEN X-Phone: int+46 8 162000 X-Fax: int+46 8 6126717 X-Url: http://www.matematik.su.se To: mbone, rem-conf@es.net Subject: Retransmissions from Stockholm Math Worshop Date: Sun, 19 Nov 1995 23:52:43 +0100 From: Leif Johansson <leifj@matematik.su.se> Hi Y'all, I will be broadcasting retransmissions from the Workshop on Remote Collaboration and Resource Sharing in Mathematics held in Stockholm on 23-29 of October, on the 20:th and 21:st of November from 20:00 GMT. Original scedules and abstracts can be found here: http://wizkids.matematik.su.se/users/leifj/workshop.html The format of the video will be vic. Best Regards Leif Johansson Phone: +46 8 164541 Department of Mathematics Fax : +46 8 6126717 Stockholm University email: leifj@matematik.su.se <This space is left blank for quotational and disclamatory purposes.> From list-mgr@ISI.EDU Mon Nov 20 13:06:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25191>; Mon, 20 Nov 1995 15:06:58 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25119>; Mon, 20 Nov 1995 15:06:11 -0800 Received: from aotearoa (aotearoa.sura.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA25107>; Mon, 20 Nov 1995 15:06:08 -0800 Received: from LOCALHOST.sura.net by aotearoa with SMTP (8.6.12/($Id: sendmail.cf,v 1.17 1991/02/11 14:07:23 jmalcolm Exp $)) id SAA10801; Mon, 20 Nov 1995 18:06:07 -0500 Message-Id: <199511202306.SAA10801@aotearoa> To: mbone Subject: Syslog message Date: Mon, 20 Nov 1995 18:06:07 -0500 From: Erik Sherk <sherk@sura.net> Hi, I noticed that when I reboot a Sun IPC running mrouted 3.6 (and SunOS 4.1.4) I get a whole bunch of the following messages: Nov 20 18:03:16 wtn-ms2 vmunix: ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket qu! eue full<4>ip_mforward: ip_mrouter socket q Nov 20 18:03:17 wtn-ms2 vmunix: ip_mforward: ip_mrouter socket queue full<4>ip_mforward: ip_mrouter socket queue full<4>ip_mforward Are they anything to worry about? After the initial flurry, they stop. Erik From list-mgr@ISI.EDU Mon Nov 20 08:32:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07356>; Mon, 20 Nov 1995 16:34:20 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07086>; Mon, 20 Nov 1995 16:32:59 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA07074>; Mon, 20 Nov 1995 16:32:56 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15607(4)>; Mon, 20 Nov 1995 16:32:45 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177478>; Mon, 20 Nov 1995 16:32:42 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: Erik Sherk <sherk@sura.net> Cc: mbone Subject: Re: Syslog message In-Reply-To: Your message of "Mon, 20 Nov 1995 15:06:07 PST." <199511202306.SAA10801@aotearoa> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Nov 1995 16:32:39 PST From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov20.163242pst.177478@crevenia.parc.xerox.com> In message <199511202306.SAA10801@aotearoa>you write: > I noticed that when I reboot a Sun IPC running mrouted 3.6 >(and SunOS 4.1.4) I get a whole bunch of the following messages: > >Nov 20 18:03:16 wtn-ms2 vmunix: ip_mforward: ip_mrouter socket queue full These messages are normal on startup and under heavy load. I am working on removing them from the startup case for version 3.7 . Bill From list-mgr@ISI.EDU Mon Nov 20 18:20:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20608>; Mon, 20 Nov 1995 20:24:46 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20590>; Mon, 20 Nov 1995 20:24:00 -0800 Received: from DIESEL.UTCC.UTK.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA20583>; Mon, 20 Nov 1995 20:23:58 -0800 Received: by diesel.utcc.utk.edu (5.x/2.7c-UTK) id AA14527; Mon, 20 Nov 1995 23:20:06 -0500 Date: Mon, 20 Nov 1995 23:20:05 -0500 (EST) From: Nair Venugopal <venu@utkux.utcc.utk.edu> X-Sender: venu@diesel.utcc.utk.edu To: mbone Subject: MBone question Message-Id: <Pine.SOL.3.91.951120231553.14440B-100000@diesel.utcc.utk.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, We encountered a weird problem during a local MBone broadcast today afternoon. 1) The session could be seen via "sd" in different subnets made IP-multicast capable via mrouted tunnels. 2) All subnets except the subnet containing the host sourcing the traffic could see *all* participants in the session. 3) The vat/nv running on the host sourcing the session could *not* see any other participants in the session. 4) The threshold on sourcing host's mrouted tunnel endpoints was 1. Would you know a possible cause to the problem? Could it be that one can get IGMP packets in the "sourcing" host's subnet, but no IP-in-IP packets? How can one fix this problem? Thanks --Venu -------------------------------------------------------------------------------- Nair Venugopal(Venu) Network Services Email: venu@utkux.utcc.utk.edu 2339 Dunford Hall, Knoxville TN-37996 Phone: (423) 974 6616 University of Tennessee, Knoxville From list-mgr@ISI.EDU Tue Nov 21 13:29:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03406>; Tue, 21 Nov 1995 05:34:21 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03365>; Tue, 21 Nov 1995 05:31:46 -0800 Received: from mailsun.aber.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA03357>; Tue, 21 Nov 1995 05:31:20 -0800 Received: from mailhost.aber.ac.uk (actually host saturn.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Tue, 21 Nov 1995 13:30:02 +0000 To: Bill Fenner <fenner@parc.xerox.com> Cc: elson@aeolus.jpl.nasa.gov (Lee Elson), mbone, dap@aber.ac.uk Subject: Re: multicast to unicast audio In-Reply-To: Your message of Fri, 17 Nov 1995 09:13:20 -0800. <95Nov17.091326pst.177478@crevenia.parc.xerox.com> Date: Tue, 21 Nov 1995 13:29:39 +0000 Message-Id: <4670.816960579@mailhost.aber.ac.uk> From: D E PRICE <dap@aber.ac.uk> Dear Bill and all, I now find myself needing to handle a machine with unicast only where I need to relay that into multicast for both video and audio. I understand how to do the audio (vat -m as in previous emails etc), but how can I do the Video ??? Thanks Folks, Dave Price From list-mgr@ISI.EDU Tue Nov 21 15:08:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06557>; Tue, 21 Nov 1995 07:14:14 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06529>; Tue, 21 Nov 1995 07:13:11 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA06519>; Tue, 21 Nov 1995 07:12:52 -0800 Received: from mailhost.lut.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA02758>; Tue, 21 Nov 1995 07:12:51 -0800 Received: (jon@localhost) by weeble.lut.ac.uk (8.6.12/8.6.9) id PAA23347; Tue, 21 Nov 1995 15:08:58 GMT Date: Tue, 21 Nov 1995 15:08:57 +0000 (GMT) From: Jon Knight <J.P.Knight@lut.ac.uk> To: D E PRICE <dap@aber.ac.uk> Cc: Bill Fenner <fenner@parc.xerox.com>, Lee Elson <elson@aeolus.jpl.nasa.gov>, mbone, dap@aber.ac.uk Subject: Re: multicast to unicast audio In-Reply-To: <4670.816960579@mailhost.aber.ac.uk> Message-Id: <Pine.SUN.3.91.951121150434.7133r-100000@weeble.lut.ac.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 21 Nov 1995, D E PRICE wrote: > I now find myself needing to handle > a machine with unicast only where I need to > relay that into multicast for both video > and audio. > > I understand how to do the audio (vat -m as in previous emails etc), > but how can I do the Video ??? Personally I used Jon Crowcroft's neat little hack called ``monstermash'' (I've had a copy up at <URL:ftp://agate.lut.ac.uk/pub/mbone/monstermash.c> for ages and I'd guess you'll be able to find it at other sites as well). This is a generic multicast relay program that takes a multicast stream on an arbitrary <address,port> pair and relays it to and from a unicast stream on another <address,port> pair. Its one of those really handy little tools that should be in any multicast experimenters toolbox and Jon Crowcroft deserves a nice little packet of kudos for writing it. :-) Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Researcher, Sysop and General Dogsbody, Department of Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * From list-mgr@ISI.EDU Tue Nov 21 07:28:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07201>; Tue, 21 Nov 1995 07:32:06 -0800 Received: from cythera.unb.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA07194>; Tue, 21 Nov 1995 07:32:03 -0800 Received: from cythera.unb.ca (cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.6.12/8.6.5) with SMTP id LAA18087; Tue, 21 Nov 1995 11:28:23 -0400 Newsgroups: rec.music.classical Date: Tue, 21 Nov 1995 11:28:11 -0400 (AST) From: "Dwight E. Spencer" <spencer@unb.ca> To: rem-conf@es.net Cc: mbone-na, atlanted@unb.ca, newmedia@unb.ca, lex-l@unb.ca, cnet@unb.ca, cnetadmin@cythera.unb.ca, Allyn.Romanow@Eng.Sun.COM, "Brian O'Shea" <boshea@wpine.com>, cu-seeme-l@cornell.edu Subject: Symphony Broadcast on Mbone, simulcast on CUSM. Message-Id: <Pine.SOL.3.91.951121105744.11739S-100000@cythera.unb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII (sorry to those who get multiple copies...) The Saint John String Quartet is performing this Thurday (November 23rd) at the Christ Church Cathedral, in downtown Fredericton, NB, Canada. With the help of many members of the community, we are pleased to announce that we will be able to broadcast this concert LIVE on the mbone as well as to CUSM clients via a cusm reflector running at sol.csd.unb.ca. Broadcast time is 4:00pm PST, 8:00pm AST(local), Midnight GMT. We hope as many people as possible will drop in to see this Thursday evening. Please contact Steve Sloan (sloan@unb.ca) or myself (spencer@unb.ca) for more details, or see the URL http://www.lib.unb.ca/sjsq/ I will be broadcasting to the mbone with nv (cuseeme encoding, 70kbps) and vat. I will be also broadcasting it to the cusm reflector. You can download cusm clients at ftp://gated.cornell.edu/ or ftp://ftp.wpine.com/ Many thanks to those involved: Brunswick Micro NBTel UNB Libraries Community Access Canada Symphony New Brunswick American Federation of Musicians Sun Microsystems UNB Computing Services Saint John String Quartet Dean Wright of Christ Church Cathedral Dwight Spencer ---------------------------------------------------------------------------- Dwight E. Spencer Canada's Community Access Network eMail: spencer@unb.ca, Server Administrator UNB, Fredericton, NB, Canada Phone: +1 506 447 3153 Url: http://cnet.unb.ca/cspace/staff/dspencer/ From list-mgr@ISI.EDU Tue Nov 21 18:09:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08516>; Tue, 21 Nov 1995 08:10:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08488>; Tue, 21 Nov 1995 08:09:23 -0800 Received: from pat.uio.no by venera.isi.edu (5.65c/5.61+local-22) id <AA08477>; Tue, 21 Nov 1995 08:09:19 -0800 Received: from ulrik.uio.no by pat.uio.no with local-SMTP (PP) id <00475-0@pat.uio.no>; Tue, 21 Nov 1995 17:09:11 +0100 Received: from monet by monet.uio.no ; Tue, 21 Nov 1995 16:09:09 GMT Message-Id: <199511211609.QAA03808@monet.uio.no> X-Mailer: exmh version 1.6.2 7/18/95 To: mbone Subject: Mbone topology Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 1995 17:09:08 +0100 From: Gorm Haug Eriksen <g.h.eriksen@usit.uio.no> Dear All, Two questions : 1.) Someone know of a newer MBONE backbone map than: http://sauce.uio.no/mice-nsc/MBONE.gif (1995 is prefered). 2.) Someone got sets of data or plots that describe the history of MBONE (# of routers, traffic e.t.c.). Thanks in advance for any help. - Gorm From list-mgr@ISI.EDU Tue Nov 21 00:53:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10543>; Tue, 21 Nov 1995 08:55:20 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10515>; Tue, 21 Nov 1995 08:54:39 -0800 Received: from mercury.Sun.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA10508>; Tue, 21 Nov 1995 08:54:37 -0800 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id IAA00575; Tue, 21 Nov 1995 08:54:36 -0800 Received: from caribe.eng.sun.com (caribe-85.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25617; Tue, 21 Nov 1995 08:54:33 -0800 Received: from encryption.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA14534; Tue, 21 Nov 1995 08:54:22 -0800 Received: by encryption.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00550; Tue, 21 Nov 1995 08:53:52 -0800 Date: Tue, 21 Nov 1995 08:53:52 -0800 From: sangeeta@caribe-86.Eng.Sun.COM (Sangeeta Muhkerjee) Message-Id: <199511211653.IAA00550@encryption.eng.sun.com> To: mbone Subject: Add me to the mailing list Cc: allyn@offshore.Eng.Sun.COM X-Sun-Charset: US-ASCII Kindly add me to this mailing list Thanks, Sangeeta From list-mgr@ISI.EDU Tue Nov 21 02:00:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14605>; Tue, 21 Nov 1995 10:16:15 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14522>; Tue, 21 Nov 1995 10:14:16 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA14515>; Tue, 21 Nov 1995 10:14:11 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15687(2)>; Tue, 21 Nov 1995 10:01:01 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177478>; Tue, 21 Nov 1995 10:00:54 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: Nair Venugopal <venu@utkux.utcc.utk.edu> Cc: mbone Subject: Re: MBone question In-Reply-To: Your message of "Mon, 20 Nov 1995 20:20:05 PST." <Pine.SOL.3.91.951120231553.14440B-100000@diesel.utcc.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 1995 10:00:41 PST From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov21.100054pst.177478@crevenia.parc.xerox.com> In message <Pine.SOL.3.91.951120231553.14440B-100000@diesel.utcc.utk.edu>you wr ite: >2) All subnets except the subnet containing the host sourcing the traffic > could see *all* participants in the session. > >3) The vat/nv running on the host sourcing the session could *not* see > any other participants in the session. Can a that host see, for example, 'sd' sessions for other groups, or participants in MBONE Audio? I'd need a more complete description of the topology and the situation (and hopefully to be able to capture it in action) to be able to help debug this. Bill From list-mgr@ISI.EDU Tue Nov 21 03:33:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19575>; Tue, 21 Nov 1995 11:37:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19400>; Tue, 21 Nov 1995 11:33:39 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA19391>; Tue, 21 Nov 1995 11:33:38 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15744(7)>; Tue, 21 Nov 1995 11:33:22 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 21 Nov 1995 11:33:07 -0800 To: mbone, idmr@cs.ucl.ac.uk Cc: dino@cisco.com, deering@parc.xerox.com Subject: MBone Engineering BOF in Dallas Date: Tue, 21 Nov 1995 11:33:01 PST Sender: Steve Deering <deering@parc.xerox.com> From: Steve Deering <deering@parc.xerox.com> Message-Id: <95Nov21.113307pst.75270@digit.parc.xerox.com> [This message is being sent to both the mbone and idmr mailing lists; please post any follow-ups to the mbone list only.] An MBone Engineering BOF has been scheduled for the Dallas IETF, on Monday evening from 7:30 to 10:00. It will be chaired by Steve Deering and Dino Farinacci. The purpose of the BOF is: (1) to identify what problems need to be addressed and what steps need to be taken to evolve the current "experimental" MBone infrastructure into a ubiquitously-available, "native" IP multicast service in the Internet, (2) to learn the status of current and planned solutions to the outstanding problems, and (3) to begin planning for the deployment of those solutions. Like any IETF BOF, anyone is welcome to attend, but we particularly solicit participation by Internet service providers and IP multicast implementors. We invite ISPs to give brief (5 minute) presentations on what they see as the issues and obstacles to deployment of native multicast in their networks, and we invite implementors of IP multicast infrastructure technology (e.g., routing protocols, management and diagnostic tools, traffic management algorithms) to give brief (5 minute) status reports on their implementations. The BOF will be 'cast on the MBone (of course) to try to enable participation by those who cannot attend in person. Here is a tentative agenda; if you have any changes or additions to suggest, or if you are willing to give a presentation, please send mail to deering@parc.xerox.com and dino@cisco.com. o ISP presentations -- possible issues/topics: - ISP plans for / experiments with native multicast - un-met software requirements - routing, mgmt tools, etc. - need for hardware upgrades? - traffic management/congestion concerns - bandwidth availability forecasts - vulnerability to misconfiguration, "storms", etc. - other? o status reports on management and debugging tools - multicast debugging architecture - Van Jacobson - SNMP support for multicast - Dave Thaler - multicast traceroute - Bill Fenner - IGMP-based router info messages - Bill Fenner - other? o status reports on multicast routing implementations - 3Com - ?? - Bay - ?? - cisco - Dino Farinacci - PARC - Bill Fenner and/or Steve Deering - USC - ?? - SGI? Sun? Digital? UCL? Alantec? other? o status reports on multicast traffic management mechanisms (for best-efforts traffic only, i.e., excluding resource reservation approaches, which are being addressed in other forums) - multicast rate limits and priority dropping - Deering - administrative scope control - Jacobson? - RED? - other? o next steps for growing/improving the MBone - replacing tunnels with native multicast forwarding wherever possible. - using DVMRP routing through transit PIM clouds. - using route aggregation and default routes in DVMRP. - scheduling an "MBone re-engineering week", during which no one is allowed to complain that the MBone isn't working. - configuring administrative scope boundaries around all organizations, and change sd, etc. to allocate appropriately-scoped group addresses. - banning the use of multicast routing implementations that don't correctly support pruning, mtrace, and longest-match routing, e.g., pre-3.3 mrouted kernels and pre-3.5 mrouted demons. - raising the 500 Kbps MBone bandwidth ceiling. - ... Steve & Dino From list-mgr@ISI.EDU Tue Nov 21 21:41:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26501>; Tue, 21 Nov 1995 13:43:00 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26338>; Tue, 21 Nov 1995 13:42:03 -0800 Received: from mailsun.aber.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA26325>; Tue, 21 Nov 1995 13:42:00 -0800 Received: from mailhost.aber.ac.uk (actually host manuel.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Tue, 21 Nov 1995 21:41:16 +0000 To: Jon Knight <J.P.Knight@loughborough.ac.uk> Cc: D E PRICE <dap@aber.ac.uk>, Bill Fenner <fenner@parc.xerox.com>, Lee Elson <elson@aeolus.jpl.nasa.gov>, mbone, dap@aber.ac.uk Subject: Re: multicast to unicast audio In-Reply-To: Your message of Tue, 21 Nov 1995 15:08:57 +0000. <Pine.SUN.3.91.951121150434.7133r-100000@weeble.lut.ac.uk> Date: Tue, 21 Nov 1995 21:41:11 +0000 Message-Id: <2091.816990071@mailhost.aber.ac.uk> From: D E PRICE <dap@aber.ac.uk> Dear Jon et al., I appear to be acting rather brain dead tonight.... I have now recovered `monstermash' and I have compiled it fine. It can get it to run, but I can't for the life of me actually understand precisely what I have to supply as parameters to achieve what I want...... As a test, I attempted to forward an incoming multicast to a unicast only host..... nothing arrived.... (Actually I really want to use monstermash the other way round, .....) can someone supply any example sets of parameters for monstermash to use in the specfic cases of 1). interworking VIC multicast <-> unicast using monstermash and 2). interworking VAT multicast <-> unicast Thanks folks.... Dave Price From list-mgr@ISI.EDU Wed Nov 22 00:12:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04414>; Tue, 21 Nov 1995 16:14:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04382>; Tue, 21 Nov 1995 16:13:16 -0800 Received: from mailhost.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA04372>; Tue, 21 Nov 1995 16:13:09 -0800 Received: (jon@localhost) by weeble.lut.ac.uk (8.6.12/8.6.9) id AAA25434; Wed, 22 Nov 1995 00:12:26 GMT Date: Wed, 22 Nov 1995 00:12:25 +0000 (GMT) From: Jon Knight <J.P.Knight@lut.ac.uk> To: D E PRICE <dap@aber.ac.uk> Cc: Bill Fenner <fenner@parc.xerox.com>, Lee Elson <elson@aeolus.jpl.nasa.gov>, mbone, dap@aber.ac.uk Subject: Re: multicast to unicast audio In-Reply-To: <2091.816990071@mailhost.aber.ac.uk> Message-Id: <Pine.SUN.3.91.951122000536.7133D-100000@weeble.lut.ac.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 21 Nov 1995, D E PRICE wrote: > I appear to be acting rather brain dead tonight.... > I have now recovered `monstermash' and I have compiled it fine. > It can get it to run, but I can't for the life of me actually > understand precisely what I have to supply as parameters > to achieve what I want...... As a test, I attempted to forward > an incoming multicast to a unicast only host..... nothing > arrived.... (Actually I really want to use monstermash > the other way round, .....) Here's an example that I've used in the past for relaying Radio Free VAT audio. The machine it was running on was a Sun running SunOS 4.1.3U1B with multicast extensions with an IP address of 158.125.220.7. The multicast address is 224.2.253.119, port 42147 and the unicast address was 131.231.224.22, port 3456, multicast TTL is 191: monstermash -T191 -r42147 -t3456 -b1024 "131.231.224.22 3456" "224.2.253.119 158.125.220.7.0" (incidentally that should be all on one line - I split it for readability). VAT takes two monstermashes to relay (one for the audio and one for the user info). With nv I used one monstermash just for the video and I guess that it would work with vic as well (though I've not had occasion to try the latter yet). Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Researcher, Sysop and General Dogsbody, Department of Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * From list-mgr@ISI.EDU Tue Nov 21 09:15:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07550>; Tue, 21 Nov 1995 17:20:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07266>; Tue, 21 Nov 1995 17:16:12 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA07254>; Tue, 21 Nov 1995 17:16:06 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15663(2)>; Tue, 21 Nov 1995 17:15:56 PST Received: by crevenia.parc.xerox.com id <177478>; Tue, 21 Nov 1995 17:15:53 -0800 From: Bill Fenner <fenner@parc.xerox.com> To: mbone, multicast-beta@cisco.com Subject: Black holes caused by aggregation Message-Id: <95Nov21.171553pst.177478@crevenia.parc.xerox.com> Date: Tue, 21 Nov 1995 17:15:44 PST [This list is growing awfully fast!] As I described in a message to the MBONE mailing list in October, injecting both a general route and more-specific routes will cause black holes for traffic originating from hosts that are covered by the more specific routes. What follows is a list of networks that are affected by this problem. The responsible people for these networks should either: a) Configure whatever router is injecting the general route to only inject specific routes b) Configure your topology in such a way that you can configure a single router to inject a single general route without requiring any more-specific routes. The problem can also be caused by mis-configuration of interface netmasks; this generally affects unicast connectivity as well. The solution in this case is to either configure the interface's netmask properly or use the 'phyint netmask' command in your mrouted.conf. As I said before, of course, the proper solution is to get the MBONE to support longest-match routing; however, mrouted versions previous to 3.5 do not support longest-match routing and will cause black holes. Bill University of California (NET-UCB-ETHER) EECS Division 573 Evans Hall Berkeley, CA 94720 128.32.226/24 is covered by 128.32/16 orwegian Telecommunications Administration (NET-NTANET) P.O. Box 83 N-2007 Kjeller NORWAY 128.39.88/23 is covered by 128.39/16 128.39.157/24 is covered by 128.39/16 128.39.197/24 is covered by 128.39/16 SURANET (NET-SURA-B) 128.167.1/24 is covered by 128.167/16 128.167.254/24 is covered by 128.167/16 University of Illinois, CCSO (NET-UIUC-CAMPUS-B) 1304 West Springfield Avenue Urbana, IL 61801-2910 US 128.174.212.0/25 is covered by 128.174/16 128.174.240/24 is covered by 128.174/16 National Institutes of Health (NET-NIH-NET) 9000 Rockville Pike Bethesda, MD 20892 128.231.76/23 is covered by 128.231/16 128.231.128/23 is covered by 128.231/16 Continuous Electronic Beam Accelerator Facility (SURA/CEBAF) (NET-CEBAF) 12000 Jefferson Avenue Newport News, VA 23606 129.57.32/22 is covered by 129.57/16 Tohoku University (NET-TAINS) Katahira, Aoba-Ku, Sendai 980-77 Japan 130.34.6/24 is covered by 130.34/16 130.34.8/24 is covered by 130.34/16 130.34.10/24 is covered by 130.34/16 130.34.18/24 is covered by 130.34/16 130.34.64/24 is covered by 130.34/16 130.34.78/24 is covered by 130.34/16 130.34.82/24 is covered by 130.34/16 130.34.104/24 is covered by 130.34/16 130.34.120/24 is covered by 130.34/16 130.34.227/24 is covered by 130.34/16 RedIRIS (NET-IRIS) RedIRIS/CSIC Serrano 142 28006 Madrid SPAIN 130.206.0/23 is covered by 130.206/16 130.206.16/24 is covered by 130.206/16 130.206.34/24 is covered by 130.206/16 130.206.35/24 is covered by 130.206/16 130.206.36/24 is covered by 130.206/16 130.206.45/24 is covered by 130.206/16 130.206.46/24 is covered by 130.206/16 130.206.47/24 is covered by 130.206/16 130.206.48/24 is covered by 130.206/16 130.206.63/24 is covered by 130.206/16 130.206.121/24 is covered by 130.206/16 130.206.122/24 is covered by 130.206/16 130.206.123/24 is covered by 130.206/16 130.206.124/24 is covered by 130.206/16 130.206.125/24 is covered by 130.206/16 130.206.126/24 is covered by 130.206/16 130.206.193/24 is covered by 130.206/16 California Institute of Technology (NET-CALTECH-NET) Pasadena, CA 91125 131.215.58.2/32 is covered by 131.215.58/24 McGill University (NET-MCGILL-CA) Computing Centre 805 Sherbrooke Street West Montreal, Quebec H3A 2K6 CANADA 132.206.3/24 is covered by 132.206/16 132.206.35/24 is covered by 132.206/16 132.206.141/24 is covered by 132.206/16 132.206.186/24 is covered by 132.206/16 Jet Propulsion Laboratory (NET-JPL-NET2) Communications and Computing Network Services Section 4800 Oak Grove Drive Pasadena, CA 91109 137.78.32/24 is covered by 137.78/16 137.78.80.0/25 is covered by 137.78/16 137.78.80.128/25 is covered by 137.78/16 137.78.96/24 is covered by 137.78/16 137.78.160/24 is covered by 137.78/16 137.78.250/24 is covered by 137.78/16 137.78.252/24 is covered by 137.78/16 Telecom Paris (NET-FNET-ESNET) Centre de Calcul 46, rue Barrault 75634 Paris Cedex 13 FRANCE 137.194.2/23 is covered by 137.194/16 137.194.34/23 is covered by 137.194/16 137.194.98/23 is covered by 137.194/16 137.194.160/23 is covered by 137.194/16 137.194.224/23 is covered by 137.194/16 137.194.230/23 is covered by 137.194/16 137.194.232/23 is covered by 137.194/16 NASA/Johnson Space Center (NET-JIN) Mail Code FD32 Houston, TX 77058 139.169.162/24 is covered by 139.169/16 The Little Garden (NET-LITTLEGARDEN) Box 410923 San Francisco, CA 94141-0923 140.174.2/24 is covered by 140.174/16 140.174.97.0/25 is covered by 140.174/16 LSI Logic Corporation (NET-LSIL) 1501 McCarthy Boulevard Milpitas, CA 95035 147.145.44/24 is covered by 147.145/16 National Institutes of Health (NET-NIHNET-3) Computer Center National Institute of Health Building 12, Room 2244 Bethesda, MD 20892 156.40.112/23 is covered by 156.40/16 National Institute of Environmental Health Sciences (NET-NIEHS2) 111 Alexander Drive Research Triangle Park, NC 27709 157.98.8/21 is covered by 157.98/16 Fraunhofer Institut fuer graphische Datenverarbeitung, Darmstadt (NETBLK-FHGIGDP) Fraunhofer-Strasse 1 D-76131 Karlsruhe Germany DE 192.67.203.128/27 is covered by 192.67.203/24 inetnum: 202.232.121.0 - 202.232.121.31 netname: SHIN-NET-JP descr: (Yoshimura, Shin) descr: 1-4, Sanbancho, Chiyoda-ku, Tokyo, country: JP admin-c: SY001JP-JP tech-c: SY001JP-JP notify: db-staff@nic.ad.jp mnt-by: MAINT-JPNIC changed: db-staff@nic.ad.jp 951018 source: JPNIC 202.232.121.0/28 is covered by 202.232.121/24 From list-mgr@ISI.EDU Tue Nov 21 13:17:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07597>; Tue, 21 Nov 1995 17:21:21 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07574>; Tue, 21 Nov 1995 17:20:38 -0800 Received: from dfw.net by venera.isi.edu (5.65c/5.61+local-22) id <AA07563>; Tue, 21 Nov 1995 17:20:36 -0800 Received: by dfw.net (4.1/SMI-4.1) id AA00639; Tue, 21 Nov 95 19:17:44 CST Date: Tue, 21 Nov 1995 19:17:43 -0600 (CST) From: Aleph One <aleph1@dfw.net> To: mbone Subject: Solaris 2.5 and Mrouted Message-Id: <Pine.SUN.3.90.951121191232.360A-100000@dfw.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sorry if this is been touched upon but I could not find it in the archives. I would like to install mrouted under Solaris 2.5 BETA. I could find is the package on playground.sun.com for 2.4 with mrouted 3.6 and kernel 3.5. There is a small note in the readme saying that "Multicast 3.5/3.6 for Solaris 3.5 (sic) is not yet available, but will be." I was wondering if there was a timeframe for this and if not can an mrouted other than 3.6 be used? Thanx in advance. Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 From list-mgr@ISI.EDU Tue Nov 21 12:17:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13110>; Tue, 21 Nov 1995 20:19:35 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12946>; Tue, 21 Nov 1995 20:17:29 -0800 Received: from medoc.CS.Berkeley.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA12938>; Tue, 21 Nov 1995 20:17:26 -0800 Received: from medoc.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by medoc.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id UAA14674; Tue, 21 Nov 1995 20:17:23 -0800 From: Eric Paulos <paulos@CS.Berkeley.EDU> Message-Id: <199511220417.UAA14674@medoc.CS.Berkeley.EDU> To: rem-conf@es.net, rem-conf-request@es.net Cc: mbone Subject: MBONE Reservation request: Nov 24, 25, or 26 Date: Tue, 21 Nov 1995 20:17:22 -0800 Survival Research Laboratories (SRL) is planning an MBONE presentation of their upcoming large scale "Crime Wave" show. This show will revolve around the many aspects of violent human interaction. This will be the first large scale SRL performance since the May 1994 show, "A Calculated Forecast Of Ultimate Doom". The "Crime Wave" show will take place either November 24 (Friday), 25 (Saturday), or 26 (Sunday). Exact notification of the time of day and location will not be released until necessary. To avoid regulatory difficulties, arrangements will be sneakier than usual. This will also apply to how we will be notifying the public. By nature SRL shows must happen without much warning to avoid alerting various official personal. For that reason we are remaining vague about the exact date and time of the show. As the show date approaches, we will be more specific via the WWW site mentioned below. Seeing as there are no other events scheduled during this three day time frame, we do not expect any conflicts or problems. If anyone has a conflicting event, please contact me, Eric Paulos (paulos@cs.berkeley.edu), so that we can resolve the scheduling issues. I apologize for the late announcement and the vagueness of the date but our group must be somewhat secretive to avoid confrontation with various official personal. Survival Research Laboratories was conceived of and founded by Mark Pauline in November 1978. Since its inception SRL has operated as an organization of creative technicians dedicated to re-directing the techniques, tools, and tenets of industry, science, and the military away from their typical manifestations in practicality, product or warfare. Since 1979, SRL has staged over 45 mechanized presentations in the United States and Europe. Each performance consists of a unique set of ritualized interactions between machines, robots, and special effects devices, employed in developing themes of socio-political satire. Humans are present only as audience or operators. More information about SRL can be found at the WWW site below: http://robotics.eecs.berkeley.edu/SRL/ The show will be broadcast out of the San Francisco Bay Area. More detailed and up to date information about the multicast can be found at the following location: http://robotics.eecs.berkeley.edu/SRL/live.html SRL would like to reserve MBONE bandwidth for one live video and audio steam. The performance will occur during one of the following times: Date Time (PST) Time (GMT) Event -------------------------------------------------------------------- 24 Nov 95 17:00-23:00 1:00-7:00* SRL Live Performance 25 Nov 95 17:00-23:00 1:00-7:00* SRL Live Performance 26 Nov 95 17:00-23:00 1:00-7:00* SRL Live Performance *GMT is on next day This information has also been inserted into the session director (sd) and posted to the MBONE Broadcast Schedule: http://www.msri.org:80/mbone/ Eric Paulos paulos@cs.berkeley.edu From list-mgr@ISI.EDU Wed Nov 22 10:58:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21524>; Wed, 22 Nov 1995 01:07:01 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21422>; Wed, 22 Nov 1995 01:05:54 -0800 Received: from arco.na.cnr.it ([140.164.1.1]) by venera.isi.edu (5.65c/5.61+local-22) id <AA21342>; Wed, 22 Nov 1995 01:04:49 -0800 Received: from cps.na.cnr.it ([140.164.14.3]) by arco.na.cnr.it (5.65c+/1.34) id AA07999; Wed, 22 Nov 1995 10:01:50 -0500 Received: by cps.na.cnr.it (4.1/SMI-4.1) id AA08218; Wed, 22 Nov 95 09:58:52 +0100 Date: Wed, 22 Nov 95 09:58:52 +0100 From: canonico@cps.na.cnr.it (Roberto Canonico) Message-Id: <9511220858.AA08218@cps.na.cnr.it> To: mbone Subject: A question for tcpdumpers Hi everybody, I've got a little question for tcpdump users: - Is it possible to use tcpdump to measure how many IP packets per second arrive from an ATM board? I tried to listen on an ATM interface (fa0) but tcpdump didn't recognize the incoming IP packets. Is there any other useful tool able to catch IP traffic from an ATM interface? Thanks for any suggestion. Roberto -------------------------------------------------------------------------- Roberto Canonico Universita' degli Studi di Napoli "Federico II" - Italy email: canonico@cps.cps.na.cnr.it canonico@capri.dis.unina.it -------------------------------------------------------------------------- From list-mgr@ISI.EDU Wed Nov 22 09:30:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22249>; Wed, 22 Nov 1995 01:35:30 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22212>; Wed, 22 Nov 1995 01:33:33 -0800 Received: from mailsun.aber.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA22205>; Wed, 22 Nov 1995 01:33:30 -0800 Received: from mailhost.aber.ac.uk (actually host saturn.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Wed, 22 Nov 1995 09:30:51 +0000 To: Jon Knight <J.P.Knight@loughborough.ac.uk> Cc: D E PRICE <dap@aber.ac.uk>, Bill Fenner <fenner@parc.xerox.com>, Lee Elson <elson@aeolus.jpl.nasa.gov>, mbone, dap@aber.ac.uk Subject: Re: multicast to unicast audio In-Reply-To: Your message of Wed, 22 Nov 1995 00:12:25 +0000. <Pine.SUN.3.91.951122000536.7133D-100000@weeble.lut.ac.uk> Date: Wed, 22 Nov 1995 09:30:37 +0000 Message-Id: <67.817032637@mailhost.aber.ac.uk> From: D E PRICE <dap@aber.ac.uk> Dear Jon, Well the `global problem solver' is working well tonight...... I now have lots of suggestions etc.... For VAT, is the `user info'' just on the next port upwards in number ?? Thanks dave From list-mgr@ISI.EDU Wed Nov 22 13:48:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22782>; Wed, 22 Nov 1995 01:56:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22728>; Wed, 22 Nov 1995 01:51:53 -0800 Received: from proge.ml.tele.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA22713>; Wed, 22 Nov 1995 01:51:18 -0800 Received: (from mit@localhost) by proge.ml.tele.fi (8.7.1/8.7.1) id LAA10542; Wed, 22 Nov 1995 11:48:47 +0200 (EET) Date: Wed, 22 Nov 1995 11:48:47 +0200 (EET) Message-Id: <199511220948.LAA10542@proge.ml.tele.fi> From: Mikko Tsokkinen <mit@ml.tele.fi> To: canonico@cps.na.cnr.it (Roberto Canonico) Cc: mbone Subject: A question for tcpdumpers In-Reply-To: <9511220858.AA08218@cps.na.cnr.it> References: <9511220858.AA08218@cps.na.cnr.it> Roberto Canonico writes: > > Hi everybody, > > I've got a little question for tcpdump users: > > - Is it possible to use tcpdump to measure how many IP packets per second > arrive from an ATM board? > > I tried to listen on an ATM interface (fa0) but tcpdump didn't recognize > the incoming IP packets. Is there any other useful tool able to catch IP > traffic from an ATM interface? Most of the general dumpers, snoopers and statters usually cause problems with the ATM-boards that I have experience with. In the wosrt case the crash to whole machine, less severe bugs are just printing out totally useless random data or nothing. fa0 is the interface name for Fore's boards, they have their own dumper in Sunos, if remember correctly it is /usr/fore/etc/atmstat or whereever you have installed their package. If you are using some other machine besides Sun I don't know whether this will apply to you or not. Most of the report programs that I have experience with print out incorrect values e.g. too high/low bitrate or packet count. IMHO the only way to find out what is really going into/out of any interface is a reliable network analyzer. Mikko I. Tsokkinen xxxxx Mit <Mikko.Tsokkinen@tele.fi> R & D Engineer Telecom Finland Ltd./Telegate/Medialaboratory From list-mgr@ISI.EDU Wed Nov 22 12:17:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23502>; Wed, 22 Nov 1995 02:19:55 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23318>; Wed, 22 Nov 1995 02:17:32 -0800 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA23311>; Wed, 22 Nov 1995 02:17:29 -0800 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id LAA29840; Wed, 22 Nov 1995 11:14:41 +0100 Message-Id: <199511221014.LAA29840@piraya.electrum.kth.se> To: canonico@cps.na.cnr.it (Roberto Canonico) Cc: mbone, e93_mda@it.kth.se Subject: Re: A question for tcpdumpers In-Reply-To: Your message of "Wed, 22 Nov 1995 09:58:52 +0100." <9511220858.AA08218@cps.na.cnr.it> Date: Wed, 22 Nov 1995 11:17:08 +0100 From: Magnus <e93_mda@it.kth.se> If your ATM card is named fa0 could it possibly be a Fore card? Then you should examine the atmstat tool (aswell as the other tools that comes with their drivers). These tools will usually give a rather good picture on what is happening with your packets. Use the latest Fore software 3.01(1.28). Magnus From list-mgr@ISI.EDU Wed Nov 22 10:28:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23853>; Wed, 22 Nov 1995 02:33:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23836>; Wed, 22 Nov 1995 02:31:14 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA23828>; Wed, 22 Nov 1995 02:31:08 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA18240>; Wed, 22 Nov 1995 02:31:06 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.07649-0@bells.cs.ucl.ac.uk>; Wed, 22 Nov 1995 10:28:37 +0000 From: Mark Handley <M.Handley@cs.ucl.ac.uk> X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: D E PRICE <dap@aber.ac.uk> Cc: Jon Knight <J.P.Knight@loughborough.ac.uk>, Bill Fenner <fenner@parc.xerox.com>, Lee Elson <elson@aeolus.jpl.nasa.gov>, mbone Subject: Re: multicast to unicast audio In-Reply-To: Your message of "Wed, 22 Nov 1995 09:30:37 GMT." <67.817032637@mailhost.aber.ac.uk> Date: Wed, 22 Nov 1995 10:28:30 +0000 Message-Id: <6392.817036110@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >For VAT, is the `user info'' just on the next port upwards in >number ?? yes. Mark From list-mgr@ISI.EDU Wed Nov 22 12:22:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25828>; Wed, 22 Nov 1995 04:26:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25791>; Wed, 22 Nov 1995 04:24:14 -0800 Received: from mailhost.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA25782>; Wed, 22 Nov 1995 04:24:11 -0800 Received: (jon@localhost) by weeble.lut.ac.uk (8.6.12/8.6.9) id MAA27636; Wed, 22 Nov 1995 12:22:43 GMT Date: Wed, 22 Nov 1995 12:22:43 +0000 (GMT) From: Jon Knight <J.P.Knight@lut.ac.uk> To: D E PRICE <dap@aberystwyth.ac.uk> Cc: Bill Fenner <fenner@parc.xerox.com>, Lee Elson <elson@aeolus.jpl.nasa.gov>, mbone, dap@aberystwyth.ac.uk Subject: Re: multicast to unicast audio In-Reply-To: <67.817032637@mailhost.aber.ac.uk> Message-Id: <Pine.SUN.3.91.951122122231.7133N-100000@weeble.lut.ac.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 22 Nov 1995, D E PRICE wrote: > Well the `global problem solver' is working > well tonight...... I now have lots of suggestions etc.... > > For VAT, is the `user info'' just on the next port upwards in > number ?? Yep. Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Researcher, Sysop and General Dogsbody, Department of Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * From list-mgr@ISI.EDU Wed Nov 22 05:41:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01962>; Wed, 22 Nov 1995 07:44:49 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01887>; Wed, 22 Nov 1995 07:43:38 -0800 Received: from wham.engin.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA01878>; Wed, 22 Nov 1995 07:43:34 -0800 Received: (dschluss@localhost) by wham.engin.umich.edu (8.6.12/8.6.4) id KAA25591; Wed, 22 Nov 1995 10:41:22 -0500 Date: Wed, 22 Nov 1995 10:41:21 -0500 (EST) From: "david a. schlussel" <dschluss@engin.umich.edu> To: Lee Elson <elson@aeolus.jpl.nasa.gov> Cc: mbone Subject: Re: multicast to unicast audio In-Reply-To: <199511171625.IAA21917@aeolus> Message-Id: <Pine.SOL.3.91.951122104059.25407C-100000@wham.engin.umich.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII there is some info on this and links to more info from my homepage +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ On Fri, 17 Nov 1995, Lee Elson wrote: > Does anyone know how to transfer audio from a multicasting machine to one that > doesn't have multicast? Both machines have vat but I need to be able to connect > the audio input from one vat session to the audio output of another. TIA > From list-mgr@ISI.EDU Wed Nov 22 18:13:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04047>; Wed, 22 Nov 1995 08:23:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03879>; Wed, 22 Nov 1995 08:22:02 -0800 Received: from arco.na.cnr.it by venera.isi.edu (5.65c/5.61+local-22) id <AA03842>; Wed, 22 Nov 1995 08:21:11 -0800 Received: from cps.na.cnr.it ([140.164.14.3]) by arco.na.cnr.it (5.65c+/1.34) id AA10708; Wed, 22 Nov 1995 17:16:34 -0500 Received: by cps.na.cnr.it (4.1/SMI-4.1) id AA09160; Wed, 22 Nov 95 17:13:57 +0100 Date: Wed, 22 Nov 95 17:13:57 +0100 From: canonico@cps.na.cnr.it (Roberto Canonico) Message-Id: <9511221613.AA09160@cps.na.cnr.it> To: mbone Subject: A question for tcpdumpers (2) Hi, thanks for your reply to my question about tcpdump. What i'm looking for is a simple tool able to measure the traffic addressed to a specific IP (multicast). That's why netstat is not enough. Regarding the bpf support for tcpdump, as far as i know, it requires a source distribution of SunOS, that is not available to me. Am i wrong? Sorry to bother you again. Roberto From list-mgr@ISI.EDU Wed Nov 22 01:06:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07020>; Wed, 22 Nov 1995 09:10:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06945>; Wed, 22 Nov 1995 09:09:14 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA06935>; Wed, 22 Nov 1995 09:09:10 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15847(3)>; Wed, 22 Nov 1995 09:07:20 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 22 Nov 1995 09:06:58 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: canonico@cps.na.cnr.it (Roberto Canonico) Cc: mbone Subject: Re: A question for tcpdumpers (2) In-Reply-To: Your message of "Wed, 22 Nov 1995 08:13:57 PST." <9511221613.AA09160@cps.na.cnr.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Nov 1995 09:06:47 PST From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov22.090658pst.177478@crevenia.parc.xerox.com> In message <9511221613.AA09160@cps.na.cnr.it>you write: >Regarding the bpf support for tcpdump, as far as i know, it requires >a source distribution of SunOS, that is not available to me. Am i wrong? The multicast distribution contains BPF-modified objects for the things you need source to. You still need to get and install BPF but for the interface drivers you can just use, for example, if_le.o.bpf from the multicast distribution. [Of course, you need to install the whole multicast distribution, not *just* if_le.o ...] Bill From list-mgr@ISI.EDU Wed Nov 22 08:16:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11251>; Wed, 22 Nov 1995 10:18:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11088>; Wed, 22 Nov 1995 10:16:47 -0800 Received: from ziggy.csc.ncsu.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA11042>; Wed, 22 Nov 1995 10:16:30 -0800 Received: by Ziggy.csc.ncsu.edu (4.1/Sun) id AA18284; Wed, 22 Nov 95 13:16:25 EST From: patel@ziggy.csc.ncsu.edu (Sanjay Patel) Posted-Date: Wed, 22 Nov 1995 13:16:25 -0500 (EST) Message-Id: <9511221816.AA18284@Ziggy.csc.ncsu.edu> Subject: UNSUBSCRIBE To: mbone Date: Wed, 22 Nov 1995 13:16:25 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 142 unsubscribe patel@adm.csc.ncsu.edu -- -Sanjay Phone: 919 515 1964 Email: patel@ncsu.edu URL: http://www.csc.ncsu.edu/cgi-bin/S_Patel.pl From list-mgr@ISI.EDU Wed Nov 22 08:23:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11824>; Wed, 22 Nov 1995 10:26:40 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11521>; Wed, 22 Nov 1995 10:24:40 -0800 Received: from utkux4.utcc.utk.edu ([128.169.76.11]) by venera.isi.edu (5.65c/5.61+local-22) id <AA11510>; Wed, 22 Nov 1995 10:24:37 -0800 Received: by utkux4.utcc.utk.edu (5.x/2.7c-UTK) id AA19619; Wed, 22 Nov 1995 13:23:26 -0500 Date: Wed, 22 Nov 1995 13:23:25 -0500 (EST) From: Nair Venugopal <venu@utkux.utcc.utk.edu> X-Sender: venu@utkux4 To: Bill Fenner <fenner@parc.xerox.com> Cc: mbone Subject: Re: MBone question In-Reply-To: <95Nov21.100054pst.177478@crevenia.parc.xerox.com> Message-Id: <Pine.SOL.3.91.951122130127.24250H-100000@utkux4> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Bill, I really appreciate your help. I have enclosed a figure of the topology in this mail. On Tue, 21 Nov 1995, Bill Fenner wrote: > In message <Pine.SOL.3.91.951120231553.14440B-100000@diesel.utcc.utk.edu>you wr > ite: > >2) All subnets except the subnet containing the host sourcing the traffic > > could see *all* participants in the session(using vat/nv). > > > >3) The vat/nv running on the host sourcing the session could *not* see > > any other participants in the session. > > Can that host see, for example, 'sd' sessions for other groups, or > participants in MBONE Audio? Yes, all sessions advertisements(including MBONE Audio) were showing up on "sd" in all the participating hosts. However, no participants(except the source) showed up in the VAT/NV sessions opened on the sourcing host. > I'd need a more complete description of the topology and the situation (and > hopefully to be able to capture it in action) to be able to help debug this. This is the topology. Unfortunately, we pulled down the setup after the broadcast. Also, it didnt occur to me to run mrouted with debugging turned on. :-( . The sourcing host is on the bottom left of the figure. We were broadcasting with a ttl of 30. Campus Mrouted server (Subnet A) SunOS-4.1.4 mrouted 3.4 / | \ / | \ / | \ ________/ | \_______ (threshold 1) / | \ (threshold 16) / | \ / | \ *** Host Sourcing traffic | Remote Site (Subnet B) | (Different network) Solaris 2.4 | SunOS 4.1.4 mrouted 2.x | mrouted 3.6 (cant see | (can see everything) others | (threshold 1) on vat/nv) | My Host (Subnet C) Solaris 2.4 mrouted 3.6 (can see everything) --Venu From list-mgr@ISI.EDU Wed Nov 22 23:09:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20821>; Wed, 22 Nov 1995 13:10:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20804>; Wed, 22 Nov 1995 13:09:53 -0800 Received: from cismsun.univ-lyon1.fr by venera.isi.edu (5.65c/5.61+local-22) id <AA20796>; Wed, 22 Nov 1995 13:09:50 -0800 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id WAA28898; Wed, 22 Nov 1995 22:09:41 +0100 Message-Id: <199511222109.WAA28898@cismsun.univ-lyon1.fr> Subject: Re: A question for tcpdumpers (2) To: canonico@cps.na.cnr.it (Roberto Canonico) Date: Wed, 22 Nov 1995 22:09:40 +0100 (MET) From: "Lucia Gradinariu" <lucia@univ-lyon1.fr> Cc: schulzrinne@fokus.gmd.de, mbone In-Reply-To: <9511221613.AA09160@cps.na.cnr.it> from "Roberto Canonico" at Nov 22, 95 05:13:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 737 > > What i'm looking for is a simple tool able to measure the traffic > addressed to a specific IP (multicast). That's why netstat is not enough. > > Regarding the bpf support for tcpdump, as far as i know, it requires > a source distribution of SunOS, that is not available to me. Am i wrong? > > Sorry to bother you again. > Roberto > > Just in case when you are using some RTP based applications you might use rtpdump written by Henning Schulzrinne and available with nevot-3.33 package from ftp://ftp.fokus.gmd.de/pub/step/nevot. It will dump all about packets at a receiving socket without bothering about your data link interface. It works fine on SunOS5 and I try to get it to work on OSF/1. Lucia.Gradinariu@univ-lyon1.fr From list-mgr@ISI.EDU Thu Nov 23 08:44:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15747>; Wed, 22 Nov 1995 22:43:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15737>; Wed, 22 Nov 1995 22:42:40 -0800 Received: from thoth.mch.sni.de by venera.isi.edu (5.65c/5.61+local-22) id <AA15730>; Wed, 22 Nov 1995 22:42:36 -0800 Received: from balla.mch.sni.de by thoth.mch.sni.de with SMTP id AA20157 (5.67a/IDA-1.5 for <mbone@isi.edu>); Thu, 23 Nov 1995 07:42:29 +0100 Received: (from gme@localhost) by balla.mch.sni.de (8.6.9/8.6.9) id HAA04668 for mbone@isi.edu; Thu, 23 Nov 1995 07:44:35 +0100 Date: Thu, 23 Nov 1995 07:44:35 +0100 From: Georg Memmesheimer MR PD251-DF <Georg.Memmesheimer@mch.sni.de> Message-Id: <199511230644.HAA04668@balla.mch.sni.de> To: mbone Subject: help Content-Type: text Content-Length: 5 help From list-mgr@ISI.EDU Fri Nov 24 03:41:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20657>; Thu, 23 Nov 1995 01:47:14 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20416>; Thu, 23 Nov 1995 01:42:03 -0800 Received: from ps.sfc.wide.ad.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA20409>; Thu, 23 Nov 1995 01:41:58 -0800 Received: from localhost (localhost [127.0.0.1]) by ps.sfc.wide.ad.jp (8.6.12+2.4W/3.4Wbeta695100619) with ESMTP id SAA19784; Thu, 23 Nov 1995 18:41:45 +0900 Message-Id: <199511230941.SAA19784@ps.sfc.wide.ad.jp> To: mbone, rem-conf@es.net Subject: Session announce `Ryuichi Sakamoto Tour95 "D&L" with Daizaburo Harada Live at Nippon Budohkan' From: Makoto Niimi <bignum@wide.ad.jp> X-Mailer: Mew version 1.00.4 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 23 Nov 1995 18:41:45 +0900 Sender: bignum@sfc.wide.ad.jp We'll present this event to you as following. Ryuichi Sakamoto Tour95 "D&L" with Daizaburo Harada Live at Nippon Budohkan Tokyo, Japan Time-Table Rehearsal from Nov. 30 16:00 JST (Nov. 30 7:00 UTC) till Nov. 30 17:00 JST (Nov. 30 8:00 UTC) Session (with TTL=127) Video (nv,32kbps*2=64kbps) Audio (GSM 17Kbps) Concert from Nov. 30 18:00 JST (Nov. 30 9:00 UTC) till Nov. 30 22:00 JST (Nov. 30 13:00 UTC) Session (with TTL=127) Video (nv,64kbps*2=128kbps) Audio (dvi4,32kbps) Information http://www.sdw.com/DandL/ In this mbone experiment, we will install temporary satellite station at the Nippon Budohkan. This satellite station will broadcast IP datagrams to several satellite stations of WIDE Network Operation Centers at 2Mbps. One station at the NOC relays nv/vat traffic to the MBONE. ----- Makoto Niimi, WIDE Project From list-mgr@ISI.EDU Thu Nov 23 14:00:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22630>; Thu, 23 Nov 1995 04:04:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22603>; Thu, 23 Nov 1995 04:01:42 -0800 Received: from nez-perce.inria.fr by venera.isi.edu (5.65c/5.61+local-22) id <AA22596>; Thu, 23 Nov 1995 04:01:29 -0800 Received: from electre.inria.fr (electre.inria.fr [128.93.2.11]) by nez-perce.inria.fr (8.7.1/8.6.9) with SMTP id NAA21309; Thu, 23 Nov 1995 13:00:06 +0100 (MET) Received: by electre.inria.fr; Thu, 23 Nov 1995 13:00:06 +0100 From: Christian DONOT <Christian.Donot@inria.fr> Message-Id: <199511231200.AA03693@electre.inria.fr> Subject: Re: Session announce `Ryuichi Sakamoto Tour95 "D&L" with Daizaburo Harada To: bignum@wide.ad.jp (Makoto Niimi) Date: Thu, 23 Nov 1995 13:00:06 +0100 (MET) Cc: mbone, rem-conf@es.net In-Reply-To: <199511230941.SAA19784@ps.sfc.wide.ad.jp> from "Makoto Niimi" at Nov 23, 95 06:41:45 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Quoting > Makoto Niimi wrote, > > We'll present this event to you as following. > > Ryuichi Sakamoto Tour95 "D&L" with Daizaburo Harada > Live at Nippon Budohkan Tokyo, Japan > > Time-Table > Rehearsal > from Nov. 30 16:00 JST (Nov. 30 7:00 UTC) > till Nov. 30 17:00 JST (Nov. 30 8:00 UTC) > > Session (with TTL=127) > Video (nv,32kbps*2=64kbps) > Audio (GSM 17Kbps) > > Concert > from Nov. 30 18:00 JST (Nov. 30 9:00 UTC) > till Nov. 30 22:00 JST (Nov. 30 13:00 UTC) > > Session (with TTL=127) > Video (nv,64kbps*2=128kbps) > Audio (dvi4,32kbps) > > > Information http://www.sdw.com/DandL/ > > In this mbone experiment, we will install temporary satellite station > at the Nippon Budohkan. This satellite station will broadcast IP > datagrams to several satellite stations of WIDE Network Operation > Centers at 2Mbps. One station at the NOC relays nv/vat traffic to > the MBONE. > > ----- > The transatlantic links are already full. I'm not sure that on the European's side, we need this kind of diffusion. Please, could'you put the ttl below 64. Best regards. Christian -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Christian Donot Direction of Research Promotion and its Transfer =+=+=+=+=+=+=+= * INRIA's Activities Demonstrations Manager (DPRT) * French Multicast Bone Co-ordinator (mbone-fr@inria.fr) (ARISTOTE) To get "mbone-fr" map : ftp anonymous from electre.inria.fr:pub/mbone ftp anonymous from ftp.inria.fr:network/mbone/map * To get "ivs" : (INRIA) ftp anonymous from zenon.inria.fr:rodeo/ivs/last_version http://www.inria.fr/rodeo/ivs.html * To get "telesia" : (Aristote) ftp anonymous from electre.inria.fr:pub/videoconf/last_version =+=+=+=+=+=+=+= Tel : +33 1 39 63 57 75 | INRIA/DPRT/ARISTOTE Fax : +33 1 39 63 55 34/53 30 | BP 105 Email : Christian.Donot@inria.fr | 78153 LE CHESNAY CEDEX : chd@inria.fr | FRANCE =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= From list-mgr@ISI.EDU Thu Nov 23 07:24:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17153>; Thu, 23 Nov 1995 23:32:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17082>; Thu, 23 Nov 1995 23:25:45 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA17075>; Thu, 23 Nov 1995 23:25:44 -0800 Received: from localhost (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id PAA00307; Thu, 23 Nov 1995 15:24:05 -0800 Message-Id: <199511232324.PAA00307@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: canonico@cps.na.cnr.it (Roberto Canonico) Cc: mbone Subject: Re: A question for tcpdumpers In-Reply-To: Your message of "Wed, 22 Nov 1995 09:58:52 +0100." <9511220858.AA08218@cps.na.cnr.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Nov 1995 15:24:01 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> See if the box which has the ATM interface supports snmp and if so then you can issue an snmp request to find out how many packets is the interface transmitting or receiving. Cheers, Amancio >>> Roberto Canonico said: > > Hi everybody, > > I've got a little question for tcpdump users: > > - Is it possible to use tcpdump to measure how many IP packets per second > arrive from an ATM board? > > I tried to listen on an ATM interface (fa0) but tcpdump didn't recognize > the incoming IP packets. Is there any other useful tool able to catch IP > traffic from an ATM interface? > > Thanks for any suggestion. > > Roberto > > -------------------------------------------------------------------------- > Roberto Canonico > Universita' degli Studi di Napoli "Federico II" - Italy > email: canonico@cps.cps.na.cnr.it canonico@capri.dis.unina.it > -------------------------------------------------------------------------- From list-mgr@ISI.EDU Mon Nov 27 20:53:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18915>; Sun, 26 Nov 1995 21:03:47 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18695>; Sun, 26 Nov 1995 20:54:46 -0800 Received: from biomed.nus.sg by venera.isi.edu (5.65c/5.61+local-22) id <AA18686>; Sun, 26 Nov 1995 20:54:37 -0800 Received: from localhost (bchtantw@localhost) by biomed.nus.sg (8.6.4/8.6.4) id MAA06107; Mon, 27 Nov 1995 12:53:57 +0800 Date: Mon, 27 Nov 1995 12:53:57 +0800 (SST) From: Dr Tan Tin Wee <bchtantw@biomed.nus.sg> To: mbone Subject: Help needed Message-Id: <Pine.ULT.3.91.951127124051.5091I-100000@biomed.nus.sg> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We are running a localised ATM test bed to test the frame rate speeds of nv and vat. At the moment, it seems that nv is only 256 colours. Can it do any better? Also, what is the best frame rate anybody has gotten out of nv, theoretical? nv between two unix boxes side by side on an ethernet ? nv between two unix boxes connected to a fast ethernet switch? If any one could share your experience with us, we would very much appreciate it. thanks in advance. Tin Wee -- Tan Tin Wee Internet R&D Unit, ComCen, NUS +(65)-772-6490 Fax: 65-778-0198 Internet: tinwee@technet.sg From list-mgr@ISI.EDU Sun Nov 26 16:00:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23054>; Mon, 27 Nov 1995 00:12:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22821>; Mon, 27 Nov 1995 00:01:07 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA22814>; Mon, 27 Nov 1995 00:01:06 -0800 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14913(5)>; Mon, 27 Nov 1995 00:00:53 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16136>; Mon, 27 Nov 1995 00:00:33 -0800 To: Dr Tan Tin Wee <bchtantw@biomed.nus.sg> Cc: mbone Subject: Re: Help needed In-Reply-To: Your message of "Sun, 26 Nov 95 20:53:57 PST." <Pine.ULT.3.91.951127124051.5091I-100000@biomed.nus.sg> Date: Mon, 27 Nov 1995 00:00:31 PST Sender: Ron Frederick <frederic@parc.xerox.com> From: Ron Frederick <frederic@parc.xerox.com> Message-Id: <95Nov27.000033pst.16136@ecco.parc.xerox.com> In message <Pine.ULT.3.91.951127124051.5091I-100000@biomed.nus.sg> you write: > At the moment, it seems that nv is only 256 colours. Can it do > any better? > This is not correct. The native format used by nv to encode video is YUV 4:2:2. On average, it works out to 16 bits/pixel, but each pixel is represented by three 8-bit values, which are just a linear combination of a 24-bit RGB value. When displaying things on the screen, nv will use a 24-bit visual if it can find one. Otherwise, it will do the best it can, rendering in RGB555 for a 16-bit display, dithering to 8-bit PseudoColor, or even dithering to 1-bit monochrome if it has to. To speed things up, nv does make a slight compromise in quality for 24-bit. It actually does the YUV->RGB conversion using a 16-bit lookup table. So, some of the low order bits of the uncompressed pixel data are thrown away. > Also, what is the best frame rate anybody has gotten out of nv, > theoretical? > This depends on the machine you run it on. However, several machines are capable of getting the full 30 fps at "small" size, and some are capable of it at "medium" size when there isn't too much motion. > nv between two unix boxes side by side on an ethernet ? > nv between two unix boxes connected to a fast ethernet switch? > For the most part, this shouldn't matter, except in the sense that one device driver might be better optimized than another. Even when setting a higher than normal max bandwidth limit, it is difficult to get nv to produce more than 10 Mbps, especially on an ethernet where the MTU is so small. If you recompile nv with a larger packet size, assuming the network can handle the larger packets, you can push up the bandwidth nv is capable of delivering. There are still some unnecessary copy steps in the current releases, though. I've been redesigning the capture routines rather extensively to avoid those, and I've been able to improve the efficiency quite a bit on some machines (particularly the SGI Indy and DEC Alpha), but I'm afraid that code isn't ready for release yet. -- Ron Frederick frederick@parc.xerox.com From list-mgr@ISI.EDU Sun Nov 26 23:35:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25468>; Mon, 27 Nov 1995 01:39:46 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25297>; Mon, 27 Nov 1995 01:36:33 -0800 Received: from radicalmedia.com by venera.isi.edu (5.65c/5.61+local-22) id <AA25289>; Mon, 27 Nov 1995 01:36:30 -0800 Received: (from phiber@localhost) by radicalmedia.com (8.6.12/8.6.12) id EAA02278; Mon, 27 Nov 1995 04:35:35 -0500 From: Mark Abene <phiber@radicalmedia.com> Message-Id: <199511270935.EAA02278@radicalmedia.com> Subject: mbone3.uu.net hosed... To: hank@uunet.uu.net Date: Mon, 27 Nov 1995 04:35:33 -0500 (EST) Cc: mbone X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1101 Sometime after midnight mbone3.uu.net started spitting out the following errors, over and over again: Nov 27 00:28:38 scrod mrouted[315]: warning - 137.39.229.98 reports an invalid o rigin (0.0.0.0) and/or mask (ff000000) Nov 27 00:28:48 scrod last message repeated 2 times Nov 27 00:28:48 scrod mrouted[315]: warning - 137.39.229.98 reports an invalid o rigin (0.0.0.0) and/or mask (ffffffff) Nov 27 00:28:53 scrod mrouted[315]: warning - 137.39.229.98 reports an invalid o rigin (0.0.0.0) and/or mask (ff000000) Nov 27 00:28:58 scrod mrouted[315]: warning - 137.39.229.98 reports an invalid o rigin (0.0.0.0) and/or mask (ff000000) Nov 27 00:29:10 scrod mrouted[315]: warning - 137.39.229.98 reports an invalid o rigin (0.0.0.0) and/or mask (ffffffff) Nov 27 00:29:20 scrod mrouted[315]: warning - 137.39.229.98 reports an invalid o rigin (0.0.0.0) and/or mask (ffffffff) This, with varying origins and masks. I had to kill our mrouted until further notice, since it was wasting disk space with all the logged errors. Are there problems on the mbone3 machine? -Mark Abene Radical Media, Inc. From list-mgr@ISI.EDU Sun Nov 26 17:50:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25803>; Mon, 27 Nov 1995 01:54:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25777>; Mon, 27 Nov 1995 01:50:59 -0800 Received: from kachina.jetcafe.org ([206.117.70.2]) by venera.isi.edu (5.65c/5.61+local-22) id <AA25769>; Mon, 27 Nov 1995 01:50:57 -0800 Received: from [127.0.0.1] ([127.0.0.1]) by kachina.jetcafe.org (8.6.10/8.6.6) with SMTP id BAA21003; Mon, 27 Nov 1995 01:50:52 -0800 Message-Id: <199511270950.BAA21003@kachina.jetcafe.org> To: mbone Cc: earle@elroy.jpl.nasa.gov Subject: Mrouted troubles Date: Mon, 27 Nov 1995 01:50:47 -0800 From: Dave Hayes <dave@kachina.jetcafe.org> The advantage of sitting at home trying to write software late at night is seeing this kind of stuff: Nov 26 23:11:49 kachina vmunix: ip_mforward: ip_mrouter socket queue full Nov 26 23:11:57 kachina last message repeated 5 times The machine I get my tunnel from reports the following: Nov 26 03:03:00 elxr mrouted[18896]: [W] warning - received packet shorter (576 bytes) than hdr+data length (20+568) (Ok, ignore that one) Nov 26 21:31:27 elxr mrouted[18896]: [W] warning - received truncated route report from 137.78.80.130 Nov 26 21:32:01 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports out-of-range metric 0 for origin 164/8 Nov 26 21:32:01 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports out-of-range metric 0 for origin 0/8 ...ad nauseum... In looking through the logs I find that this message seemed to cycle through many different IP numbers: Nov 26 22:18:55 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports out-of-range metric 0 for origin default Nov 26 22:19:10 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports an invalid origin (0.44.0.0) and/or mask (ff00ad00) Nov 26 22:19:16 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports out-of-range metric 0 for origin 179.0/15 Nov 26 22:19:16 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports out-of-range metric So in my naivete, I cut the tunnel to jetcafe.org (since the socket overflows were creaming my 128Kbps network), and the tunnel to 137.78.80.130. I still got ip_mrouter socket queue full errors, so I then killed both mrouteds. After a while, I restarted the one on elxr only to find: Nov 27 01:35:43 elxr mrouted[7428]: [W] mrouted version 3.6 Nov 27 01:38:50 elxr vmunix: ip_mforward: ip_mrouter socket queue full Nov 27 01:39:34 elxr last message repeated 8 times *sigh* Then there's these: 01:43:29.159 warning - kernel entry already exists for (204.62.246.73 224.2.143.24) 01:43:29.164 warning - kernel entry already exists for (149.127.6.181 224.2.0.1) 01:43:29.166 warning - kernel entry already exists for (133.138.190.73 225.0.54.119) 01:43:29.168 warning - kernel entry already exists for (204.62.246.73 224.2.143.24) When I cut all the tunnels but the one to AMES, I still get this problem. Whatever it is has escaped. 8-/ Am I loopy, completely clueless, or is there something bad happening here? ------ >>> Dave Hayes - Altadena CA, USA - dave@jetcafe.org <<< "When I was in the desert", said Nasrudin one day, "I caused an entire tribe of horrible and bloodthirsty bedouins to run." "However did you do it?", someone asked. "Easy. I just ran, and they ran after me." From list-mgr@ISI.EDU Mon Nov 27 14:19:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26678>; Mon, 27 Nov 1995 02:31:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26423>; Mon, 27 Nov 1995 02:20:09 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA26415>; Mon, 27 Nov 1995 02:20:01 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id MAA06527; Mon, 27 Nov 1995 12:19:33 +0200 Date: Mon, 27 Nov 1995 12:19:33 +0200 Message-Id: <199511271019.MAA06527@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Mark Abene <phiber@radicalmedia.com> Cc: mbone Subject: mbone3.uu.net hosed... In-Reply-To: <199511270935.EAA02278@radicalmedia.com> References: <199511270935.EAA02278@radicalmedia.com> Mark Abene writes: > > Sometime after midnight mbone3.uu.net started spitting out the following > errors, over and over again: > > Nov 27 00:28:38 scrod mrouted[315]: warning - 137.39.229.98 reports an invalid o > rigin (0.0.0.0) and/or mask (ff000000) > Nov 27 00:28:48 scrod last message repeated 2 times > notice, since it was wasting disk space with all the logged errors. > Are there problems on the mbone3 machine? > Somebody is injecting aggregates and host routes to the DVMRP routing domain and your VERY OLD mrouted 2.2 is complaining about them. PLEASE UPGRADE TO A RECENT VERSION. You are sucking up bandwidth unneccessarily anyway. Pete From list-mgr@ISI.EDU Mon Nov 27 01:32:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27387>; Mon, 27 Nov 1995 03:40:17 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27301>; Mon, 27 Nov 1995 03:33:34 -0800 Received: from radicalmedia.com by venera.isi.edu (5.65c/5.61+local-22) id <AA27294>; Mon, 27 Nov 1995 03:33:31 -0800 Received: (from phiber@localhost) by radicalmedia.com (8.6.12/8.6.12) id GAA02559; Mon, 27 Nov 1995 06:32:33 -0500 From: Mark Abene <phiber@radicalmedia.com> Message-Id: <199511271132.GAA02559@radicalmedia.com> Subject: Re: mbone3.uu.net hosed... To: pete@sms.fi (Petri Helenius) Date: Mon, 27 Nov 1995 06:32:32 -0500 (EST) Cc: mbone In-Reply-To: <199511271019.MAA06527@silver.sms.fi> from "Petri Helenius" at Nov 27, 95 12:19:33 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 603 > Somebody is injecting aggregates and host routes to the DVMRP routing domain > and your VERY OLD mrouted 2.2 is complaining about them. > > PLEASE UPGRADE TO A RECENT VERSION. > You are sucking up bandwidth unneccessarily anyway. > > Pete > Gladly, as soon as Sun provides a WORKING update to the multicasting facilities for Solaris x86 2.4. Until that time, I'm stuck with version 2.2 of mrouted which I ported myself. Their last supposed "update" still did not support the new socket options and protocol enhancements found in multicasting 3.4, much less 3.6. -Mark Abene Radical Media, Inc. From list-mgr@ISI.EDU Mon Nov 27 01:48:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27593>; Mon, 27 Nov 1995 03:55:09 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27569>; Mon, 27 Nov 1995 03:52:03 -0800 Received: from radicalmedia.com by venera.isi.edu (5.65c/5.61+local-22) id <AA27562>; Mon, 27 Nov 1995 03:52:00 -0800 Received: (from phiber@localhost) by radicalmedia.com (8.6.12/8.6.12) id GAA02647; Mon, 27 Nov 1995 06:48:12 -0500 From: Mark Abene <phiber@radicalmedia.com> Message-Id: <199511271148.GAA02647@radicalmedia.com> Subject: Re: Mrouted troubles To: dave@kachina.jetcafe.org (Dave Hayes) Date: Mon, 27 Nov 1995 06:48:12 -0500 (EST) Cc: mbone In-Reply-To: <199511270950.BAA21003@kachina.jetcafe.org> from "Dave Hayes" at Nov 27, 95 01:50:47 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1003 ... > Nov 26 22:18:55 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports out-of-range metric 0 for origin default > Nov 26 22:19:10 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports an invalid origin (0.44.0.0) and/or mask (ff00ad00) > Nov 26 22:19:16 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports out-of-range metric 0 for origin 179.0/15 > Nov 26 22:19:16 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports out-of-range metric > > So in my naivete, I cut the tunnel to jetcafe.org (since the socket > overflows were creaming my 128Kbps network), and the tunnel to > 137.78.80.130. I still got ip_mrouter socket queue full errors, so > I then killed both mrouteds. ... I was flooded with the very same reports of "invalid origin and/or mask". I currently have mrouted disabled because the instant I bring it up, I'm flooded with the errors. I suspect there will be a lot of confused people who will be discovering this in a few hours. -Mark Abene Radical Media, Inc. From list-mgr@ISI.EDU Sun Nov 26 12:02:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27786>; Mon, 27 Nov 1995 04:06:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27753>; Mon, 27 Nov 1995 04:03:39 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA27746>; Mon, 27 Nov 1995 04:03:37 -0800 Received: from localhost (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id UAA00440; Sun, 26 Nov 1995 20:03:00 -0800 Message-Id: <199511270403.UAA00440@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Mark Abene <phiber@radicalmedia.com> Cc: mbone Subject: Re: mbone3.uu.net hosed... In-Reply-To: Your message of "Mon, 27 Nov 1995 06:32:32 EST." <199511271132.GAA02559@radicalmedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Nov 1995 20:02:59 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Hmmm... Have you considered running FreeBSD or Linux ... Amancio >>> Mark Abene said: > > Somebody is injecting aggregates and host routes to the DVMRP routing doma in > > and your VERY OLD mrouted 2.2 is complaining about them. > > > > PLEASE UPGRADE TO A RECENT VERSION. > > You are sucking up bandwidth unneccessarily anyway. > > > > Pete > > > > Gladly, as soon as Sun provides a WORKING update to the multicasting facilit ies > for Solaris x86 2.4. Until that time, I'm stuck with version 2.2 of mrouted > which I ported myself. > Their last supposed "update" still did not support the new socket options an d > protocol enhancements found in multicasting 3.4, much less 3.6. > > -Mark Abene > Radical Media, Inc. > From list-mgr@ISI.EDU Mon Nov 27 13:48:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28614>; Mon, 27 Nov 1995 04:52:55 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28582>; Mon, 27 Nov 1995 04:49:45 -0800 Received: from aries.cyceron.fr (cyceron.fr) by venera.isi.edu (5.65c/5.61+local-22) id <AA28568>; Mon, 27 Nov 1995 04:49:22 -0800 Received: from indigo1.cyceron.fr by aries.cyceron.fr via SMTP (920330.SGI/921123.CYCERON) for mbone@ISI.EDU id AA16289; Mon, 27 Nov 95 13:48:38 GMT Received: by indigo1.cyceron.fr (940816.SGI.8.6.9/920502.SGI) id NAA05842; Mon, 27 Nov 1995 13:48:13 GMT From: "Jael.Travere@Cyceron.Fr" <travere@indigo1.cyceron.fr> Message-Id: <9511271348.ZM5840@indigo1.cyceron.fr> Date: Mon, 27 Nov 1995 13:48:13 +0000 In-Reply-To: Mark Abene <phiber@radicalmedia.com> "Re: Mrouted troubles" (Nov 27, 6:48am) References: <199511271148.GAA02647@radicalmedia.com> Reply-To: Jael.Travere@Cyceron.Fr X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Mark Abene <phiber@radicalmedia.com> Subject: Re: Mrouted troubles Cc: mbone Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 27, 6:48am, Mark Abene wrote: > Subject: Re: Mrouted troubles > ... > > Nov 26 22:18:55 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports > > I was flooded with the very same reports of "invalid origin and/or mask". > I currently have mrouted disabled because the instant I bring it up, I'm > flooded with the errors. I suspect there will be a lot of confused people > who will be discovering this in a few hours. > > -Mark Abene > Radical Media, Inc. >-- End of excerpt from Mark Abene Same problem for me in France ... i have disabled mrouted on my SGI. Nov 27 13:46:08 4D:indigo1 mrouted[5839]: warning - 129.104.30.50 reports an invalid origin (0.0.0.0) and/or mask (ff878c00) Nov 27 13:46:08 4D:indigo1 mrouted[5839]: warning - 129.104.30.50 reports an invalid origin (0.0.0.0) and/or mask (ff879b01) Nov 27 13:46:08 4D:indigo1 mrouted[5839]: warning - 129.104.30.50 reports an invalid origin (0.0.0.0) and/or mask (ff879f01) Nov 27 13:46:08 4D:indigo1 mrouted[5839]: warning - 129.104.30.50 reports an invalid origin (0.0.0.0) and/or mask (ff87a000) Nov 27 13:46:08 4D:indigo1 mrouted[5839]: warning - 129.104.30.50 reports an invalid origin (0.0.0.0) and/or mask (ff87a996) -- Jael.Travere@Cyceron.Fr ______________________________________________________________________ J.M Travere, Ph. D Cyceron PET Research Center CEA/DSV/DRM Bd Becquerel - BP 5229 Comp. Sc. Manager 14074 - Caen - CEDEX France Std : (+33) 31 47 02 00 Tel : (+33) 31 47 02 14 Fax : (+33) 31 47 02 22 ______________________________________________________________________ => Cyceron experimental URL ! : http://www.cyceron.fr ______________________________________________________________________ From list-mgr@ISI.EDU Mon Nov 27 15:44:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29556>; Mon, 27 Nov 1995 05:54:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29389>; Mon, 27 Nov 1995 05:45:47 -0800 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA29382>; Mon, 27 Nov 1995 05:45:45 -0800 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id OAA02146; Mon, 27 Nov 1995 14:41:46 +0100 Message-Id: <199511271341.OAA02146@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: Mark Abene <phiber@radicalmedia.com> Cc: dave@kachina.jetcafe.org (Dave Hayes), mbone, e93_mda@it.kth.se Subject: Re: Mrouted troubles In-Reply-To: Your message of "Mon, 27 Nov 1995 06:48:12 EST." <199511271148.GAA02647@radicalmedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Nov 1995 14:44:56 +0100 From: Magnus <e93_mda@it.kth.se> > I was flooded with the very same reports of "invalid origin and/or mask". > I currently have mrouted disabled because the instant I bring it up, I'm > flooded with the errors. I suspect there will be a lot of confused people > who will be discovering this in a few hours. FYI have I also recieved many errors on my multicast router tjatte.electrum.kth.se. Somebody must be bored enougth for flooding the net with new routing entries. I could however come up with lots of other activities as alternative :-) Magnus From list-mgr@ISI.EDU Mon Nov 27 16:17:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29996>; Mon, 27 Nov 1995 06:19:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29922>; Mon, 27 Nov 1995 06:16:47 -0800 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA29914>; Mon, 27 Nov 1995 06:16:44 -0800 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id PAA02702; Mon, 27 Nov 1995 15:14:13 +0100 Message-Id: <199511271414.PAA02702@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: mbone Cc: magda@it.kth.se Subject: Routing entires Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Nov 1995 15:17:24 +0100 From: Magnus <e93_mda@it.kth.se> Hi! I currently have 6206 routing entries on my machine. Magnus From list-mgr@ISI.EDU Mon Nov 27 06:20:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00436>; Mon, 27 Nov 1995 06:33:17 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00110>; Mon, 27 Nov 1995 06:20:46 -0800 Received: from access.cc.univie.ac.at by venera.isi.edu (5.65c/5.61+local-22) id <AA00101>; Mon, 27 Nov 1995 06:20:29 -0800 Received: by cc.univie.ac.at (MX V4.1 VAX) id 15; Mon, 27 Nov 1995 15:20:23 MET Date: Mon, 27 Nov 1995 15:20:21 MET From: "Christian Panigl, ACOnet/UniVie +43 1 4065822-383" <panigl@cc.univie.ac.at> To: mbone Cc: panigl@cc.univie.ac.at Message-Id: <0099A064.55028098.15@cc.univie.ac.at> Subject: Re: Mrouted troubles >I was flooded with the very same reports of "invalid origin and/or mask". >I currently have mrouted disabled because the instant I bring it up, I'm >flooded with the errors. I suspect there will be a lot of confused people >who will be discovering this in a few hours. These where the last words of our Mbone router (Cisco with 10.3(5.5)) at its last gasp this morning: Nov 27 06:41:22: %RADIX-4-ORPHAN: Orphaned mask 0xAF433C, refcount=1 at 0x0, next=0x0 -Process= "IGMP Input", ipl= 0, pid= 36 -Traceback= 256564 2BB196 2BB172 256654 2BB150 2B8060 2B7872 Nov 27 06:42:02: %RADIX-3-DELETE: Error deleting trie entry, couldn't find our annotation -Process= "IGMP Input", ipl= 0, pid= 36 -Traceback= 2563EC 2BB196 2BB172 256654 2BB150 2B8060 2B7872 After disabling our international tunnel and (just to be on the safe side) "NO ip multicast-routing" it's doing better again ... Regards Christian --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet : -------------------------------------------- --- --- Universitaetsstrasse 7 : Internet: Christian.Panigl@CC.UniVie.ac.at --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) --- From list-mgr@ISI.EDU Mon Nov 27 17:05:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02291>; Mon, 27 Nov 1995 07:15:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01964>; Mon, 27 Nov 1995 07:05:45 -0800 Received: from ncc.ripe.net by venera.isi.edu (5.65c/5.61+local-22) id <AA01953>; Mon, 27 Nov 1995 07:05:39 -0800 Received: from office.ripe.net by ncc.ripe.net with SMTP id AA19223 (5.65a/NCC-2.30); Mon, 27 Nov 1995 16:05:02 +0100 Message-Id: <9511271505.AA19223@ncc.ripe.net> To: Magnus <e93_mda@it.kth.se> Cc: mbone From: Geert Jan de Groot <GeertJan.deGroot@ripe.net> X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: Re: Mrouted troubles In-Reply-To: Your message of "Mon, 27 Nov 1995 14:44:56 +0100." <199511271341.OAA02146@piraya.electrum.kth.se> Date: Mon, 27 Nov 1995 16:05:02 +0100 Sender: GeertJan.deGroot@ripe.net On Mon, 27 Nov 1995 14:44:56 +0100 Magnus wrote: > FYI have I also recieved many errors on my multicast router > tjatte.electrum.kth.se. > Can people please send kill -USR1 to their mrouted and see if they see the same as I do: Origin-Subnet From-Gateway Metric Tmr In-Vif Out-Vifs 192.87.4/24 1 5 0 1* 0.0.0/23 192.87.4.25 9 0 0 1* 0.0.0.0/32 192.87.4.25 9 0 0 1* 0.0.0/21 192.87.4.25 9 0 0 1* 0.0.0.0/32 192.87.4.25 9 0 0 1* 0.0.0.0/32 192.87.4.25 9 0 0 1* 0.0.0.0/32 192.87.4.25 9 0 0 1* 0.0.0/24 192.87.4.25 9 0 0 1* 170.0.0.129/32 192.87.4.25 20 0 0 1* 161.0.0.0/32 192.87.4.25 26 0 0 1* 0.0/16 192.87.4.25 9 0 0 1* 0.0.0/24 192.87.4.25 9 0 0 1* 0.0.0/23 192.87.4.25 9 0 0 1* 0.0.0/24 192.87.4.25 9 0 0 1* 0.0.0/24 192.87.4.25 9 0 0 1* 13.0.144.32/27 192.87.4.25 23 0 0 1* 0.0.0/22 192.87.4.25 9 0 0 1* 0.0.0.0/31 192.87.4.25 9 0 0 1* 0.0.0.0/32 192.87.4.25 9 0 0 1* 0.0.0/19 192.87.4.25 9 0 0 1* 0.0.0.0/30 192.87.4.25 9 0 0 1* 0.0.0.0/32 192.87.4.25 9 0 0 1* This looks suspiciously like a byte swap problem somewhere, and I'm debugging code which isn't helpful. Am I the only person seeing this? Geert Jan From list-mgr@ISI.EDU Fri Nov 27 15:59:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02347>; Mon, 27 Nov 1995 07:16:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01610>; Mon, 27 Nov 1995 06:54:58 -0800 Received: from campino.Informatik.RWTH-Aachen.DE by venera.isi.edu (5.65c/5.61+local-22) id <AA01597>; Mon, 27 Nov 1995 06:54:38 -0800 Received: from i4.informatik.rwth-aachen.de (ikarus.Informatik.RWTH-Aachen.DE [137.226.8.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-4/8.6.12) with ESMTP id PAA17992 for <mbone@ISI.EDU>; Mon, 27 Nov 1995 15:48:48 +0100 Received: from IKARUS/TEMPQ by i4.informatik.rwth-aachen.de (Mercury 1.20); 27 Nov 95 15:54:27 Received: from TEMPQ by IKARUS (Mercury 1.20); 27 Nov 95 15:53:51 To: mbone From: "Claudia Popien" <popien@i4.informatik.rwth-aachen.de> Organization: Informatik IV - RWTH Aachen Date: 27 Nov 1995 15:59:53 GMT+1 Subject: Forwarded: ICDP96 - conference announcement Priority: normal X-Mailer: Pegasus Mail/Mac v2.02 Message-Id: <1E0BF063962@i4.informatik.rwth-aachen.de> ============================================================================ ANNOUNCEMENT AND CALL FOR PARTICIPATION I C D P ' 9 6 IFIP / IEEE INTERNATIONAL CONFERENCE ON DISTRIBUTED PLATFORMS Client/Server and Beyond: DCE, CORBA, ODP & Advanced Distributed Applications Dresden, Germany February 27 - March 1, 1996 Organized by IFIP IEEE Communications Society Gesellschaft fuer Informatik Dresden University of Technology Aachen University of Technology ============================================================================ OBJECTIVES AND SCOPE: Client/Server applications are of increasing importance in industry, and have been enhanced with advanced distributed object-oriented techniques, dedicated tool support and both multimedia and mobile computing extensions. Such solutions are a significant step towards a global distributed processing model. Recent responses to this trend are standardized platforms and models including the Distributed Computing Environment (DCE) of the Open Software Foundation (OSF), Open Distributed Processing (ODP), and the Common Object Request Broker Architecture (CORBA) of the Object Management Group (OMG). ICDP'96 will be a major forum for distributed systems researchers, network developers, service providers, application designers and end users for discussing the latest research and development results with respect to these platforms. ---------------------------------------------------------------------------- -------------- Tuesday, February 27 - Tutorials -------------------------- ---------------------------------------------------------------------------- Tutorial Track 1: 9.00 - 12.00 Tutorial 1A: OSF DCE SECURITY, AN ARCHITECTURAL OVERVIEW Tuvell, W. (DCE Architect, OSF Cambridge, USA) Tutorial 1B: MOBILE COMPUTING Davies, N. (Univ. Lancaster, UK) Tutorial 1C: DATA AND APPLICATION (RE)ENGINEERING IN CLIENT/SERVER ENVIRONMENTS Umar, A. (Bellcore, USA) Tutorial Track 2: 14.00 - 17.00 Tutorial 2A: COMMON OBJECT REQUEST BROKER ARCHITECTURE (CORBA) Siegel, J. (Director of Program Management, OMG, USA) Tutorial 2B: WORKFLOW MANAGEMENT SYSTEMS Jablonski, S. (Univ. Erlangen, D) Tutorial 2C: REFERENCE MODEL FOR OPEN DISTRIBUTED PROCESSING Farooqui, K. (Univ. of Ottawa, CDN) ---------------------------------------------------------------------------- -------------- Wednesday, February 28 ------------------------------------ ---------------------------------------------------------------------------- Welcome : 9.00 - 9.30 INVITED TALK : 9.30 - 10.30 Creating Consensus for Distributed Computing Soley, R. (Vice President & Technical Director, OMG, USA) Break : 10.30 - 11.00 ---------------------------------------------------------------------------- SESSION 1: 11.00 - 12.30 MOBILE COMPUTING Session Chair : Spaniol, O. (RWTH Aachen, D) Extensions to ANSAware for Advanced Mobile Applications Friday, A.; Blair, G.S.; Cheverst, K.; Davies, N. (Lancester Univ., UK) System-Integration for Mobile Computing and Service Mobility Diehl, N.; Grill, D.; Held, A.; Kroh, R.; Reigber, T.; Ziegert,Th. (Daimler-Benz AG Ulm, D) A Comparative Analysis of Virtual Versus Physical Process-Migration Han, K.; Ghosh, S.(Brown Univ., USA) ---------------------------------------------------------------------------- SESSION 2 : 11.00 -12.30 CORBA Session Chair : Ruddock, D. (Bellcore, USA) Use of DSOM Before/After Metaclass for Enabling Object Access Control Benantar, M.; Blakeley, B.; Nadalin, A. (IBM Austin, USA) A Framework for Inter-ORB Request Level Bridge Construction Steinder, M.; Uszok, A.; Zielinski, K. (Univ. of Mining and Metallurgy, PL) Migration of Legacy Applications to a CORBA Platform: A Case Study Konstantas, D. (Univ. of Geneva, CH) ---------------------------------------------------------------------------- Lunch : 12.30 - 14.00 ---------------------------------------------------------------------------- SESSION 3 : 14.00 - 15.30 DCE: INTEROPERABILITY Session Chair : Dilley, J. (HP Labs, USA) DCE Porting Tool Muppidi, S.; Krawetz, N.; Marti, W.; Beedubail, G.; Pooch, U. (Texas A&M Univ., USA) Migrating from ISODE/ROSE to DCE/RPC: A Common Interface and a Compiler Hummes, J. (Univ. of Karlsruhe, D); Gerteis, W. (Digital Equipment, EARC, D) Achieving Interoperability between CORBA and DCE Applications Using Bridges Yang, Z.; Vogel, A. (Univ. of Queensland, AUS) ---------------------------------------------------------------------------- SESSION 4 : 14.00 - 15.30 SYSTEM MANAGEMENT Session Chair : Svobodova, L. (IBM Zurich, CH) Efficient and Fault-Tolerant Distributed Host Monitoring Using System-Level Diagnosis Bearden, M.; Bianchini, R. (Carnegie Mellon Univ., USA) Object Instrumentation for Distributed Applications Management Trommler, P. (Univ. Erlangen,D); Schade, A.; Kaiserswerth, M. (IBM Zurich,CH) Modeling Framework for Integrated Distributed Systems Fault Management Kaetker, S. (IBM ENC, D) ---------------------------------------------------------------------------- Break : 15.30 - 16.00 ---------------------------------------------------------------------------- SESSION 5 : 16.00 -18.00 CSCW and GROUPWARE Session Chair : Bever, M. (IBM ENC, D) Design of Multimedia Global PACS CORBA Environment Martinez, R.; Hsieh, S.-L. (Univ. of Arizona, USA) An Object Group Model and its Implementation to Support Cooperative Applications on CORBA Costa, F.M.; Madeira, E.R.M. (UNICAMP, BRA) Trader Supported Distributed Office Applications Mittasch, Ch.; Koenig, W.; Funke, R. (TU Dresden, D) ---------------------------------------------------------------------------- SESSION 6 : 16.00 -18.00 INDUSTRIAL STREAM I: APPLICATIONS Session Chair : Lin, D. (IBM Austin, USA) Highly Reliable Remote Procedure Calls Heindel, L.E.; Kasten, V.A. (Bellcore, USA) Dynamic Widely-Distributed Systems Dilley, J. (HP Labs, USA) Mobile Database Access Heuser, L. (Digital Equipment EARC, D); Schill, A.; Boehmak,W.(TU Dresden, D) CoNus - A CSCW System Supporting Synchronous, Asynchronous and Autonomous Collaborative Work Berger, M. (Siemens AG Munich, D) ---------------------------------------------------------------------------- Conference Banquet : 19.30 ---------------------------------------------------------------------------- --------------- Thursday, February 29 ------------------------------------- ---------------------------------------------------------------------------- INVITED TALK : 9.00 - 10.00 Distributed object-oriented Approaches: Trends and Perspectives Horn, C. (IONA Inc., IRL) Break : 10.00 - 10.30 ---------------------------------------------------------------------------- SESSION 7 : 10.30 -12.00 DCE: SYSTEM ASPECTS Session Chair : Gaylord, A. (Univ. Massachussetts, USA) SMT: A System Monitoring Tool for DCE Brutch, P.; Gurijala, A.; Karmarkar, A.; Walzel, K.; Marti, W.; Pooch, U. (Texas A&M Univ., USA) Performance Evaluation of a Distributed Application Performance Monitor Friedrich, R. (HP Labs, USA); Rolia, J. (Carleton Univ., CDN) A High-level Process Checkpointing and Migration Scheme for Heterogenous Distributed Systems Redhead, T. (Univ. Queensland, AUS) ---------------------------------------------------------------------------- SESSION 8 : 10.30 -12.00 INDUSTRIAL STREAM II: SYSTEM SOLUTIONS Session Chair : Heuser, L. (Digital Equ., EARC, D) DCE Application Server for CICS and IMS Marquardt,K.-H. (IBM Stuttgart, D) A 3-Tiered- Architecture in a Transactional World Pedersen, P. (Santix Software GmbH, D) A message-oriented communication service for the Portuguese Energy Market Camara, J.; Sarmento, H.; Videira, I; Martins, J. (INESC, P); Trigo, P. (Edinfor, P) Distributed High Availability in Finance Pedro, L.de (HP, E) ---------------------------------------------------------------------------- Lunch : 12.00 - 13.30 ---------------------------------------------------------------------------- SESSION 9 : 13.30 - 15.00 SERVICE TRADING Session Chair : Mittasch, C. (TU Dresden, D) Agents, Services and Electronic Markets: How do they Integrate ? Merz, M.; Lamersdorf, W. (Univ. of Hamburg, D) New Concepts for Qualitative Trader Cooperation Puder, A. ; Burger, C. (Univ. of Frankfurt / Stuttgart, D) Overview of the DRYAD Trading System Implementation Kutvonen, L. (Univ. Helsinki, FI) ---------------------------------------------------------------------------- SESSION 10 : 13.30 -15.00 INDUSTRIAL STREAM III: EXPERIENCES Session Chair : Miralles, F. (SNI Munich, D) DCE/Encina Cell Deployment Architecture for a Production Environment DeMent, J.; Hughes, S.; Pierce, K.; Ericksen, S; Szumilas, D.; Dickman, A. (US WEST Communications, Inc., USA) Client/Server Architectures 2-Tier and 3-Tier Rockler, M. (Open Horizon, USA) Distributed Object Technology in EDS Hubert,R.G. (Interactive Objects, D) Experiences in using the CORBA Implementation DSOM Koschel, A.; Leibfried, P. (FZI Karlsruhe, D) Jump-Starting DCE Application Development Zierten, S. (Open Environment Europe) ---------------------------------------------------------------------------- Break : 15.00 - 15.30 PANEL : 15.30 - 17.00 Distributed Platforms: Impacts on the Infobahn Break : 17.00 - 17.30 POSTER SESSION A : 17.30 - 19.00 APPLICATIONS OF DISTRIBUTED SYSTEMS POSTER SESSION B : 17.30 - 19.00 MIDDLEWARE AND PERFORMANCE ASPECTS ---------------------------------------------------------------------------- --------------- Friday, March 1st ----------------------------------------- ---------------------------------------------------------------------------- INVITED TALK : 9.00 - 10.00 The Impact of Mobility on Distributed Systems Platforms Davies, N. (Univ. Lancaster, UK) Break : 10.00 - 10.30 ---------------------------------------------------------------------------- SESSION 11 : 10.30 - 12.00 ODP TRADING AND SECURITY Session Chair : Schuermann, G. (GMD Fokus, D) Enabling Interworking between Heterogenous Distributed Platforms - A Gateway for Federating Traders Meyer, B.; Zlatinis, S.; Popien, C. (RWTH Aachen, D) Interoperability and Distributed Platform Design Hoffner, Y. (ANSA, UK) Security Architecture based on Secret Key and User Attribute Certificates Sameshima, Y. (Hitachi Software Engineering Co., J) ---------------------------------------------------------------------------- SESSION 12: 10.30 - 12.00 INTEROPERABILITY SOLUTIONS Session Chair : Popien, C. (RWTH Aachen, D) A Model for Evolution of Services in Distributed Systems Senivongse, T.; Utting, I.A. (Univ. of Kent, UK) Using OMG IDL to Write OODCE Applications Dilley, J. (HP Labs, USA) Transparently Programming Heterogenous Distributed Systems Wolff, Th. (FU Berlin, D) ---------------------------------------------------------------------------- Lunch : 12.00 - 13.00 ---------------------------------------------------------------------------- SESSION 13 : 13.00 - 14.30 PERFORMANCE ASPECTS Session Chair : Dasgupta, P. (Arizona State Univ., USA) Evaluating Delayed Write in a Multilevel Caching File System Muntz, D.; Honeyman,P., Antonelli,C.J. (Univ. Michigan, USA) Reducing the Cost of RPC Ibbetson, A.L.; Linington, P.F.; Penny, I.A.; Smith, A.B.; Tripp, G.E.W. (Univ. Kent, UK) Service Management using up-to-date Quality Properties Kuepper, A.; Popien, C.; Meyer, B. (RWTH Aachen, D) ---------------------------------------------------------------------------- SESSION 14 : 13.00 - 14.30 QUALITY OF SERVICE Session Chair : Geihs, K. (Univ. Frankfurt, D) QoS Support for Distributed Multimedia Communication Garcia, F.; Mauthe, A.; Yeadon, N.; Hutchison, D. (Lancaster Univ., UK) A Framework for QoS Updates in a Networking Environment Stiller, B. (Univ. of Cambridge, UK) Equus: A QoS Manager for Distributed Applications Sreenan, C.; Mishra, P.P. (AT&T Bell Labs, USA) ---------------------------------------------------------------------------- Break : 14.30 - 15.00 PANEL : 15.00 - 16.00 Distributed Platforms - How Does the Future Look Like? INDUSTRY EXHIBITION DURING WHOLE CONFERENCE ! ============================================================================ LOCATION: Dresden has become famous above all as city of the arts and is only a two hours drive from Berlin to the north and Prague to the south. Major attractions are the Semper Opera, the baroque Zwinger, the art collections (Gruenes Gewoelbe, Gemaeldegalerie) and the Frauenkirche that is currently being rebuilt. The surrounding countryside also provides many opportunities for sightseeing including Pillnitz castle, the china manufacture in Meissen and Saxon Switzerland. TRANSPORTATION: Direct flights from Frankfurt and many other European cities to Dresden airport are available. From the airport, take the airport bus to the main station. From there, take a tram to the campus area (just three stops). Or take a taxi from the airport to the campus. By train, exit at Dresden Hauptbahnhof (main station) and take a tram from there. By car, please follow the signs to Technische Universitaet on the road E55 to the campus area (direction towards Prague/Prag). FURTHER INFORMATION: For further information on the conference program, location etc. please refer to WWW: http://wwwrn.inf.tu-dresden.de/lsrn/icdp96.html Prof. Dr. Alexander Schill Dresden Univ. of Technology Dept. of Computer Science D-01062 Dresden GERMANY e-mail: ICDP96@ibc.inf.tu-dresden.de Tel: (+49) 351 4575 261 Fax: (+49) 351 4575 335 CONFERENCE CHAIRS: Prof. Dr. Alexander Schill / Dr. Christian Mittasch TU Dresden Prof. Dr. Otto Spaniol / Dr. Claudia Popien RWTH Aachen PROGRAMME COMMITTEE: H. Adeli, Ohio State University (USA) S.A. Aidarous, BNR, Ottawa (Canada) M. Bever, IBM ENC Heidelberg (Germany) P. Dasgupta, Arizona State University (USA) J. Dilley, HP Labs (USA) R.L. Fike, RNF Systems (USA) A. Gaylord, Univ. Massachussetts, Project Pilgrim (USA) K. Geihs, Univ. Frankfurt (Germany) A. Herbert, ANSA (UK) L. Heuser, DEC CEC, Karlsruhe (Germany) J. Janecek, TU Prague (Czech Republic) F. Kamoun, ENSI, Tunis (Tunisia) J. Kiho, Univ. Tartu (Estonia) D. Lin, IBM Austin (USA) P. Linington, Univ. Kent (UK) O. Martikainen, Telecom (Finland) F. Miralles, SNI Munich (Germany) E. Najm, ENST Paris (France) B. Pehrson, Swedish Inst. of Comp. Science (Sweden) R. Posch, TU Graz (Austria) P. Radford, Logica (UK) K. Raymond, Uni Brisbane (Australia) D. Ruddock, Bellcore, New Jersey (USA) H. Rudin, IBM Zurich Research Lab. (Switzerland) G. Schuermann, GMD FOKUS, Berlin (Germany) R. Soley, OMG (USA) L. Svobodova, IBM Zurich Research Lab. (Switzerland) R. Torbergsen, SINTEF RUNIT, Trondheim (Norway) W. Tuvell, OSF Cambridge (USA) ============================================================================ ============================================================================ R E G I S T R A T I O N ============================================================================ Please mark your choices and give the required information. REGISTRATION TYPE: Advance Late (by Jan. 19, 1996) (after Jan. 19, 1996) Member ___ DM 420 ___ DM 520 Non-Member ___ DM 560 ___ DM 660 Speaker ___ DM 350 ___ DM 450 Students ___ DM 40 ___ DM 80 (enclose copy of student id.) Tutorials: ___ DM 300 Tutorial numbers: ___ ___ The Tutorial fee includes participation in up to two tutorials. (Tutorials registration is only possible together with conference registration.) The conference fee includes proceedings, refreshments, and the banquet. Extra Proceedings: ___ DM 100 Extra banquet ticket: ___ DM 100 Member means member of: IFIP, IEEE, ACM, GI, ITG For the membership rate, please give organisation and membership no.: _____________________________________ Cancellation policy: Cancellation is possible until Jan. 19, 1996 and is subject to a DM 100 cancellation fee. No refunds are provided after that date. Substitutions are permitted. Various sightseeing tours can be booked on-site, including offers during the weekend of March 2 and 3, 1996. METHOD OF PAYMENT: All payments are in German Marks (1 DM equals approx. US$ 0,75). ___ Credit Card ( ___ Mastercard/Eurocard or ___ VISA only! ) Card holder name:__________________________________________ Card number:_______________________________________________ Expiration date:___________________________________________ Signature:_________________________________________________ ___ Bank Transfer Account Name: TU Dresden, ICDP96/606 Account No.: 850 015 22 Bank Name: Landeszentralbank Dresden Bank Code: 850 000 00 Reference to participant name and affiliation required ! ___ Check (must accompany registration form) Payable to TU Dresden, ICDP96. (Please add DM 30 handling fee for foreign checks.) TOTAL AMOUNT:_________________________________________________ ============================================================================ ============================================================================ A C C O M M O D A T I O N ============================================================================ If you would like us to reserve a room for you, please give the following information: Category: ___ simple ___ medium ___ luxury Occupancy: ___ single ___ double Date of arrival:_____________________________________________ Date of departure:___________________________________________ Prices range from approx. DM 100 for simple rooms over approx. DM 180 for middle class rooms up to approx. DM 300 for luxury rooms and include breakfast. (These prices are for single rooms, prices for double rooms are slightly higher.) Payments must be made directly to the hotel after confirmation. Rooms are limited, reservation until January is recommended. Date / Signature:_____________________________________________ ============================================================================ Please send form by e-mail to ICDP96@ibc.inf.tu-dresden.de . ============================================================================ THE CONFERENCE PROGRAM AND FORMS FOR REGISTRATION AND RESERVATION OF AN ACCOMMODATION ARE OFFERED IN WWW TOO : http://wwwrn.inf.tu-dresden.de/lsrn/icdp96.html ============================================================================ """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" Dr. Claudia Popien Tel.: +49 241 8021415 RWTH Aachen, Informatik IV FAX: +49 241 8888220 Ahornstr. 55 popien@informatik.rwth-aachen.de D-52056 Aachen GERMANY http://www-i4.informatik.rwth-aachen.de """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" From list-mgr@ISI.EDU Mon Nov 27 15:42:20 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03420>; Mon, 27 Nov 1995 07:44:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03388>; Mon, 27 Nov 1995 07:43:00 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA03368>; Mon, 27 Nov 1995 07:42:43 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id PAA22916; Mon, 27 Nov 1995 15:42:28 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id PAA17504; Mon, 27 Nov 1995 15:42:23 GMT Date: Mon, 27 Nov 1995 15:42:20 +0000 (GMT) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Geert Jan de Groot <GeertJan.deGroot@ripe.net> Cc: Magnus <e93_mda@it.kth.se>, mbone Subject: Re: Mrouted troubles In-Reply-To: <9511271505.AA19223@ncc.ripe.net> Message-Id: <Pine.SV4.3.91.951127154031.15019G-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 27 Nov 1995, Geert Jan de Groot wrote: > On Mon, 27 Nov 1995 14:44:56 +0100 Magnus wrote: > > FYI have I also recieved many errors on my multicast router > > tjatte.electrum.kth.se. > > > > Can people please send kill -USR1 to their mrouted and see if they see > the same as I do: [ routing table stuff deleted ] > This looks suspiciously like a byte swap problem somewhere, > and I'm debugging code which isn't helpful. > > Am I the only person seeing this? Well every time someone has sent a message complaining, I have gone and looked at my routing tables. I have yet to see a problem, so either it is very short lived or the problem is manifesting itself only in parts of the network. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Mon Nov 27 17:41:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03747>; Mon, 27 Nov 1995 07:52:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03298>; Mon, 27 Nov 1995 07:40:40 -0800 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA03291>; Mon, 27 Nov 1995 07:40:38 -0800 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id QAA04726; Mon, 27 Nov 1995 16:38:00 +0100 Message-Id: <199511271538.QAA04726@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: Geert Jan de Groot <GeertJan.deGroot@ripe.net> Cc: Magnus <e93_mda@it.kth.se>, mbone Subject: Re: Mrouted troubles In-Reply-To: Your message of "Mon, 27 Nov 1995 16:05:02 +0100." <9511271505.AA19223@ncc.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Nov 1995 16:41:07 +0100 From: Magnus <e93_mda@it.kth.se> > On Mon, 27 Nov 1995 14:44:56 +0100 Magnus wrote: > > FYI have I also recieved many errors on my multicast router > > tjatte.electrum.kth.se. > > > > Can people please send kill -USR1 to their mrouted and see if they see > the same as I do: > > Origin-Subnet From-Gateway Metric Tmr In-Vif Out-Vifs > 192.87.4/24 1 5 0 1* > 0.0.0/23 192.87.4.25 9 0 0 1* > 0.0.0.0/32 192.87.4.25 9 0 0 1* > 0.0.0/21 192.87.4.25 9 0 0 1* > 0.0.0.0/32 192.87.4.25 9 0 0 1* > 0.0.0.0/32 192.87.4.25 9 0 0 1* > 0.0.0.0/32 192.87.4.25 9 0 0 1* > 0.0.0/24 192.87.4.25 9 0 0 1* > 170.0.0.129/32 192.87.4.25 20 0 0 1* > 161.0.0.0/32 192.87.4.25 26 0 0 1* > 0.0/16 192.87.4.25 9 0 0 1* > 0.0.0/24 192.87.4.25 9 0 0 1* > 0.0.0/23 192.87.4.25 9 0 0 1* > 0.0.0/24 192.87.4.25 9 0 0 1* > 0.0.0/24 192.87.4.25 9 0 0 1* > 13.0.144.32/27 192.87.4.25 23 0 0 1* > 0.0.0/22 192.87.4.25 9 0 0 1* > 0.0.0.0/31 192.87.4.25 9 0 0 1* > 0.0.0.0/32 192.87.4.25 9 0 0 1* > 0.0.0/19 192.87.4.25 9 0 0 1* > 0.0.0.0/30 192.87.4.25 9 0 0 1* > 0.0.0.0/32 192.87.4.25 9 0 0 1* I see a large number of those comming through broodjeham.surfnet.nl > This looks suspiciously like a byte swap problem somewhere, > and I'm debugging code which isn't helpful. Maybe a bug, maybe a combination of a small bug in mrouted and some insertion problem. > Am I the only person seeing this? No. > Geert Jan > > Magnus From list-mgr@ISI.EDU Mon Nov 27 17:53:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03965>; Mon, 27 Nov 1995 08:00:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03777>; Mon, 27 Nov 1995 07:52:34 -0800 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA03770>; Mon, 27 Nov 1995 07:52:32 -0800 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id QAA04949; Mon, 27 Nov 1995 16:49:58 +0100 Message-Id: <199511271549.QAA04949@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: Graeme.Wood@ucs.ed.ac.uk Cc: Geert Jan de Groot <GeertJan.deGroot@ripe.net>, Magnus <e93_mda@it.kth.se>, mbone Subject: Re: Mrouted troubles In-Reply-To: Your message of "Mon, 27 Nov 1995 15:42:20 GMT." <Pine.SV4.3.91.951127154031.15019G-100000@scorpio.ucs.ed.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Nov 1995 16:53:09 +0100 From: Magnus <e93_mda@it.kth.se> > On Mon, 27 Nov 1995, Geert Jan de Groot wrote: > > > Can people please send kill -USR1 to their mrouted and see if they see > > the same as I do: > > [ routing table stuff deleted ] > > > This looks suspiciously like a byte swap problem somewhere, > > and I'm debugging code which isn't helpful. > > > > Am I the only person seeing this? > > Well every time someone has sent a message complaining, I have gone and > looked at my routing tables. I have yet to see a problem, so either it is > very short lived or the problem is manifesting itself only in parts of > the network. Ok, for those with interest you may take a peak at: ftp://knatte.electrum.kth.se/mrouted.dump ftp://knatte.electrum.kth.se/mrouted.cache and the 6202 entries versions are at: ftp://knatte.electrum.kth.se/mrouted.dump.1 ftp://knatte.electrum.kth.se/mrouted.cache.1 These are the dumps from tjatte.electrum.kth.se Magnus From list-mgr@ISI.EDU Mon Nov 27 18:04:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04739>; Mon, 27 Nov 1995 08:15:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04237>; Mon, 27 Nov 1995 08:06:09 -0800 Received: from rype.runit.sintef.no by venera.isi.edu (5.65c/5.61+local-22) id <AA04230>; Mon, 27 Nov 1995 08:06:07 -0800 Received: from runit.sintef.no (localhost [127.0.0.1]) by rype.runit.sintef.no (8.6.11/8.6.9) with ESMTP id RAA26375; Mon, 27 Nov 1995 17:04:38 +0100 Message-Id: <199511271604.RAA26375@rype.runit.sintef.no> To: GeertJan.deGroot@ripe.net Cc: e93_mda@it.kth.se, mbone Subject: Re: Mrouted troubles From: Havard.Eidnes@runit.sintef.no In-Reply-To: Your message of "Mon, 27 Nov 1995 16:05:02 +0100" References: <9511271505.AA19223@ncc.ripe.net> X-Mailer: Mew beta version 0.96 on Emacs 19.29.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Nov 1995 17:04:37 +0100 Sender: he@runit.sintef.no > Can people please send kill -USR1 to their mrouted and see if they see > the same as I do: Yep, we do. Lots of various prefix-lengths of 0.0.0.0, lots of host routes, lots of /30, /29 and /28 routes. Using mtrace to try to trace back to these origins gives no clue (for "randomly" picked "strange" routes the traces go off in different directions). I suspect this is more severe than a simple byte swap problem. Why then would I see umpteen 0/8 entries? - H=E5vard From list-mgr@ISI.EDU Mon Nov 27 06:20:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05428>; Mon, 27 Nov 1995 08:29:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04903>; Mon, 27 Nov 1995 08:20:04 -0800 Received: from beantown.lcs.mit.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA04896>; Mon, 27 Nov 1995 08:20:02 -0800 Received: by beantown.lcs.mit.edu (8.7.1/SGI) for mbone@isi.edu id QAA05660; Mon, 27 Nov 1995 16:20:01 GMT From: rabatin@beantown.lcs.mit.edu (George Rabatin) Message-Id: <199511271620.QAA05660@beantown.lcs.mit.edu> Subject: MBONE reservation request: Dec12-14 To: mbone Date: Mon, 27 Nov 1995 11:20:01 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text The MIT Laboratory for Computer Science is planning an MBONE presentation of selected sessions of the Fourth International World Wide Web Conference, "The Web Revolution", on Dec. 12th, 13th, and 14th, 1995. The conference will be held in Boston, MA. Conference web pages can be found at: http://www.w3.org/pub/Conferences/WWW4/ More detailed information about the multicast can be found at http://beantown.lcs.mit.edu/mbone/www4.html (up to date sessions and times)... The Lab would like to reserve MBONE bandwidth for 2 simultaneous presentations. The presentations will occur during the following times: date time(EST) time(GMT) session/speakers -------------------------------------------------------------------------- 12 Dec 95 8:00-18:00 13:00-23:00 live presentation 13 Dec 95 20:00*-4:00 01:00-09:00 rebroadcast of days events 13 Dec 95 8:00-18:00 13:00-23:00 live presentation 14 Dec 95 20:00**-4:00 01:00-09:00 rebroadcast of days events *=12 Dec **=13 Dec If anyone has a conflicting event, please contact me, rabatin@lcs.mit.edu, so that we can resolve the scheduling issues. This information has been posted to the Mbone Broadcast Schedule: http://www.msri.org:80/mbone/ Thanks, George Rabatin MIT Lab for Computer Science rabatin@lcs.mit.edu From list-mgr@ISI.EDU Fri Nov 27 13:33:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06342>; Mon, 27 Nov 1995 08:47:17 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06303>; Mon, 27 Nov 1995 08:46:20 -0800 Received: from relay2.UU.NET by venera.isi.edu (5.65c/5.61+local-22) id <AA06296>; Mon, 27 Nov 1995 08:46:17 -0800 Received: from cixgate by relay2.UU.NET with SMTP id QQzrrm06376; Mon, 27 Nov 1995 11:44:41 -0500 (EST) Received: from gw.3Com.COM by cixgate (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA04326; Mon, 27 Nov 95 08:52:51 PST Received: from hqsmtp.OPS.3Com.COM by gw.3Com.COM with SMTP id AA27241 (5.65c/IDA-1.4.4 for <mbone@isi.edu>); Mon, 27 Nov 1995 08:29:42 -0800 Received: by hqsmtp.ops.3com.com (IBM OS/2 SENDMAIL VERSION 1.3.14/1.0) id AA0707; Mon, 27 Nov 95 08:46:22 -0800 Message-Id: <9511271646.AA0707@hqsmtp.ops.3com.com> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id C2C1798CAD27216300256281005AA10C; Mon, 27 Nov 95 08:46:22 EDT To: mbone <mbone> From: Frank Ridgewell/C/GB/3Com <Frank_Ridgewell@3mail.3Com.COM> Date: 27 Nov 95 17:33:54 EDT Subject: MBONE access Mime-Version: 1.0 Content-Type: Text/Plain to who it may concern, I'm enquiring about access to the MBONE multicast network, and would be grateful if you could give me information about procedures for gaining access. regards Frank Ridgewell From list-mgr@ISI.EDU Mon Nov 27 00:35:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06377>; Mon, 27 Nov 1995 08:47:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05757>; Mon, 27 Nov 1995 08:36:14 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA05748>; Mon, 27 Nov 1995 08:36:13 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14562(6)>; Mon, 27 Nov 1995 08:35:48 PST Received: by crevenia.parc.xerox.com id <177478>; Mon, 27 Nov 1995 08:35:35 -0800 From: Bill Fenner <fenner@parc.xerox.com> To: GeertJan.deGroot@ripe.net, Graeme.Wood@ucs.ed.ac.uk Subject: Re: Mrouted troubles Cc: e93_mda@it.kth.se, mbone Message-Id: <95Nov27.083535pst.177478@crevenia.parc.xerox.com> Date: Mon, 27 Nov 1995 08:35:33 PST Graeme Wood wrote: >Well every time someone has sent a message complaining, I have gone and >looked at my routing tables. I have yet to see a problem, so either it is >very short lived or the problem is manifesting itself only in parts of >the network. The problem will not pass through a 2.2 router; it might not pass through Ciscos, so if you are seperated from the problem by one of those you won't see it. The problem doesn't appear to be byte swapping as Geert Jan suggests; it looks more like it is a byte offset problem -- someone dropped a byte while creating a report so then the metrics and netmasks start getting offsetted. There was a bug in 3.5 having to do with the default route that could cause this; unfortunately, none of my tools help to track it down other than doing "kill -USR1 `cat /etc/mrouted.pid`" on each router. mtrace isn't able to trace these bogus routes. (An example of one of these bogus route reports: Netmask 255.0.0.0 129.0.0.0, metric 62* 0.0.0.0, metric 0 161.0.0.0, metric 32 Netmask 255.0.183.191 0.0.0.0, metric 0 60.61.0.0, metric 32 Netmask 255.154.186.0 185.0.0.0, metric 0 0.188.0.0, metric 59* Netmask 255.0.55.0 161.32.0.0, metric 61* Note the nonsense netmasks. They are what really confuses mrouted. If anyone is injecting a default route, please stop and we will see if this calms down. Thanks, Bill From list-mgr@ISI.EDU Mon Nov 27 19:04:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07626>; Mon, 27 Nov 1995 09:07:21 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07349>; Mon, 27 Nov 1995 09:03:23 -0800 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA07342>; Mon, 27 Nov 1995 09:03:21 -0800 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id SAA06238 for <mbone@isi.edu>; Mon, 27 Nov 1995 18:00:51 +0100 Message-Id: <199511271700.SAA06238@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: mbone Subject: Small debug helpers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Nov 1995 18:04:03 +0100 From: Magnus <e93_mda@it.kth.se> Hi! Some small scripts that migth speed mrouted debugging somewhat: mdump: ---------- #!/bin/sh kill -USR2 `cat /etc/mrouted.pid` ---------- mdumpcache: ---------- #!/bin/sh kill -USR1 `cat /etc/mrouted.pid` ---------- showdump: ---------- #!/bin/sh more /usr/tmp/mrouted.dump ---------- showcache: ---------- #!/bin/sh more /usr/tmp/mrouted.cache ---------- newmconf: ---------- #!/bin/sh kill -HUP `cat /etc/mrouted.pid` ---------- Not very big, but migth get in handy. Magnus From list-mgr@ISI.EDU Mon Nov 27 06:58:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07652>; Mon, 27 Nov 1995 09:07:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06951>; Mon, 27 Nov 1995 08:58:05 -0800 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA06942>; Mon, 27 Nov 1995 08:58:04 -0800 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.7.1/8.7.1) id LAA18485; Mon, 27 Nov 1995 11:58:14 -0500 (EST) From: Dave Thaler <thalerd@eecs.umich.edu> Message-Id: <199511271658.LAA18485@dip.eecs.umich.edu> Subject: Re: Routing entires To: e93_mda@it.kth.se (Magnus) Date: Mon, 27 Nov 1995 11:58:12 -0500 (EST) Cc: mbone, magda@it.kth.se In-Reply-To: <199511271414.PAA02702@piraya.electrum.kth.se> from "Magnus" at Nov 27, 95 03:17:24 pm X-Mailer: ELM [version 2.4 PL24 PGP1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I currently have 6206 routing entries on my machine. Trouble began around 6am GMT today when the routing table size went from about 2700 to over 4000 and grew to over 13600 by 11am GMT. There are lots of bad routes in the table, including lots of net 0.0.0.0 routes, which one cannot mtrace to apparently. However, 161.0.0/24 is another example of a suspect route. Specifically, it appears to be actually advertising a route of: net 161.0.0.0 mask 255.0.52.0 An mtrace to 161.0.0.1 led to rtr-900-b28-cf.gsfc.nasa.gov (128.183.251.63) [cisco 10.2] Perhaps this, or some other cisco router near there is configured incorrectly. This box doesn't respond to public SNMP queries, so I don't know who the contact person is. Dave Thaler From list-mgr@ISI.EDU Mon Nov 27 07:16:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08762>; Mon, 27 Nov 1995 09:27:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08099>; Mon, 27 Nov 1995 09:15:59 -0800 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA08092>; Mon, 27 Nov 1995 09:15:57 -0800 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.7.1/8.7.1) id MAA19277; Mon, 27 Nov 1995 12:16:14 -0500 (EST) From: Dave Thaler <thalerd@eecs.umich.edu> Message-Id: <199511271716.MAA19277@dip.eecs.umich.edu> Subject: Routing problem source: satellite-sfc.wide.ad.jp? To: e93_mda@it.kth.se (Magnus) Date: Mon, 27 Nov 1995 12:16:13 -0500 (EST) Cc: mbone, magda@it.kth.se In-Reply-To: <199511271414.PAA02702@piraya.electrum.kth.se> from "Magnus" at Nov 27, 95 03:17:24 pm X-Mailer: ELM [version 2.4 PL24 PGP1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit An mtrace to 0.0.0.1 eventually leads through nasa to satellite-sfc.wide.ad.jp (133.4.11.22) [...] -8 morgul.barrnet.net (192.31.48.211) DVMRP thresh^ 32 -13673 ms Wrong interface -9 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 64 -14675 ms -10 mbone.inoc.imnet.ad.jp (202.241.2.71) DVMRP thresh^ 64 -84164 ms -11 wnoc-tyo.wide.ad.jp (133.4.3.2) DVMRP thresh^ 32 -13447 ms -12 sh.wide.ad.jp (133.4.2.1) DVMRP thresh^ 32 -157843 ms -13 * satellite-sfc.wide.ad.jp (133.4.11.22) DVMRP thresh^ 1 -13462 ms -14 ? (0.0.0.1) satellite-sfc.wide.ad.jp doesn't seem to be responding to mrinfo or SNMP. Dave Thaler From list-mgr@ISI.EDU Mon Nov 27 05:18:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08503>; Mon, 27 Nov 1995 09:22:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08211>; Mon, 27 Nov 1995 09:18:50 -0800 Received: from indy23.gclab.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA08204>; Mon, 27 Nov 1995 09:18:47 -0800 Received: (from ccshag@localhost) by indy23.gclab.missouri.edu (8.7.1/8.7.1) id LAA27838; Mon, 27 Nov 1995 11:18:30 -0600 (CST) Date: Mon, 27 Nov 1995 11:18:29 -0600 (CST) From: "Paul 'Shag' Walmsley" <ccshag@cclabs.missouri.edu> X-Sender: ccshag@indy23.gclab.missouri.edu To: Magnus <e93_mda@it.kth.se> Cc: Graeme.Wood@ucs.ed.ac.uk, Geert Jan de Groot <GeertJan.deGroot@ripe.net>, Magnus <e93_mda@it.kth.se>, mbone Subject: Re: Mrouted troubles In-Reply-To: <199511271549.QAA04949@piraya.electrum.kth.se> Message-Id: <Pine.SGI.3.91.951127105345.27685B-100000@indy23.gclab.missouri.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 27 Nov 1995, Magnus wrote: > > On Mon, 27 Nov 1995, Geert Jan de Groot wrote: > > > > > Can people please send kill -USR1 to their mrouted and see if they see > > > the same as I do: Yes, we see the same bogus routes here. (Graeme Wood, perhaps?, wrote:) > > Well every time someone has sent a message complaining, I have gone and > > looked at my routing tables. I have yet to see a problem, so either it is > > very short lived or the problem is manifesting itself only in parts of > > the network. Our multicast routers are all running either 3.4 or 3.6, and we're hanging off of dc-mbone-2.sprintlink.net (204.117.214.14). dc-mbone-2 is running mrouted 3.6 and is attached to the MBONE via MBONE1.UU.NET. I played around with mtrace a little bit and it appears that the bogus routes extend at least as far as MBONE1.UU.NET, MBONE2.UU.NET, mae-bone.psi.net, VINEGAR.SESQUI.NET, mbone.sdsc.edu, morgul.barrnet.net, and mbone.nsi.nasa.gov. - Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu> "Praise and blame alike mean nothing." -- Virginia Woolf From list-mgr@ISI.EDU Mon Nov 27 02:27:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13546>; Mon, 27 Nov 1995 10:36:08 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12885>; Mon, 27 Nov 1995 10:32:41 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA12837>; Mon, 27 Nov 1995 10:32:19 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14791(6)>; Mon, 27 Nov 1995 10:28:11 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Mon, 27 Nov 1995 10:27:59 -0800 To: Dave Hayes <dave@kachina.jetcafe.org> Cc: Bill Fenner <fenner@parc.xerox.com>, mbone Subject: Re: Mrouted troubles In-Reply-To: Your message of "Mon, 27 Nov 95 10:15:57 PST." <199511271815.KAA28951@kachina.jetcafe.org> Date: Mon, 27 Nov 1995 10:27:53 PST Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov27.102759pst.177478@crevenia.parc.xerox.com> In message <199511271815.KAA28951@kachina.jetcafe.org> you write: >[As an aside, why is there a 2 hour turnaround delay on the mbone list?] I think I'm pretty far down on the list, since I just changed addresses in February. >>If anyone is injecting a default route, please stop and we will see if this >>calms down. > >I don't think I am. I'm running 3.6. How do I tell? If you're running mrouted, then you're not injecting a default route; unmodified mrouteds are not capable of sourcing a default route (but can pass them on, of course). I'm really not sure how to track this one down, since there are hundreds of 'default' routes out there. This at least points out some more error-checking for mrouted... Bill From list-mgr@ISI.EDU Mon Nov 27 02:13:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12316>; Mon, 27 Nov 1995 10:24:50 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11698>; Mon, 27 Nov 1995 10:15:32 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA11688>; Mon, 27 Nov 1995 10:15:31 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16211(9)>; Mon, 27 Nov 1995 10:14:25 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 27 Nov 1995 10:14:08 -0800 To: Dave Thaler <thalerd@eecs.umich.edu> Cc: mbone, deering@parc.xerox.com Subject: Re: Routing problem source: satellite-sfc.wide.ad.jp? In-Reply-To: thalerd's message of Mon, 27 Nov 95 09:16:13 -0800. <199511271716.MAA19277@dip.eecs.umich.edu> Date: Mon, 27 Nov 1995 10:13:56 PST Sender: Steve Deering <deering@parc.xerox.com> From: Steve Deering <deering@parc.xerox.com> Message-Id: <95Nov27.101408pst.75270@digit.parc.xerox.com> Has anyone tried cutting off a piece of well-behaved MBone topology from the rest of the MBone to see if the bogus routes go away there? If so, maybe we can drop the tunnel to Japan and see if the MBone heals. Steve From list-mgr@ISI.EDU Mon Nov 27 01:50:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11378>; Mon, 27 Nov 1995 10:12:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10599>; Mon, 27 Nov 1995 10:01:47 -0800 Received: from elroy.jpl.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA10580>; Mon, 27 Nov 1995 10:01:38 -0800 Received: from isolar.tujunga.ca.us by elroy.jpl.nasa.gov (4.1/SMI-4.1+DXR) id AA06451; Mon, 27 Nov 95 10:01:32 PST Received: from localhost.tujunga.ca.us by isolar.Tujunga.CA.US (4.1/SATAN-6.6.6) id AA16283; Mon, 27 Nov 95 09:51:00 PST Message-Id: <9511271751.AA16283@isolar.Tujunga.CA.US> X-Mailer: exmh version 1.5.3 12/28/94 To: mbone Cc: dave@kachina.jetcafe.org Subject: Re: Mrouted troubles Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Nov 1995 09:50:44 -0800 From: Greg Earle <earle@isolar.Tujunga.CA.US> > In looking through the logs I find that this message seemed to cycle > through many different IP numbers: > > Nov 26 22:18:55 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports > out-of-range metric 0 for origin default > Nov 26 22:19:10 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports an > invalid origin (0.44.0.0) and/or mask (ff00ad00) > Nov 26 22:19:16 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports > out-of-range metric 0 for origin 179.0/15 > Nov 26 22:19:16 elxr mrouted[18896]: [W] warning - 137.78.80.130 reports > out-of-range metric I'm also seeing these on the machine mentioned above (137.78.80.130, elroy.JPL.NASA.GOV): elroy:1:30 [/var/log] % sudo egrep mrouted daemonlog | tail -6 Nov 27 09:45:17 elroy mrouted[219]: warning - 128.149.24.127 reports an invalid origin (0.188.0.0) and/or mask (ff00a500) Nov 27 09:45:42 elroy mrouted[219]: warning - 128.149.24.127 reports out-of-range metric 0 for origin 160.0.27/24 Nov 27 09:45:42 elroy mrouted[219]: warning - 128.149.24.127 reports out-of-range metric 0 for origin 57.17.0/24 Nov 27 09:45:42 elroy mrouted[219]: warning - 128.149.24.127 reports out-of-range metric 0 for origin 21.0.31/24 Nov 27 09:45:42 elroy mrouted[219]: warning - 128.149.24.127 reports an invalid origin (0.160.0.0) and/or mask (ff00a500) Nov 27 09:45:42 elroy mrouted[219]: warning - 128.149.24.127 reports out-of-range metric 0 for origin 0.0.0/24 The 128.149.24.127 machine (temblor.JPL.NASA.GOV) is another of mine, it sits on a subnet which "elroy" is attached to, and redistributes multicast traffic onto an internal FDDI/CDDI ring in my work area. It's also complaining: temblor:1:28 [/var/adm] % tail -6messages Nov 27 09:48:02 temblor mrouted[206]: warning - 128.149.24.3 reports an invalid origin (0.20.0.0) and/or mask (ff009600) Nov 27 09:48:02 temblor mrouted[206]: warning - 128.149.24.3 reports an invalid origin (0.15.0.0) and/or mask (ff009600) Nov 27 09:48:02 temblor mrouted[206]: warning - 128.149.24.3 reports an invalid origin (0.14.0.0) and/or mask (ff009600) Nov 27 09:48:02 temblor mrouted[206]: warning - 128.149.24.3 reports an invalid origin (0.13.0.0) and/or mask (ff009600) Nov 27 09:48:02 temblor mrouted[206]: warning - 128.149.24.3 reports an invalid origin (0.13.0.0) and/or mask (ff009600) Nov 27 09:48:02 temblor mrouted[206]: warning - 128.149.24.3 reports an invalid origin (0.4.0.0) and/or mask (ff009600) Note that it's complaining about its upstream neighbor, and its upstream neighbor is complaining about its downstream neighbor. (Interestingly, "elroy" isn't complaining about "elxr", the tunnel source that both "elroy" and his "kachina" machine have in common.) I've killed the "mrouted" on both hosts, then I restarted "mrouted" on "elroy" and later on "temblor". I'm still getting a few of the "reports out-of-range metric 0 for origin NN.N/NN" errors and an occasional "reports an invalid origin (N.N.N.NNN) and/or mask (XXXXXXXX)" error, but at least it's not - yet - a never-ending constant stream of them. On the other hand, the downstream neighbor is now getting the "ip_mrouter socket queue full" problem, so I guess I'll have to kill off both mrouted's :-( I'm running the 3.5 ipmulti release - and mrouted 3.5 - on both hosts. (If this is something that's curable by moving to mrouted 3.6, please let us know. Bill?) - Greg P.S. Some sort of interpretation of the above messages would be appreciated (-: From list-mgr@ISI.EDU Mon Nov 27 02:15:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12580>; Mon, 27 Nov 1995 10:28:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11737>; Mon, 27 Nov 1995 10:16:12 -0800 Received: from kachina.jetcafe.org ([206.117.70.2]) by venera.isi.edu (5.65c/5.61+local-22) id <AA11730>; Mon, 27 Nov 1995 10:16:11 -0800 Received: from [127.0.0.1] ([127.0.0.1]) by kachina.jetcafe.org (8.6.10/8.6.6) with SMTP id KAA28951; Mon, 27 Nov 1995 10:15:57 -0800 Message-Id: <199511271815.KAA28951@kachina.jetcafe.org> To: Bill Fenner <fenner@parc.xerox.com> Cc: mbone Subject: Re: Mrouted troubles Date: Mon, 27 Nov 1995 10:15:57 -0800 From: Dave Hayes <dave@kachina.jetcafe.org> [As an aside, why is there a 2 hour turnaround delay on the mbone list?] Bill Fenner <fenner@parc.xerox.com> writes: >There was a bug in 3.5 having to do with the default route that could cause >this; unfortunately, none of my tools help to track it down other than doing >"kill -USR1 `cat /etc/mrouted.pid`" on each router. mtrace isn't able to >trace these bogus routes. Is -that- why you wanted us to go to 3.6? 8-) >If anyone is injecting a default route, please stop and we will see if this >calms down. I don't think I am. I'm running 3.6. How do I tell? There's over 400K of stuff generated by a kill -USR1... ------ >>> Dave Hayes - Altadena CA, USA - dave@jetcafe.org <<< "Better to be safe than to be sorry" is a remark of value only when these are the actual alternatives. From list-mgr@ISI.EDU Mon Nov 27 22:03:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11753>; Mon, 27 Nov 1995 10:16:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10854>; Mon, 27 Nov 1995 10:04:27 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA10847>; Mon, 27 Nov 1995 10:04:23 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id UAA07375; Mon, 27 Nov 1995 20:03:55 +0200 Date: Mon, 27 Nov 1995 20:03:55 +0200 Message-Id: <199511271803.UAA07375@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Dave Thaler <thalerd@eecs.umich.edu> Cc: e93_mda@it.kth.se (Magnus), mbone, magda@it.kth.se Subject: Routing problem source: satellite-sfc.wide.ad.jp? In-Reply-To: <199511271716.MAA19277@dip.eecs.umich.edu> References: <199511271414.PAA02702@piraya.electrum.kth.se> <199511271716.MAA19277@dip.eecs.umich.edu> Dave Thaler writes: > An mtrace to 0.0.0.1 eventually leads through nasa to > satellite-sfc.wide.ad.jp (133.4.11.22) > > [...] > -8 morgul.barrnet.net (192.31.48.211) DVMRP thresh^ 32 -13673 ms Wrong interface > -9 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 64 -14675 ms > -10 mbone.inoc.imnet.ad.jp (202.241.2.71) DVMRP thresh^ 64 -84164 ms > -11 wnoc-tyo.wide.ad.jp (133.4.3.2) DVMRP thresh^ 32 -13447 ms > -12 sh.wide.ad.jp (133.4.2.1) DVMRP thresh^ 32 -157843 ms > -13 * satellite-sfc.wide.ad.jp (133.4.11.22) DVMRP thresh^ 1 -13462 ms > -14 ? (0.0.0.1) > > satellite-sfc.wide.ad.jp doesn't seem to be responding to mrinfo or SNMP. > I noticed a while ago a bogus set of mroutes appearing in Japan: OLD mrouteds 133.27.221.52 (news2.mag.keio.ac.jp): 39 secs 133.27.229.4 (leo-tpddi0.mma.mag.keio.ac.jp): 12 mins 22 secs 133.19.1.54 (jhow.san.cs.ritsumei.ac.jp): 26 secs 133.19.1.16 (selab.selab.cs.ritsumei.ac.jp): 27 secs 133.19.1.50 (polaris.cv.cs.ritsumei.ac.jp): 3 mins 34 secs 133.19.1.44 (pajero.maru.cs.ritsumei.ac.jp): 3 mins 34 secs 133.19.1.18 (jotu.jotu.cs.ritsumei.ac.jp): 11 mins 49 secs 133.19.1.56 (picasso.img.cs.ritsumei.ac.jp): 27 secs 133.19.1.52 (zeus.muse.cs.ritsumei.ac.jp): 3 mins 34 secs (information courtesy of JIPS mbone statistics) The machines seem to be running NEWS-OS and seem to be running some reincarnated obsolete code. Of course this is just a hunch but still maybe worth investigating? Doing mrinfo on those machines does not reveal any active external links but that might be wrong taking account the old version of code. Pete From list-mgr@ISI.EDU Tue Nov 28 13:05:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15661>; Mon, 27 Nov 1995 11:08:21 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15429>; Mon, 27 Nov 1995 11:05:21 -0800 Received: from shonan.sfc.wide.ad.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA15412>; Mon, 27 Nov 1995 11:05:17 -0800 Received: (from nishida@localhost) by shonan.sfc.wide.ad.jp (8.6.11+2.5Wb2/3.3Wb4-shonan) id EAA25072; Tue, 28 Nov 1995 04:05:09 +0900 Message-Id: <199511271905.EAA25072@shonan.sfc.wide.ad.jp> To: thalerd@eecs.umich.edu Cc: mbone Subject: Re: Routing problem source: satellite-sfc.wide.ad.jp? Reply-To: nishida@sfc.wide.ad.jp In-Reply-To: Your message of "Mon, 27 Nov 1995 12:16:13 -0500 (EST)" References: <199511271716.MAA19277@dip.eecs.umich.edu> X-Mailer: Mew beta version 0.98 on Emacs 18.59.3, Mule 1.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 28 Nov 1995 04:05:09 +0900 From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp> >>>>> On Mon, 27 Nov 1995 12:16:13 -0500 (EST), Dave Thaler <thalerd@eecs.umich.edu> said: >> satellite-sfc.wide.ad.jp doesn't seem to be responding to mrinfo or SNMP. Today, we moved satellite-sfc.wide.ad.jp to another segment. Although we use mrouted 3.6, if we had made some mistakes, we're going to fix them AS SOON AS POSSIBLE. If you find something about satellite-sfc, please let us know. If we made today's big trouble, we apologize sincerely to all internet people. -- Yoshifumi Nishida Keio UNIV. nishida@sfc.wide.ad.jp From list-mgr@ISI.EDU Mon Nov 27 03:53:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18909>; Mon, 27 Nov 1995 11:58:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18628>; Mon, 27 Nov 1995 11:55:00 -0800 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA18620>; Mon, 27 Nov 1995 11:54:58 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id LAA23340; Mon, 27 Nov 1995 11:53:48 -0800 Date: Mon, 27 Nov 1995 11:53:48 -0800 From: Dino Farinacci <dino@cisco.com> Message-Id: <199511271953.LAA23340@stilton.cisco.com> To: thalerd@eecs.umich.edu Cc: e93_mda@it.kth.se, mbone, magda@it.kth.se In-Reply-To: Dave Thaler's message of Mon, 27 Nov 1995 11:58:12 -0500 (EST) <199511271658.LAA18485@dip.eecs.umich.edu> Subject: Routing entires >> An mtrace to 161.0.0.1 led to >> rtr-900-b28-cf.gsfc.nasa.gov (128.183.251.63) [cisco 10.2] This router doesn't have any DVMRP tunnels: 174:dino@dino-ss20% mrinfo rtr-900-b28-cf.gsfc.nasa.gov 128.183.251.63 (rtr-900-b28-cf.gsfc.nasa.gov) [version 10.2]: 128.183.33.1 -> 0.0.0.0 (local) [1/0/pim/querier] 128.183.34.129 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] 128.183.253.3 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] I wonder if anyone knows if this router is doing DVMRP interaction on the 128.183.33.1 interface. Can someone check on this and send the configuration file and a "show version" to multicast-support@cisco.com. Thanks. Dino From list-mgr@ISI.EDU Mon Nov 27 06:03:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27379>; Mon, 27 Nov 1995 14:05:46 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27218>; Mon, 27 Nov 1995 14:02:51 -0800 Received: from san_marcos.csusm.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA27209>; Mon, 27 Nov 1995 14:02:49 -0800 Received: by san_marcos.csusm.edu (AIX 4.1/UCB 5.64/4.03) id AA18456; Mon, 27 Nov 1995 14:03:54 -0800 Date: Mon, 27 Nov 1995 14:03:54 -0800 (PST) From: Mark Chorak <chorak1@coyote.csusm.edu> X-Sender: chorak1@san_marcos.csusm.edu To: mbone Subject: AIX mrouted port! In-Reply-To: <199511270935.EAA02278@radicalmedia.com> Message-Id: <Pine.A32.3.91.951127140014.18716C-100000@san_marcos.csusm.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Us AIXer's are starving for a mrouted port that has pruning capabilities. Has anybody out there have any suggestions? Mark From list-mgr@ISI.EDU Mon Nov 27 12:42:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29701>; Mon, 27 Nov 1995 14:44:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29653>; Mon, 27 Nov 1995 14:43:08 -0800 Received: from wizard.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA29645>; Mon, 27 Nov 1995 14:43:07 -0800 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA02330; Mon, 27 Nov 95 17:42:50 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9511272242.AA02330@wizard.gsfc.nasa.gov> Subject: Re: Routing entires To: dino@cisco.com (Dino Farinacci) Date: Mon, 27 Nov 1995 17:42:50 -0500 (EST) Cc: thalerd@eecs.umich.edu, e93_mda@it.kth.se, mbone, magda@it.kth.se In-Reply-To: <199511271953.LAA23340@stilton.cisco.com> from "Dino Farinacci" at Nov 27, 95 11:53:48 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1523 > >> An mtrace to 161.0.0.1 led to > >> rtr-900-b28-cf.gsfc.nasa.gov (128.183.251.63) [cisco 10.2] > > This router doesn't have any DVMRP tunnels: Dino, It had a DVMRP tunnel to mbone2-f.gsfc.nasa.gov (128.183.242.17), but I shut it down because the MBone problems were causing our ciscos that are running PIM to crash periodically (that had been running fine for quite some time without any problems previously). I shut the MBone access down by doing a: no ip multicast-routing no interface tunnel0 However, I did not reload the router earlier. I have now done that, in case the router was left in a weird state. I don't know why the mtrace would lead to rtr-900-b28-cf with the MBone tunnel shut down. > 174:dino@dino-ss20% mrinfo rtr-900-b28-cf.gsfc.nasa.gov > 128.183.251.63 (rtr-900-b28-cf.gsfc.nasa.gov) [version 10.2]: > 128.183.33.1 -> 0.0.0.0 (local) [1/0/pim/querier] > 128.183.34.129 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] > 128.183.253.3 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] These are the subnets which have been set up to normally have MBone connectivity. > I wonder if anyone knows if this router is doing DVMRP interaction on the > 128.183.33.1 interface. Can someone check on this and send the configuration > file and a "show version" to multicast-support@cisco.com. Thanks. There's no DVMRP on the 128.183.33 subnet, at least that I'm aware of. I'll send the requested information to multicast-support@cisco.com, just in case it's helpful. > Dino -Bill From list-mgr@ISI.EDU Tue Nov 28 03:18:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02284>; Mon, 27 Nov 1995 15:28:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01838>; Mon, 27 Nov 1995 15:18:32 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA01831>; Mon, 27 Nov 1995 15:18:30 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id BAA08181; Tue, 28 Nov 1995 01:18:15 +0200 Date: Tue, 28 Nov 1995 01:18:15 +0200 Message-Id: <199511272318.BAA08181@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: bill@wizard.gsfc.nasa.gov (Bill Fink) Cc: mbone Subject: Re: Routing entires In-Reply-To: <9511272242.AA02330@wizard.gsfc.nasa.gov> References: <199511271953.LAA23340@stilton.cisco.com> <9511272242.AA02330@wizard.gsfc.nasa.gov> Bill Fink writes: > However, I did not reload the router earlier. I have now done that, > in case the router was left in a weird state. I don't know why the > mtrace would lead to rtr-900-b28-cf with the MBone tunnel shut down. > Cisco has never been good at cleaning things if an interface is deleted or disappears for some reason. Multicast is no exeption. You should reverse the settings on an interface before deleting, for example you might type: int tun 0 no ip address no ip pim dense-mode no tunnel mode dvmrp no int tun 0 etc.... Pete From list-mgr@ISI.EDU Mon Nov 27 13:38:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AB03420>; Mon, 27 Nov 1995 15:42:55 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03084>; Mon, 27 Nov 1995 15:39:45 -0800 Received: from wizard.gsfc.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA03076>; Mon, 27 Nov 1995 15:39:42 -0800 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA02408; Mon, 27 Nov 95 18:38:38 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9511272338.AA02408@wizard.gsfc.nasa.gov> Subject: Re: Routing entires To: dino@cisco.com (Dino Farinacci) Date: Mon, 27 Nov 1995 18:38:37 -0500 (EST) Cc: thalerd@eecs.umich.edu, e93_mda@it.kth.se, mbone, magda@it.kth.se In-Reply-To: <199511271953.LAA23340@stilton.cisco.com> from "Dino Farinacci" at Nov 27, 95 11:53:48 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3374 > >> An mtrace to 161.0.0.1 led to > >> rtr-900-b28-cf.gsfc.nasa.gov (128.183.251.63) [cisco 10.2] For whatever it's worth, an mtrace to 161.0.0.1 from one of my systems a little while ago resulted in the following: grunt2b# mtrace 161.0.0.1 Mtrace from 161.0.0.1 to 128.183.50.28 via group 224.2.0.1 Querying full reverse path... 0 grunt2b.gsfc.nasa.gov (128.183.50.28) -1 mbone2.gsfc.nasa.gov (128.183.50.34) DVMRP thresh^ 1 1554 ms -2 mbone-cf.gsfc.nasa.gov (128.183.251.129) DVMRP thresh^ 16 1561 ms -3 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 32 835 ms -4 mbone.sdsc.edu (198.17.47.39) DVMRP thresh^ 64 1618 ms -5 VINEGAR.SESQUI.NET (128.241.0.91) DVMRP thresh^ 64 2721 ms -6 dec3800-1-fddi-0.Dallas.mci.net (204.70.114.29) DVMRP thresh^ 32 117352 ms -7 dec3800-1-fddi-1.LosAngeles.mci.net (204.70.170.45) DVMRP thresh^ 1 -230707 ms -8 dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61) DVMRP thresh^ 1 181401 ms -9 morgul.barrnet.net (192.31.48.211) DVMRP thresh^ 32 2893 ms Wrong interface Round trip time 1287 ms Then a little while later, it changed to: grunt2b# mtrace 161.0.0.1 Mtrace from 161.0.0.1 to 128.183.50.28 via group 224.2.0.1 Querying full reverse path... 0 grunt2b.gsfc.nasa.gov (128.183.50.28) -1 mbone2.gsfc.nasa.gov (128.183.50.34) DVMRP thresh^ 1 1526 ms -2 mbone-cf.gsfc.nasa.gov (128.183.251.129) DVMRP thresh^ 16 1536 ms -3 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 32 1289 ms -4 mbone.sdsc.edu (198.17.47.39) DVMRP thresh^ 64 1701 ms -5 VINEGAR.SESQUI.NET (128.241.0.91) DVMRP thresh^ 64 2016 ms -6 mae-bone.psi.net (192.41.177.247) DVMRP thresh^ 64 -94636 ms -7 stockholm.mbone.ebone.net (192.36.148.206) DVMRP thresh^ 64 -7584 ms -8 broodjeham.surfnet.nl (192.87.4.25) DVMRP thresh^ 48 216801 ms -9 mbone.cern.ch (192.65.185.20) DVMRP thresh^ 48 89587 ms -10 astra.infn.it (192.135.23.2) DVMRP thresh^ 48 -73961 ms -11 sideral.rediris.es (130.206.1.32) DVMRP thresh^ 48 69679 ms Unknown error code 130 Round trip time 604 ms Then it changed to: grunt2b# mtrace 161.0.0.1 Mtrace from 161.0.0.1 to 128.183.50.28 via group 224.2.0.1 Querying full reverse path... 0 grunt2b.gsfc.nasa.gov (128.183.50.28) -1 mbone2.gsfc.nasa.gov (128.183.50.34) DVMRP thresh^ 1 754 ms -2 mbone-cf.gsfc.nasa.gov (128.183.251.129) DVMRP thresh^ 16 766 ms -3 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 32 629 ms -4 mbone.sdsc.edu (198.17.47.39) DVMRP thresh^ 64 832 ms -5 VINEGAR.SESQUI.NET (128.241.0.91) DVMRP thresh^ 64 1039 ms -6 mae-bone.psi.net (192.41.177.247) DVMRP thresh^ 64 -95334 ms -7 MBONE1.UU.NET (137.39.43.34) DVMRP thresh^ 64 1125 ms -8 MBONE3.UU.NET (137.39.229.98) DVMRP thresh^ 64 1086 ms -9 nb-gw.rutgers.edu (192.12.88.3) DVMRP thresh^ 64 1154 ms Wrong interface Round trip time 419 ms Other times, there is no route for source 161.0.0.1. The above routes diverge at VINEGAR.SESQUI.NET (128.241.0.91). I haven't caught up on all the messages yet regarding this recent MBone problem, so I'm not really sure what the significance of the 161.0.0.1 address is, but I thought I'd pass on the above information just in case it's useful to anyone in helping to track down the problem. -Bill From list-mgr@ISI.EDU Mon Nov 27 07:42:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03616>; Mon, 27 Nov 1995 15:46:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03427>; Mon, 27 Nov 1995 15:42:56 -0800 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA03418>; Mon, 27 Nov 1995 15:42:55 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id PAA05261; Mon, 27 Nov 1995 15:42:19 -0800 Date: Mon, 27 Nov 1995 15:42:19 -0800 From: Dino Farinacci <dino@cisco.com> Message-Id: <199511272342.PAA05261@stilton.cisco.com> To: bill@wizard.gsfc.nasa.gov Cc: thalerd@eecs.umich.edu, e93_mda@it.kth.se, mbone, magda@it.kth.se In-Reply-To: Bill Fink's message of Mon, 27 Nov 1995 18:38:37 -0500 (EST) <9511272338.AA02408@wizard.gsfc.nasa.gov> Subject: Routing entires >> For whatever it's worth, an mtrace to 161.0.0.1 from one of my systems >> a little while ago resulted in the following: I was trying a little experiment (read: transient test) with Bill Fenner and temporarily injected a good DVMRP default route. Its gone now, as you noticed. Dino From list-mgr@ISI.EDU Tue Nov 28 13:05:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15661>; Mon, 27 Nov 1995 11:08:21 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15429>; Mon, 27 Nov 1995 11:05:21 -0800 Received: from shonan.sfc.wide.ad.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA15412>; Mon, 27 Nov 1995 11:05:17 -0800 Received: (from nishida@localhost) by shonan.sfc.wide.ad.jp (8.6.11+2.5Wb2/3.3Wb4-shonan) id EAA25072; Tue, 28 Nov 1995 04:05:09 +0900 Message-Id: <199511271905.EAA25072@shonan.sfc.wide.ad.jp> To: thalerd@eecs.umich.edu Cc: mbone Subject: Re: Routing problem source: satellite-sfc.wide.ad.jp? Reply-To: nishida@sfc.wide.ad.jp In-Reply-To: Your message of "Mon, 27 Nov 1995 12:16:13 -0500 (EST)" References: <199511271716.MAA19277@dip.eecs.umich.edu> X-Mailer: Mew beta version 0.98 on Emacs 18.59.3, Mule 1.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 28 Nov 1995 04:05:09 +0900 From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp> >>>>> On Mon, 27 Nov 1995 12:16:13 -0500 (EST), Dave Thaler <thalerd@eecs.umich.edu> said: >> satellite-sfc.wide.ad.jp doesn't seem to be responding to mrinfo or SNMP. Today, we moved satellite-sfc.wide.ad.jp to another segment. Although we use mrouted 3.6, if we had made some mistakes, we're going to fix them AS SOON AS POSSIBLE. If you find something about satellite-sfc, please let us know. If we made today's big trouble, we apologize sincerely to all internet people. -- Yoshifumi Nishida Keio UNIV. nishida@sfc.wide.ad.jp From list-mgr@ISI.EDU Mon Nov 27 11:10:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21635>; Mon, 27 Nov 1995 19:14:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21120>; Mon, 27 Nov 1995 19:11:36 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA21113>; Mon, 27 Nov 1995 19:11:35 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14947(7)>; Mon, 27 Nov 1995 19:11:23 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177478>; Mon, 27 Nov 1995 19:11:09 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: nishida@sfc.wide.ad.jp Cc: thalerd@eecs.umich.edu, mbone Subject: Re: Routing problem source: satellite-sfc.wide.ad.jp? In-Reply-To: Your message of "Mon, 27 Nov 1995 11:05:09 PST." <199511271905.EAA25072@shonan.sfc.wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Nov 1995 19:10:37 PST From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov27.191109pst.177478@crevenia.parc.xerox.com> In message <199511271905.EAA25072@shonan.sfc.wide.ad.jp>you write: >If we made today's big trouble, we apologize sincerely to all internet people. I don't think you did; I think that Dave's mtrace was a side effect of the symptoms of this routing problem. I will explain further in another letter coming soon. Bill From list-mgr@ISI.EDU Mon Nov 27 11:27:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23771>; Mon, 27 Nov 1995 19:39:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23246>; Mon, 27 Nov 1995 19:28:13 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA23239>; Mon, 27 Nov 1995 19:28:12 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15233(3)>; Mon, 27 Nov 1995 19:28:07 PST Received: by crevenia.parc.xerox.com id <177478>; Mon, 27 Nov 1995 19:27:57 -0800 From: Bill Fenner <fenner@parc.xerox.com> To: mbone Subject: Routing problems in the MBONE Message-Id: <95Nov27.192757pst.177478@crevenia.parc.xerox.com> Date: Mon, 27 Nov 1995 19:27:49 PST My theory on the cause of the current routing problems follows. The 3.5 release had a bug having to do with propogation of the default route. It would mangle any routing update that contained a default route, and because of the sorting rules, it would mangle the entire packet, between 60 and 120 routes. Dino Farinacci of Cisco kindly pointed this out to me, and it was fixed in 3.6. Since I knew nothing on the MBONE was supposed to inject a default route, I didn't really think through the ramifications of this bug. As we have discovered over the last 24 hours or so, this bug can cause an awful lot of pain. It turns out that the mangling not only causes bogus routes to propogate down the tree from the default injector, it also can propogate bogus routes up back towards the injector. Combined with a bug that handles duplicate copies of a route in a routing update, this appears to mean that the junk routes will not die out on their own. It's entirely possible that the default route was injected for only a few minutes, and then took on a "life" of its own, fueled by the 3.5 multicast routers. It's also possible that it will not die out until all 3.5 mrouted's are gone. I am currently testing a new release of mrouted, which I will call 3.7 . It has only bugfixes, no new features. It will identify and ignore these bogus routes, and hopefully if enough people upgrade it will kill off the looping routes. It will be a drop-in replacement for either 3.5 or 3.6 mrouted's. Binaries will be available for SunOS, Solaris 2, IRIX 5.3, OSF/1 3.2, and FreeBSD 2.1 , to make the upgrade as easy as possible. Note: I am debugging this based mostly upon guesses and observations; I really need some feedback on one particular point from the community. If you are seeing messages such as: warning - X.X.X.X reports out-of-range metric 0 for origin foo and X.X.X.X is *not* an mrouted 3.5, PLEASE let me know ASAP. I cannot duplicate this message with solely 3.6 neighbors, but we all know about 'cannot duplicate' and bug reports. Many thanks to Van Jacobson, who noticed the bogus netmasks in routing updates and provided the code to ignore them. Due to the method of printing netmasks in mrouted 3.6 it would have taken me a *lot* of time to figure this out without Van's insight. Bill From list-mgr@ISI.EDU Mon Nov 27 12:39:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25872>; Mon, 27 Nov 1995 20:38:35 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA25865>; Mon, 27 Nov 1995 20:38:33 -0800 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id UAA28365; Mon, 27 Nov 1995 20:39:53 -0800 Message-Id: <199511280439.UAA28365@rx7.ee.lbl.gov> To: mbone-na Subject: ODU.EDU hosts sending ttl 255 multicast Date: Mon, 27 Nov 95 20:39:52 PST From: Van Jacobson <van@ee.lbl.gov> Hosts frogger.cs.odu.edu & tetris.cs.odu.edu are sending bursts of 100-200kb/s multicast traffic at ttl 255 to various illegal address (225.0.0.58, 225.0.0.66, etc). Perhaps the people doing this don't realize that this traffic is going all over the world. Since this appears to be some sort of internal testing, perhaps it could be done at a more appropriate ttl, like 16 or less. Thanks. - Van From list-mgr@ISI.EDU Mon Nov 27 15:02:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03147>; Tue, 28 Nov 1995 00:13:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01169>; Mon, 27 Nov 1995 23:04:59 -0800 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA01162>; Mon, 27 Nov 1995 23:04:57 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id XAA17252; Mon, 27 Nov 1995 23:02:36 -0800 Date: Mon, 27 Nov 1995 23:02:36 -0800 From: Dino Farinacci <dino@cisco.com> Message-Id: <199511280702.XAA17252@stilton.cisco.com> To: fenner@parc.xerox.com Cc: mbone, multicast-beta@cisco.com In-Reply-To: Bill Fenner's message of Mon, 27 Nov 1995 19:27:49 PST <95Nov27.192757pst.177478@crevenia.parc.xerox.com> Subject: Routing problems in the MBONE >> I am currently testing a new release of mrouted, which I will call 3.7 . >> It has only bugfixes, no new features. It will identify and ignore these >> bogus routes, and hopefully if enough people upgrade it will kill off the >> looping routes. It will be a drop-in replacement for either 3.5 or 3.6 >> mrouted's. Binaries will be available for SunOS, Solaris 2, IRIX 5.3, >> OSF/1 3.2, and FreeBSD 2.1 , to make the upgrade as easy as possible. These type of routes infected ciscos as non-contiguous masks in the DVMRP routing table are not supported. We have put in a fix to ignore DVMRP routes with bad masks and syslog the fact. This will be fixed in 10.2, 10.3, 11.0, and 11.1. If you can't wait for next week's release, you can find 11.0 images in: ftp://ftp.cisco.com/dino/multicast/11.0/Nov28. If you need 10.3 images, I can make them on an as needed basis. Dino From list-mgr@ISI.EDU Tue Nov 28 05:32:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13594>; Tue, 28 Nov 1995 07:34:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13538>; Tue, 28 Nov 1995 07:33:06 -0800 Received: from aotearoa (aotearoa.sura.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA13528>; Tue, 28 Nov 1995 07:33:04 -0800 Received: from localhost by aotearoa with SMTP (8.6.10/($Id: sendmail.cf,v 1.17 1991/02/11 14:07:23 jmalcolm Exp $)) id KAA03387; Tue, 28 Nov 1995 10:32:52 -0500 Message-Id: <199511281532.KAA03387@aotearoa> To: Dino Farinacci <dino@cisco.com> Cc: fenner@parc.xerox.com, mbone, multicast-beta@cisco.com Subject: Re: Routing problems in the MBONE In-Reply-To: Your message of "Mon, 27 Nov 1995 23:02:36 PST." <199511280702.XAA17252@stilton.cisco.com> Date: Tue, 28 Nov 1995 10:32:51 -0500 From: Erik Sherk <sherk@sura.net> > >> I am currently testing a new release of mrouted, which I will call 3.7 . > >> It has only bugfixes, no new features. It will identify and ignore these > >> bogus routes, and hopefully if enough people upgrade it will kill off the > >> looping routes. It will be a drop-in replacement for either 3.5 or 3.6 > >> mrouted's. Binaries will be available for SunOS, Solaris 2, IRIX 5.3, > >> OSF/1 3.2, and FreeBSD 2.1 , to make the upgrade as easy as possible. > > These type of routes infected ciscos as non-contiguous masks in the > DVMRP routing table are not supported. We have put in a fix to ignore > DVMRP routes with bad masks and syslog the fact. This will be fixed in > 10.2, 10.3, 11.0, and 11.1. If you can't wait for next week's release, you > can find 11.0 images in: > > ftp://ftp.cisco.com/dino/multicast/11.0/Nov28. > > If you need 10.3 images, I can make them on an as needed basis. > > Dino OK, I loaded Nov28 and the DVMRP routing table is down to a reasonable size and it doesn't have a default. cpk-mc1#sho ip dv rou 0.0.0.0 DVMRP Routing Table - 1609 entries Route not found I am also seeing the syslog messages... Nov 28 10:15:51 128.167.252.196 34: Nov 28 10:15:50.021 EST: %DVMRP-1-BADMASK: Bad mask 255.255.0.3 received from 192.41.177.197, Report ignored Nov 28 10:16:51 128.167.252.196 35: Nov 28 10:16:50.461 EST: %DVMRP-1-BADMASK: Bad mask 255.255.0.128 received from 192.41.177.247, Report ignored Nov 28 10:17:51 128.167.252.196 36: Nov 28 10:17:50.461 EST: %DVMRP-1-BADMASK: Bad mask 255.0.0.161 received from 192.80.214.200, Report ignored Nov 28 10:18:52 128.167.252.196 37: Nov 28 10:18:51.045 EST: %DVMRP-1-BADMASK: Bad mask 255.255.0.3 received from 192.41.177.247, Report ignored Nov 28 10:19:53 128.167.252.196 38: Nov 28 10:19:52.717 EST: %DVMRP-1-BADMASK: Bad mask 255.1.0.0 received from 192.80.214.200, Report ignored Nov 28 10:20:54 128.167.252.196 39: Nov 28 10:20:53.677 EST: %DVMRP-1-BADMASK: Bad mask 255.0.0.161 received from 192.80.214.200, Report ignored Nov 28 10:21:55 128.167.252.196 40: Nov 28 10:21:54.373 EST: %DVMRP-1-BADMASK: Bad mask 255.184.0.191 received from 192.41.177.197, Report ignored Nov 28 10:22:55 128.167.252.196 41: Nov 28 10:22:54.953 EST: %DVMRP-1-BADMASK: Bad mask 255.255.0.9 received from 192.41.177.247, Report ignored Is there anything I can do on the mrouted 3.6 hosts (other than upgrade to 3.7)? The routing table is much saner on the 3.6 hosts also, although it still has more routes that the cisco 11.0 router does 1609 vs. 2273. I wonder why? Erik From list-mgr@ISI.EDU Tue Nov 28 11:22:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02890>; Tue, 28 Nov 1995 13:22:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02870>; Tue, 28 Nov 1995 13:22:11 -0800 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA02853>; Tue, 28 Nov 1995 13:22:07 -0800 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.7.1/8.7.1) id QAA06239; Tue, 28 Nov 1995 16:22:17 -0500 (EST) From: Dave Thaler <thalerd@eecs.umich.edu> Message-Id: <199511282122.QAA06239@dip.eecs.umich.edu> Subject: Updated DVMRP MIB To: mbone, idmr@cs.ucl.ac.uk Date: Tue, 28 Nov 1995 16:22:16 -0500 (EST) X-Mailer: ELM [version 2.4 PL24 PGP1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit An updated version of the DVMRP MIB is now available at: ftp://nic.merit.edu/net-research/mbone/draft-thaler-dvmrp-mib-02.txt This update incorporates the following changes to the MIB, which I will go over briefly on Monday at the MBone Engineering BOF. All of these changes have been incorporated into the snmp-mrouted code which will be released in the near future (probably immediately after IETF). (1) added dvmrpVInterfaceStatus and changed MAX-ACCESS of existing columns to allow remote configuration of tunnels. (2) added dvmrpBoundaryStatus to allow remote configuration of scoped boundaries, and made dvmrpBoundaryVifIndex not accessible. (3) added dvmrpAltNetTable to allow management of alternate subnet information on physical interfaces. (4) added dvmrpNumRoutes and dvmrpReachableRoutes gauges to aid in locating specific MBone problems. (5) made dvmrpGenerationId writable to provide restart mechanism Dave From list-mgr@ISI.EDU Tue Nov 28 05:46:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04275>; Tue, 28 Nov 1995 13:48:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04227>; Tue, 28 Nov 1995 13:47:56 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA04220>; Tue, 28 Nov 1995 13:47:54 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14746(8)>; Tue, 28 Nov 1995 13:46:44 PST Received: by crevenia.parc.xerox.com id <177478>; Tue, 28 Nov 1995 13:46:32 -0800 From: Bill Fenner <fenner@parc.xerox.com> To: mbone Subject: PLEASE UPGRADE to mrouted 3.7 Cc: fenner@parc.xerox.com Message-Id: <95Nov28.134632pst.177478@crevenia.parc.xerox.com> Date: Tue, 28 Nov 1995 13:46:26 PST The 3.7 multicast release is an mrouted-only, interim release, meant to save the MBONE from the routing thrashes that it is going through right now. A full feature release is still expected in a couple of months. To make upgrading easy, I have created binaries for SunOS, Solaris 2, IRIX, and OSF/1. (FreeBSD has to wait 'til I get home since my ISDN line doesn't come up in the right direction). This release must run over a 3.5 kernel. Binaries are available from: SunOS: mrouted 3.7: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-sparc-sunos413.tar.Z 3.5 kernel: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/ipmulti3.5-sunos41x.tar.Z Solaris 2.4: mrouted 3.7: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-sparc-solaris2.tar.Z 3.5 kernel: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/Solaris/Solaris_mc35.2.4.tar.Z IRIX 5.3: mrouted 3.7: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-sgi-irix.tar.Z 3.5 kernel: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/IRIX5.4/mrouted3.6.tar.Z OSF/1 3.2: mrouted 3.7: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-alpha-osf1.tar.Z 3.5 kernel: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/OSF1/ipm35_decosf_v32.tar.Z Note that all of the kernel packages include the out-of-date 3.6 mrouted; you need to get the 3.7 mrouted binary tar file as well. The major change in the 3.7 release is that it ignores routing updates that have bogus netmasks in them. The MBONE will be unstable until either all of the 3.5 mrouted's are gone, or all 3.5 mrouted's are surrounded by 3.7 neighbors. PLEASE UPGRADE, I'm making it as easy as I think I possibly can, let me know if I can make it easier! Bill From list-mgr@ISI.EDU Tue Nov 28 07:31:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10537>; Tue, 28 Nov 1995 15:32:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10490>; Tue, 28 Nov 1995 15:31:45 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA10480>; Tue, 28 Nov 1995 15:31:43 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14546(2)>; Tue, 28 Nov 1995 15:31:33 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177478>; Tue, 28 Nov 1995 15:31:27 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: fenner@parc.xerox.com Cc: mbone Subject: Re: PLEASE UPGRADE to mrouted 3.7 In-Reply-To: Your message of "Tue, 28 Nov 1995 13:46:26 PST." <95Nov28.134632pst.177478@crevenia.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Nov 1995 15:31:23 PST From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov28.153127pst.177478@crevenia.parc.xerox.com> I made two typos (well one typo and one braino) in my announcement. The proper URL for the 3.5 kernel for IRIX 5.3 is ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/IRIX5.3/mrouted3.6.tar.Z And the full source, for those who want to port to other platforms (let me know and I will make binaries available) or just build it themselves is in ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7.tar.Z Bill From list-mgr@ISI.EDU Tue Nov 28 13:36:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10927>; Tue, 28 Nov 1995 15:38:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10879>; Tue, 28 Nov 1995 15:37:53 -0800 Received: from radicalmedia.com by venera.isi.edu (5.65c/5.61+local-22) id <AA10866>; Tue, 28 Nov 1995 15:37:49 -0800 Received: (from phiber@localhost) by radicalmedia.com (8.6.12/8.6.12) id SAA27780; Tue, 28 Nov 1995 18:36:53 -0500 From: Mark Abene <phiber@radicalmedia.com> Message-Id: <199511282336.SAA27780@radicalmedia.com> Subject: Re: PLEASE UPGRADE to mrouted 3.7 To: fenner@parc.xerox.com (Bill Fenner) Date: Tue, 28 Nov 1995 18:36:53 -0500 (EST) Cc: mbone In-Reply-To: <95Nov28.134632pst.177478@crevenia.parc.xerox.com> from "Bill Fenner" at Nov 28, 95 01:46:26 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1926 That's all fine and dandy, but what of Solaris on Intel machines? -Mark > > The 3.7 multicast release is an mrouted-only, interim release, meant to > save the MBONE from the routing thrashes that it is going through right now. > A full feature release is still expected in a couple of months. > > To make upgrading easy, I have created binaries for SunOS, Solaris 2, > IRIX, and OSF/1. (FreeBSD has to wait 'til I get home since my ISDN > line doesn't come up in the right direction). This release must run over > a 3.5 kernel. > > Binaries are available from: > > SunOS: > mrouted 3.7: > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-sparc-sunos413.tar.Z > 3.5 kernel: > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/ipmulti3.5-sunos41x.tar.Z > > Solaris 2.4: > mrouted 3.7: > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-sparc-solaris2.tar.Z > 3.5 kernel: > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/Solaris/Solaris_mc35.2.4.tar.Z > > IRIX 5.3: > mrouted 3.7: > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-sgi-irix.tar.Z > 3.5 kernel: > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/IRIX5.4/mrouted3.6.tar.Z > > OSF/1 3.2: > mrouted 3.7: > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-alpha-osf1.tar.Z > 3.5 kernel: > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/OSF1/ipm35_decosf_v32.tar.Z > > Note that all of the kernel packages include the out-of-date 3.6 mrouted; > you need to get the 3.7 mrouted binary tar file as well. > > The major change in the 3.7 release is that it ignores routing updates that > have bogus netmasks in them. The MBONE will be unstable until either all > of the 3.5 mrouted's are gone, or all 3.5 mrouted's are surrounded by 3.7 > neighbors. PLEASE UPGRADE, I'm making it as easy as I think I possibly > can, let me know if I can make it easier! > > Bill > From list-mgr@ISI.EDU Tue Nov 28 11:40:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11011>; Tue, 28 Nov 1995 15:41:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10983>; Tue, 28 Nov 1995 15:40:47 -0800 Received: from ACADEM.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA10976>; Tue, 28 Nov 1995 15:40:45 -0800 Received: (from sob@localhost) by academ.com (8.7.1/8.7.1) id RAA02276; Tue, 28 Nov 1995 17:40:38 -0600 (CST) Message-Id: <199511282340.RAA02276@academ.com> From: sob@academ.com (Stan Barber) Date: Tue, 28 Nov 1995 17:40:38 CST X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Bill Fenner <fenner@parc.xerox.com>, mbone Subject: Re: PLEASE UPGRADE to mrouted 3.7 Vinegar.sesqui.net and Tempeh.sesqui.net are now both running mrouted 3.7. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From list-mgr@ISI.EDU Tue Nov 28 07:44:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11180>; Tue, 28 Nov 1995 15:45:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11137>; Tue, 28 Nov 1995 15:44:26 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA11130>; Tue, 28 Nov 1995 15:44:24 -0800 Received: from localhost (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id PAA02106; Tue, 28 Nov 1995 15:44:12 -0800 Message-Id: <199511282344.PAA02106@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Bill Fenner <fenner@parc.xerox.com> Cc: mbone Subject: Re: PLEASE UPGRADE to mrouted 3.7 In-Reply-To: Your message of "Tue, 28 Nov 1995 15:31:23 PST." <95Nov28.153127pst.177478@crevenia.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Nov 1995 15:44:11 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Howdy, I just compiled mrouted 3.7 on my FreeBSD box and I am getting this: Hope it helps, Amancio rah mrouted[2069]: mrouted version 3.7 Nov 28 15:41:40 rah mrouted[2069]: warning - 140.174.2.1 reports bogus netmask 0xff00000a (255.0.0.10) Nov 28 15:41:40 rah mrouted[2069]: warning - 140.174.2.1 reports bogus netmask 0xff000981 (255.0.9.129) Nov 28 15:41:41 rah mrouted[2069]: warning - 140.174.2.1 reports bogus netmask 0xff00a1bf (255.0.161.191) Nov 28 15:41:41 rah mrouted[2069]: warning - 140.174.2.1 reports bogus netmask 0xff090081 (255.9.0.129) Nov 28 15:41:41 rah mrouted[2069]: warning - 140.174.2.1 reports bogus netmask 0xff1e3b00 (255.30.59.0) Nov 28 15:41:41 rah mrouted[2069]: warning - 140.174.2.1 reports bogus netmask 0xff8181a1 (255.129.129.161) >>> Bill Fenner said: > I made two typos (well one typo and one braino) in my announcement. > > The proper URL for the 3.5 kernel for IRIX 5.3 is > > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/IRIX5.3/mrouted3.6.tar.Z > > And the full source, for those who want to port to other platforms (let me > know and I will make binaries available) or just build it themselves is in > > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7.tar.Z > > Bill > From list-mgr@ISI.EDU Tue Nov 28 07:58:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12102>; Tue, 28 Nov 1995 16:00:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12065>; Tue, 28 Nov 1995 15:59:14 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA12054>; Tue, 28 Nov 1995 15:59:12 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14463(8)>; Tue, 28 Nov 1995 15:59:05 PST Received: by crevenia.parc.xerox.com id <177478>; Tue, 28 Nov 1995 15:59:00 -0800 From: Bill Fenner <fenner@parc.xerox.com> To: fenner@parc.xerox.com, hasty@rah.star-gate.com Subject: Re: PLEASE UPGRADE to mrouted 3.7 Cc: mbone Message-Id: <95Nov28.155900pst.177478@crevenia.parc.xerox.com> Date: Tue, 28 Nov 1995 15:58:52 PST >I just compiled mrouted 3.7 on my FreeBSD box and I am getting this: >Nov 28 15:41:40 rah mrouted[2069]: warning - 140.174.2.1 reports bogus netmask >0xff00000a (255.0.0.10) I should have been more explicit in my announcement message. When I said > The MBONE will be unstable until either all >of the 3.5 mrouted's are gone, or all 3.5 mrouted's are surrounded by 3.7 >neighbors. I should have made it clear that that includes getting bogus netmask errors until the MBONE has stabilized (or your neighbor has upgraded). Luckily, 3.7 has a rate-limiting mechanism so that it doesn't syslog you to death. Bill From list-mgr@ISI.EDU Tue Nov 28 08:00:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12169>; Tue, 28 Nov 1995 16:01:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12152>; Tue, 28 Nov 1995 16:01:15 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA12144>; Tue, 28 Nov 1995 16:01:13 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14605(7)>; Tue, 28 Nov 1995 16:01:07 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177478>; Tue, 28 Nov 1995 16:01:01 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: Mark Abene <phiber@radicalmedia.com> Cc: fenner@parc.xerox.com (Bill Fenner), mbone Subject: Re: PLEASE UPGRADE to mrouted 3.7 In-Reply-To: Your message of "Tue, 28 Nov 1995 15:36:53 PST." <199511282336.SAA27780@radicalmedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Nov 1995 16:00:48 PST From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov28.160101pst.177478@crevenia.parc.xerox.com> In message <199511282336.SAA27780@radicalmedia.com> you write: >That's all fine and dandy, but what of Solaris on Intel machines? I'm afraid you'll have to ask Sun that; when they supply an Intel 3.5-based kernel, 3.7 will run over it. Bill From list-mgr@ISI.EDU Tue Nov 28 09:00:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14932>; Tue, 28 Nov 1995 17:01:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14901>; Tue, 28 Nov 1995 17:00:42 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA14893>; Tue, 28 Nov 1995 17:00:40 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14616(5)>; Tue, 28 Nov 1995 17:00:30 PST Received: by crevenia.parc.xerox.com id <177478>; Tue, 28 Nov 1995 17:00:21 -0800 From: Bill Fenner <fenner@parc.xerox.com> To: mbone Subject: mrouted 3.7 available for FreeBSD/NetBSD and HP/UX Message-Id: <95Nov28.170021pst.177478@crevenia.parc.xerox.com> Date: Tue, 28 Nov 1995 17:00:16 PST I built some binaries on my FreeBSD box that should also work under NetBSD, and Magnus built a 3.7 for HP/UX. So, FreeBSD 2.1/NetBSD ?.?: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-i386-bsd.tar.Z HP/UX 9.05: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-hp-hpux.tar.Z Bill From list-mgr@ISI.EDU Wed Nov 29 03:16:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15654>; Tue, 28 Nov 1995 17:17:45 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15586>; Tue, 28 Nov 1995 17:16:14 -0800 Received: from ncc.ripe.net by venera.isi.edu (5.65c/5.61+local-22) id <AA15573>; Tue, 28 Nov 1995 17:16:12 -0800 Received: from belegen.ripe.net by ncc.ripe.net with SMTP id AA15388 (5.65a/NCC-2.30); Wed, 29 Nov 1995 02:16:10 +0100 Message-Id: <9511290116.AA15388@ncc.ripe.net> To: mbone Subject: mrouted 3.7 for HPUX and BSD/OS + another mirror From: Geert Jan de Groot <GeertJan.deGroot@ripe.net> X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Date: Wed, 29 Nov 1995 02:16:09 +0100 Sender: GeertJan.deGroot@ripe.net Magnus Danielson <e93_mda@it.kth.se> asked me to make his HP-UX mrouted 3.7 port available; you can find it on ftp.ripe.net/tools/mrouted-3.7/mrouted3.7-hpux-9.05.tar.gz The code is humming along on the HP/UX machine on 3.7: tjatte.electrum.kth.se. Good work! I ported mrouted to BSD/OS (Either Steve McCanne's code or otherwise; see the README for details), and made that available on ftp.ripe.net/tools/mrouted-3.7/mrouted3.7-bsdos.tar.gz Note that I did not test the port; the compile builds clean and the changes were only portability issues, but since the my 'test box' is more than 100 KM away and also out primary border router, I decided to make the changes available without running them to save others from having to port the code themselves. In case the Xerox FTP server is busy, I also made a copy of the 3.7 files found on that server; they can be found on: ftp.ripe.net/tools/mrouted-3.7/ftp.parc.xerox.com Let's see if we can get mbone working again before the IETF next week.. Geert Jan From list-mgr@ISI.EDU Tue Nov 28 11:49:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21964>; Tue, 28 Nov 1995 19:53:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21860>; Tue, 28 Nov 1995 19:48:30 -0800 Received: from san_marcos.csusm.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA21852>; Tue, 28 Nov 1995 19:48:27 -0800 Received: by san_marcos.csusm.edu (AIX 4.1/UCB 5.64/4.03) id AA23574; Tue, 28 Nov 1995 19:49:14 -0800 Date: Tue, 28 Nov 1995 19:49:14 -0800 (PST) From: Mark Chorak <chorak1@coyote.csusm.edu> X-Sender: chorak1@san_marcos.csusm.edu To: Mark Abene <phiber@radicalmedia.com> Cc: Bill Fenner <fenner@parc.xerox.com>, mbone Subject: Re: PLEASE UPGRADE to mrouted 3.7 In-Reply-To: <199511282336.SAA27780@radicalmedia.com> Message-Id: <Pine.A32.3.91.951128194827.43900C-100000@san_marcos.csusm.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Or IBM AIX machines? Mark On Tue, 28 Nov 1995, Mark Abene wrote: > Date: Tue, 28 Nov 1995 18:36:53 -0500 (EST) > From: Mark Abene <phiber@radicalmedia.com> > To: Bill Fenner <fenner@parc.xerox.com> > Cc: mbone@ISI.EDU > Subject: Re: PLEASE UPGRADE to mrouted 3.7 > > That's all fine and dandy, but what of Solaris on Intel machines? > > -Mark > > > > > The 3.7 multicast release is an mrouted-only, interim release, meant to > > save the MBONE from the routing thrashes that it is going through right now. > > A full feature release is still expected in a couple of months. > > > > To make upgrading easy, I have created binaries for SunOS, Solaris 2, > > IRIX, and OSF/1. (FreeBSD has to wait 'til I get home since my ISDN > > line doesn't come up in the right direction). This release must run over > > a 3.5 kernel. > > > > Binaries are available from: > > > > SunOS: > > mrouted 3.7: > > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-sparc-sunos413.tar.Z > > 3.5 kernel: > > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/ipmulti3.5-sunos41x.tar.Z > > > > Solaris 2.4: > > mrouted 3.7: > > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-sparc-solaris2.tar.Z > > 3.5 kernel: > > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/Solaris/Solaris_mc35.2.4.tar.Z > > > > IRIX 5.3: > > mrouted 3.7: > > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-sgi-irix.tar.Z > > 3.5 kernel: > > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/IRIX5.4/mrouted3.6.tar.Z > > > > OSF/1 3.2: > > mrouted 3.7: > > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.7-alpha-osf1.tar.Z > > 3.5 kernel: > > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/OSF1/ipm35_decosf_v32.tar.Z > > > > Note that all of the kernel packages include the out-of-date 3.6 mrouted; > > you need to get the 3.7 mrouted binary tar file as well. > > > > The major change in the 3.7 release is that it ignores routing updates that > > have bogus netmasks in them. The MBONE will be unstable until either all > > of the 3.5 mrouted's are gone, or all 3.5 mrouted's are surrounded by 3.7 > > neighbors. PLEASE UPGRADE, I'm making it as easy as I think I possibly > > can, let me know if I can make it easier! > > > > Bill > > > > From list-mgr@ISI.EDU Tue Nov 28 17:11:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24314>; Tue, 28 Nov 1995 21:09:27 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24131>; Tue, 28 Nov 1995 21:06:19 -0800 Received: from jupiter.colmex.mx by venera.isi.edu (5.65c/5.61+local-22) id <AA24117>; Tue, 28 Nov 1995 21:06:15 -0800 Received: (from patvie@localhost) by jupiter.colmex.mx (8.6.12/8.6.9) id XAA10293; Tue, 28 Nov 1995 23:11:31 -0600 Date: Tue, 28 Nov 1995 23:11:31 -0600 (CST) From: Patrick Vielle <patvie@colmex.mx> To: mbone-request Cc: mbone Subject: Re: AIX mrouted port! In-Reply-To: <Pine.A32.3.91.951127140014.18716C-100000@san_marcos.csusm.edu> Message-Id: <Pine.LNX.3.91.951128231058.10252C-100000@jupiter.colmex.mx> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From list-mgr@ISI.EDU Thu Nov 30 03:21:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01787>; Wed, 29 Nov 1995 01:30:32 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01764>; Wed, 29 Nov 1995 01:28:59 -0800 Received: from ps.sfc.wide.ad.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA01756>; Wed, 29 Nov 1995 01:28:18 -0800 Received: from localhost (localhost [127.0.0.1]) by ps.sfc.wide.ad.jp (8.6.12+2.4W/3.4Wbeta695100619) with ESMTP id SAA19249; Wed, 29 Nov 1995 18:21:27 +0900 Message-Id: <199511290921.SAA19249@ps.sfc.wide.ad.jp> To: Christian.Donot@inria.fr Cc: mbone, rem-conf@es.net Subject: Re: Session announce `Ryuichi Sakamoto Tour95 "D&L" with Daizaburo Harada From: =?ISO-2022-JP?B?GyRCPzdIfkA/GyhC?= Makoto Niimi <bignum@wide.ad.jp> In-Reply-To: Your message of "Thu, 23 Nov 1995 13:00:06 +0100 (MET)" References: <199511231200.AA03693@electre.inria.fr> X-Mailer: Mew version 1.00.4 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 29 Nov 1995 18:21:27 +0900 Sender: bignum@sfc.wide.ad.jp From: Christian DONOT <Christian.Donot@inria.fr> Subject: Re: Session announce `Ryuichi Sakamoto Tour95 "D&L" with Daizaburo Harada Date: Thu, 23 Nov 1995 13:00:06 +0100 (MET) > > We'll present this event to you as following. > > > > Ryuichi Sakamoto Tour95 "D&L" with Daizaburo Harada > > Live at Nippon Budohkan Tokyo, Japan > > > The transatlantic links are already full. I'm not sure that on the > European's side, we need this kind of diffusion. > Please, could'you put the ttl below 64. We will be using a single channel for nv, at 64Kbps. The ttl for nv will be 95. The reason why we are making this 95 instead of 64 is because at 64, some areas even within Japan cannot be reached. Best regards. ----- Makoto Niimi, WIDE Project From list-mgr@ISI.EDU Sun Nov 29 11:32:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02008>; Wed, 29 Nov 1995 01:38:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01814>; Wed, 29 Nov 1995 01:32:34 -0800 Received: from mail.noris.net (main.noris.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA01805>; Wed, 29 Nov 1995 01:32:23 -0800 Received: from noris.net by mail.noris.net with smtp id m0tKisW-00014AC; Wed, 29 Nov 95 10:32 MET Received: by noris.net id m0tKisC-00029HC; Wed, 29 Nov 95 10:32 MET Sender: news@gate.noris.net (news) To: mbone Path: noris.net!noris.net!not-for-mail From: urlichs@smurf.noris.de (Matthias Urlichs) Newsgroups: dist.mbone Subject: Re: A couple questions Date: 29 Nov 1995 10:32:23 +0100 Organization: noris network GbR, Nuernberg, FRG Lines: 34 Message-Id: <49h9b7$bhl@smurf.noris.de> References: <199509200012.UAA05600@davinci.gmu.edu> <811557266.7754@noris.de> Nntp-Posting-Host: @main.noris.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In dist.mbone, article <811557266.7754@noris.de>, mbenson@davinci.gmu.edu (Michael Benson) writes: > 1) Any word on the mrouted port for Linux? > Still in progress, as far as can be seen from the kernel patches. If you want to help, the person to ask would be Alan Cox <iialan@iifeak.swan.ac.uk>. > 3) Is there a mrouted port underway or completed for Windows (either 95 > or NT). I need to be able to route a tunnel to a machine with > Windows on it. > Ouch... > 4) Is the code for sd,vat and wb ever going to be released? (I am asking > this because we need a working port of vat for Linux and would also like > this tools for Windows machines. > VanJ has previously stated that he doesn't like to do that because there's a lot of nastiness you can do with these tools if you mess with the code without knowing what you're doing. He has a point, but I suppose you'd _still_ like to have the code... So would I, in fact. -- The obscure we see immediately, the completely apparent takes longer -- Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>. From list-mgr@ISI.EDU Tue Nov 28 18:38:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03247>; Wed, 29 Nov 1995 02:41:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03233>; Wed, 29 Nov 1995 02:39:09 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA03226>; Wed, 29 Nov 1995 02:39:07 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id CAA00526; Wed, 29 Nov 1995 02:38:52 -0800 Message-Id: <199511291038.CAA00526@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: urlichs@smurf.noris.de (Matthias Urlichs) Cc: mbone Subject: Re: A couple questions In-Reply-To: Your message of "29 Nov 1995 10:32:23 +0100." <49h9b7$bhl@smurf.noris.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Nov 1995 02:38:52 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> the sources for vat, vic, nv, and mrouted are available. vat & vic are available ee.lbl.gov:/conferencing nv parcftp.xerox.com:/pub/net-research >>> Matthias Urlichs said: > In dist.mbone, article <811557266.7754@noris.de>, > mbenson@davinci.gmu.edu (Michael Benson) writes: > > 1) Any word on the mrouted port for Linux? > > > Still in progress, as far as can be seen from the kernel patches. > > If you want to help, the person to ask would be Alan Cox > <iialan@iifeak.swan.ac.uk>. > > > 3) Is there a mrouted port underway or completed for Windows (either 95 > > or NT). I need to be able to route a tunnel to a machine with > > Windows on it. > > > Ouch... > > > 4) Is the code for sd,vat and wb ever going to be released? (I am asking > > this because we need a working port of vat for Linux and would also lik e > > this tools for Windows machines. > > > VanJ has previously stated that he doesn't like to do that because there's > a lot of nastiness you can do with these tools if you mess with the code > without knowing what you're doing. > > He has a point, but I suppose you'd _still_ like to have the code... > So would I, in fact. > > -- > The obscure we see immediately, the completely apparent takes longer -- > Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.d e > Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email. > 90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 > PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE > Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>. From list-mgr@ISI.EDU Thu Nov 30 07:41:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19035>; Wed, 29 Nov 1995 10:43:56 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18905>; Wed, 29 Nov 1995 10:40:43 -0800 Received: from mercury.thepoint.net by venera.isi.edu (5.65c/5.61+local-22) id <AA18898>; Wed, 29 Nov 1995 10:40:40 -0800 Received: by mercury.thepoint.net (8.6.12/) id MAA25194; Thu, 30 Nov 1995 12:41:22 -0500 Date: Thu, 30 Nov 1995 12:41:22 -0500 (EST) From: Arlie Davis <arlie@thepoint.net> To: mbone Subject: Is pruning broken under FreeBSD? Message-Id: <Pine.BSF.3.91.951130123850.25143B-100000@mercury.thepoint.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm running mrouted 3.6 from the stock FreeBSD 2.1 release, and it seems that pruning is broken. Between two sites connected with 4 ISDN channels (256K), both running the same mrouted 3.6 code, the link is completely satured, even when there is not a single client running downstream. (And before anyone asks, there are no Ciscos involved. :) Any advice is welcome. If I can't get 3.6 to work, I'm going to be forced to downgrade to (*gasp*) mrouted 3.3. Thanks. -- arlie From list-mgr@ISI.EDU Thu Nov 30 09:14:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24160>; Wed, 29 Nov 1995 12:15:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24122>; Wed, 29 Nov 1995 12:14:08 -0800 Received: from mercury.thepoint.net by venera.isi.edu (5.65c/5.61+local-22) id <AA24110>; Wed, 29 Nov 1995 12:14:06 -0800 Received: by mercury.thepoint.net (8.6.12/) id OAA26883; Thu, 30 Nov 1995 14:14:48 -0500 Date: Thu, 30 Nov 1995 14:14:48 -0500 (EST) From: Arlie Davis <arlie@thepoint.net> To: mbone Subject: FreeBSD: Never mind. Message-Id: <Pine.BSF.3.91.951130140840.26684C-100000@mercury.thepoint.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Never mind. FreeBSD was working perfectly. An older Cisco was participating, and (of course) not pruning. This has been fixed. Speaking of Ciscos, I'm trying to bring up a Cisco 7000 under IOS 10.0.3.3. My configuration so far looks like this: interface tunnel 0 ip unnumbered Ethernet 2/0 ip pim dense-mode tunnel destination ... tunnel source ... tunnel mode dvmrp interface Ethernet 2/0 ip pim dense-mode What else is necessary to make this configuration work? I've encountered the dreaded ip dvmrp metric command, but am not completely sure how to use it, so I haven't. Help? -- arlie From list-mgr@ISI.EDU Wed Nov 29 05:21:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27631>; Wed, 29 Nov 1995 13:23:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27603>; Wed, 29 Nov 1995 13:22:32 -0800 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA27596>; Wed, 29 Nov 1995 13:22:31 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id NAA13444; Wed, 29 Nov 1995 13:21:48 -0800 Date: Wed, 29 Nov 1995 13:21:48 -0800 From: Dino Farinacci <dino@cisco.com> Message-Id: <199511292121.NAA13444@stilton.cisco.com> To: arlie@thepoint.net Cc: mbone In-Reply-To: Arlie Davis's message of Thu, 30 Nov 1995 14:14:48 -0500 (EST) <Pine.BSF.3.91.951130140840.26684C-100000@mercury.thepoint.net> Subject: FreeBSD: Never mind. >> Never mind. FreeBSD was working perfectly. An older Cisco was >> participating, and (of course) not pruning. This has been fixed. >> >> Speaking of Ciscos, I'm trying to bring up a Cisco 7000 under IOS >> 10.0.3.3. My configuration so far looks like this: I knew it, it was too good to be true :-) :-) :-) :-) :-) :-) :-) :-) >> What else is necessary to make this configuration work? I've encountered >> the dreaded ip dvmrp metric command, but am not completely sure how to >> use it, so I haven't. Help? You don't need anything else. However, all the subnets of e2/0 network number will be advertised over the DVMRP tunnel. You should make the tunnel unnumbered pointing to an interface with another network number other than your sites or configure a bogus (read: not used or injected) IP address on the tunnel. Dino From list-mgr@ISI.EDU Wed Nov 29 07:09:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04001>; Wed, 29 Nov 1995 15:14:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03719>; Wed, 29 Nov 1995 15:10:14 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA03711>; Wed, 29 Nov 1995 15:10:11 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14619(8)>; Wed, 29 Nov 1995 15:09:39 PST Received: by crevenia.parc.xerox.com id <177478>; Wed, 29 Nov 1995 15:09:20 -0800 From: Bill Fenner <fenner@parc.xerox.com> To: mbone Subject: Announcing mrouted 3.8, bugfix to the emergency 3.7 release. Message-Id: <95Nov29.150920pst.177478@crevenia.parc.xerox.com> Date: Wed, 29 Nov 1995 15:09:05 PST Some test code managed to make it into the 3.7 mrouted release. The 3.7 mrouted has the following bugs: - It can send prunes with a negative lifetime. If there is an implementation that treats prune lifetimes as unsigned, this can be Real Bad. - It can send traffic on a tunnel after the tunnel neighbor has gone down. This means that killing mrouted on one end of a tunnel may not be sufficent to prevent traffic from crossing that link. If you are a provider, I would suggest upgrading to 3.8 because of the second bug. If you are a leaf, there is no urgent need to upgrade; the negative prune lifetimes should do no harm and there is a feature release coming out in a few months. I apologize deeply for this error; I realize that re-releasing just makes people mad that they have to do the same thing today that they did yesterday. I agonized for hours last night when I discovered the presence of this bug. Once again, mrouted 3.8 is a drop-in replacement for mrouted 3.5, 3.6, and 3.7, and contains a very important fix for the routing table problems that are still floating around the MBONE. How to get it: SunOS: mrouted 3.8: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.8-sparc-sunos41x.tar.Z kernel 3.5: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/ipmulti3.5-sunos41x.tar.Z Solaris 2.4: mrouted 3.8: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.8-sparc-solaris2.tar.Z kernel 3.5: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/Solaris/Solaris_mc35.2.4.tar.Z IRIX 5.3: mrouted 3.8: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.8-sgi-irix.tar.Z kernel 3.5: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/IRIX5.3/mrouted3.6.tar.Z OSF/1 3.2: mrouted 3.8: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.8-alpha-osf1.tar.Z kernel 3.5: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/OSF1/ipm35_decosf_v32.tar.Z HP/UX: mrouted 3.8: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.8-hp-hpux.tar.Z FreeBSD 2.1, NetBSD 1.x?: mrouted 3.8: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.8-i386-bsd.tar.Z BSD/OS: mrouted 3.8: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.8-i386-bsdos.tar.Z My sincere apologies once again to those that I have inconvenienced with this bug. I am truly embarassed. Bill From list-mgr@ISI.EDU Thu Nov 30 02:31:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12310>; Thu, 30 Nov 1995 10:33:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12218>; Thu, 30 Nov 1995 10:32:52 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AB12209>; Thu, 30 Nov 1995 10:32:50 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16192(1)>; Thu, 30 Nov 1995 10:32:06 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177478>; Thu, 30 Nov 1995 10:31:54 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: Magnus <e93_mda@it.kth.se> Cc: kurt@ecrc.de (Kurt Kayser), fenner@parc.xerox.com, mbone Subject: Re: PLEASE UPGRADE!!! In-Reply-To: Your message of "Thu, 30 Nov 1995 10:11:33 PST." <199511301808.TAA16222@piraya.electrum.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Nov 1995 10:31:39 PST From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov30.103154pst.177478@crevenia.parc.xerox.com> Just a note, you really only need 3.8 at the entrance to a subtree; if a domain is singly-connected (and has no 3.5's inside it) you only really need 3.8 at the entrance point, and upgrading the machines inside the domain is less important. It's most important to get 3.8 in two places: 1) next to or in place of any 3.5 . If the people with 3.5's won't upgrade, the MBONE can still be saved if all of their neighbors upgrade. 2) In 'backbone' transit routers. Until everyone has upgraded as in (1), having 3.8 in the backbone will help to get rid of the bogus routes (but won't do a complete job). Bill From list-mgr@ISI.EDU Thu Nov 30 02:31:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12310>; Thu, 30 Nov 1995 10:33:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12218>; Thu, 30 Nov 1995 10:32:52 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AB12209>; Thu, 30 Nov 1995 10:32:50 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16192(1)>; Thu, 30 Nov 1995 10:32:06 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177478>; Thu, 30 Nov 1995 10:31:54 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: Magnus <e93_mda@it.kth.se> Cc: kurt@ecrc.de (Kurt Kayser), fenner@parc.xerox.com, mbone Subject: Re: PLEASE UPGRADE!!! In-Reply-To: Your message of "Thu, 30 Nov 1995 10:11:33 PST." <199511301808.TAA16222@piraya.electrum.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Nov 1995 10:31:39 PST From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Nov30.103154pst.177478@crevenia.parc.xerox.com> Just a note, you really only need 3.8 at the entrance to a subtree; if a domain is singly-connected (and has no 3.5's inside it) you only really need 3.8 at the entrance point, and upgrading the machines inside the domain is less important. It's most important to get 3.8 in two places: 1) next to or in place of any 3.5 . If the people with 3.5's won't upgrade, the MBONE can still be saved if all of their neighbors upgrade. 2) In 'backbone' transit routers. Until everyone has upgraded as in (1), having 3.8 in the backbone will help to get rid of the bogus routes (but won't do a complete job). Bill From list-mgr@ISI.EDU Fri Dec 1 13:21:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04319>; Fri, 1 Dec 1995 05:23:20 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04306>; Fri, 1 Dec 1995 05:22:37 -0800 Received: from mailsun.aber.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA04298>; Fri, 1 Dec 1995 05:22:34 -0800 Received: from mailhost.aber.ac.uk (actually host saturn.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Fri, 1 Dec 1995 13:22:06 +0000 To: mbone Cc: mice-nsc-wales@aber.ac.uk, mice-nsc-uk@cs.ucl.ac.uk Subject: Mbone tools on Dec Alpha with NT Date: Fri, 01 Dec 1995 13:21:57 +0000 Message-Id: <28474.817824117@mailhost.aber.ac.uk> From: D E PRICE <dap@aber.ac.uk> Dear Friends, Over the last few days we have been demoing mbone tools at a multimedia event in Cardiff, the capital of Wales. We have been approached by one compnay which is supplying machines based on the DEC Alpha chip set into educational establishments. The machines are using NT rather than OSF as an operating system. Could someone tell me which tools have been ported into NT for Alphas an where I might locate them please? Also, we have been receiving similar questions from people with PC hardware who are willing to run Linux. Can someone offer similar advice in relation to Linux please? Thanks, Dave Price --------------------------------------------------------- | David Price, Computer Science | | | | Computer Science, University of Wales, Aberystwyth, | | Penglais Campus, Aberystwyth, Dyfed, SY23 3DB | | | | Email: dap@aber.ac.uk WWW: http://www.dcs.aber.ac.uk/ | | Phone: +44 1970 622428 FAX: +44 1970 622455 | --------------------------------------------------------- From list-mgr@ISI.EDU Fri Dec 1 17:28:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08993>; Fri, 1 Dec 1995 07:28:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08910>; Fri, 1 Dec 1995 07:28:39 -0800 Received: from mons.uio.no by venera.isi.edu (5.65c/5.61+local-22) id <AA08870>; Fri, 1 Dec 1995 07:28:36 -0800 Received: from ulrik.uio.no by mons.uio.no with local-SMTP (PP) id <14493-0@mons.uio.no>; Fri, 1 Dec 1995 16:28:23 +0100 Received: by aragorn.uio.no ; Fri, 1 Dec 1995 10:28:24 -0500 From: "Olav Kolbu (UiO/USIT)" <olav.kolbu@usit.uio.no> Message-Id: <9512011628.ZM27281@aragorn.uio.no> Date: Fri, 1 Dec 1995 16:28:23 +0100 X-Mailer: Z-Mail (3.2.1 15feb95) To: mbone Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi there Are there ELF binaries of the SGI mbone software available? I've only seen COFF binaries and my IRIX 6.2(sic) doesn't support COFF. OK -- Olav Kolbu (Olav.Kolbu@usit.uio.no) System Administrator Center for Information Technology Services/Section for Operations University of Oslo P.O. Box 1059 Blindern, N-0316 Oslo, Norway Phone: +47 22 85 27 80, Fax: +47 22 85 27 30 From list-mgr@ISI.EDU Fri Dec 1 00:12:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10742>; Fri, 1 Dec 1995 08:14:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10718>; Fri, 1 Dec 1995 08:13:45 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA10710>; Fri, 1 Dec 1995 08:13:44 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14641(6)>; Fri, 1 Dec 1995 08:13:15 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Fri, 1 Dec 1995 08:13:01 -0800 To: "Olav Kolbu (UiO/USIT)" <olav.kolbu@usit.uio.no> Cc: mbone Subject: Re: mrouted 3.8 ELF binaries? In-Reply-To: Your message of "Fri, 01 Dec 95 07:28:23 PST." <9512011628.ZM27281@aragorn.uio.no> Date: Fri, 1 Dec 1995 08:12:50 PST Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Dec1.081301pst.177478@crevenia.parc.xerox.com> In message <9512011628.ZM27281@aragorn.uio.no> Olav Kolbu wrote: >Are there ELF binaries of the SGI mbone software available? I don't have an IRIX 6.2 box; you'll have to get the source from ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.8.tar.Z and compile it yourself. It should compile out of the box (although you will get some warnings about the function prototypes). Bill From list-mgr@ISI.EDU Fri Dec 1 06:38:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11848>; Fri, 1 Dec 1995 08:41:49 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11806>; Fri, 1 Dec 1995 08:41:25 -0800 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA11799>; Fri, 1 Dec 1995 08:41:24 -0800 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA27237; Fri, 1 Dec 1995 11:38:26 +0500 Message-Id: <9512011638.AA27237@msf.psi.net.> To: Bill Fenner <fenner@parc.xerox.com> Cc: mbone Subject: Re: Announcing mrouted 3.8, bugfix to the emergency 3.7 release. In-Reply-To: Your message of "Wed, 29 Nov 1995 15:09:05 PST." <95Nov29.150920pst.177478@crevenia.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <27235.817835905.1@msf.psi.net> Date: Fri, 01 Dec 1995 11:38:25 -0500 From: "Mark S. Fedor" <fedor@msf.psi.net> Content-Length: 131 mae-bone.psi.net has been upgraded to mrouted 3.8. Please let us know if there are any problems. Things look fine so far. mark From list-mgr@ISI.EDU Fri Dec 1 04:09:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12369>; Fri, 1 Dec 1995 08:53:54 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12353>; Fri, 1 Dec 1995 08:53:33 -0800 Received: from juliet.wcom.com (juliet.wiltel.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA12346>; Fri, 1 Dec 1995 08:53:31 -0800 Received: from atg.wiltel.com by juliet.wcom.com; Fri, 1 Dec 1995 10:21:20 -0600 Received: from salinas by atg.wiltel.com (NX5.67f2/NX3.0M) id AA20725; Fri, 1 Dec 95 10:18:30 -0600 Message-Id: <9512011618.AA20725@atg.wiltel.com> Received: by salinas.wiltel.com (NX5.67f2/NX3.0X) id AA06029; Fri, 1 Dec 95 10:09:09 -0600 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Original-Received: by NeXT.Mailer (1.118.2) Pp-Warning: Illegal Received field on preceding line From: Ather Chaudhry <ather.chaudhry@wcom.com> Date: Fri, 1 Dec 95 10:09:07 -0600 To: mbone Subject: subscribe Would like to subscribe to the mbone mailing list. Thanks, -- Ather LDDS WorldCom, Inc. From list-mgr@ISI.EDU Fri Dec 1 05:01:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12779>; Fri, 1 Dec 1995 09:02:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12764>; Fri, 1 Dec 1995 09:01:46 -0800 Received: from indy12.gclab.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA12750>; Fri, 1 Dec 1995 09:01:43 -0800 Received: (from ccshag@localhost) by indy12.gclab.missouri.edu (8.7.1/8.7.1) id LAA02630; Fri, 1 Dec 1995 11:01:14 -0600 (CST) Date: Fri, 1 Dec 1995 11:01:14 -0600 (CST) From: "Paul 'Shag' Walmsley" <ccshag@cclabs.missouri.edu> X-Sender: ccshag@indy12.gclab.missouri.edu To: Bill Fenner <fenner@parc.xerox.com> Cc: "Olav Kolbu (UiO/USIT)" <olav.kolbu@usit.uio.no>, mbone Subject: Re: mrouted 3.8 ELF binaries? In-Reply-To: <95Dec1.081301pst.177478@crevenia.parc.xerox.com> Message-Id: <Pine.SGI.3.91.951201110039.2451A-100000@indy12.gclab.missouri.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 1 Dec 1995, Bill Fenner wrote: > In message <9512011628.ZM27281@aragorn.uio.no> Olav Kolbu wrote: > >Are there ELF binaries of the SGI mbone software available? > > I don't have an IRIX 6.2 box; you'll have to get the source from > ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.8.tar.Z > and compile it yourself. It should compile out of the box (although > you will get some warnings about the function prototypes). Bill's compiled version of mrouted 3.8 is ELF. You can verify this for yourself by doing a "file /usr/etc/mrouted". - Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu> "Praise and blame alike mean nothing." -- Virginia Woolf From list-mgr@ISI.EDU Fri Dec 1 02:45:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12454>; Fri, 1 Dec 1995 08:57:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12439>; Fri, 1 Dec 1995 08:56:51 -0800 Received: from challenge.TCEL.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA12432>; Fri, 1 Dec 1995 08:56:48 -0800 Received: from dns.tcel.com (root@dns.tcel.com [198.161.236.2]) by challenge.tcel.com (8.6.12/1.2) with ESMTP id 199512011646.JAA00870; Fri, 1 Dec 1995 09:46:08 -0700 From: Sean Watkins <sean@tcel.com> Received: (sean@localhost) by dns.tcel.com (8.6.9/1.2.0) id JAA07538; Fri, 1 Dec 1995 09:46:01 -0700 Message-Id: <199512011646.JAA07538@dns.tcel.com> Subject: Re: your mail To: olav.kolbu@usit.uio.no (Olav Kolbu) Date: Fri, 1 Dec 1995 09:45:54 -0700 (MST) Cc: mbone In-Reply-To: <9512011628.ZM27281@aragorn.uio.no> from "Olav Kolbu" at Dec 1, 95 10:28:23 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 748 > > Hi there > > Are there ELF binaries of the SGI mbone software available? I've > only seen COFF binaries and my IRIX 6.2(sic) doesn't support COFF. > > > OK > > -- > Olav Kolbu (Olav.Kolbu@usit.uio.no) > System Administrator > Center for Information Technology Services/Section for Operations > University of Oslo > P.O. Box 1059 Blindern, N-0316 Oslo, Norway > Phone: +47 22 85 27 80, Fax: +47 22 85 27 30 > > ftp.tcel.com /pub/iris/Mbone -- Sean Watkins Telnet Canada email: sean@corp.tcel.com 1500, 540 5th Ave. S.W. voice: **(403) 262-5859** fax: (403) 228-9702 Calgary, AB, Canada From list-mgr@ISI.EDU Fri Dec 1 07:33:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04425>; Fri, 1 Dec 1995 15:33:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04390>; Fri, 1 Dec 1995 15:33:31 -0800 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA04382>; Fri, 1 Dec 1995 15:33:30 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id PAA28286; Fri, 1 Dec 1995 15:33:29 -0800 Date: Fri, 1 Dec 1995 15:33:29 -0800 From: Dino Farinacci <dino@cisco.com> Message-Id: <199512012333.PAA28286@stilton.cisco.com> To: mbone Subject: 10.2 and 10.3 with non-contig mask fix Is now available. 10.2(10.1) and 10.3(7.4) have the non-contig DVMRP mask fix in. These are standard releases. ftp.cisco.com:{beta102_dir,beta103_dir} have your favorite images. Dino From list-mgr@ISI.EDU Sat Dec 2 21:33:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24982>; Fri, 1 Dec 1995 21:35:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24947>; Fri, 1 Dec 1995 21:34:10 -0800 Received: from mimos.my by venera.isi.edu (5.65c/5.61+local-22) id <AA24940>; Fri, 1 Dec 1995 21:34:07 -0800 Received: from ms.mimos.my (ms.mimos.my [192.228.129.33]) by mimos.my (8.7.1/8.7.1) with SMTP id NAA10045 for <mbone@ISI.EDU>; Sat, 2 Dec 1995 13:33:48 +0800 (MYT) Received: by ms.mimos.my (5.64/7.0) id AA09948; Sat, 2 Dec 95 13:33:47 +0800 Date: Sat, 2 Dec 1995 13:33:47 +0800 From: Nurah Muhammad <nurah@ms.mimos.my> To: mbone Message-Id: <Pine.CVX.3.91.951202133337.9733B-100000@ms.mimos.my> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe From list-mgr@ISI.EDU Sun Dec 3 12:44:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05443>; Sat, 2 Dec 1995 06:45:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05431>; Sat, 2 Dec 1995 06:44:34 -0800 Received: from latcs1.lat.OZ.AU by venera.isi.edu (5.65c/5.61+local-22) id <AA05424>; Sat, 2 Dec 1995 06:44:30 -0800 Received: from latcs2.lat.oz.au by latcs1.lat.oz.au (8.7.1/1.34) id BAA21521; Sun, 3 Dec 1995 01:44:30 +1100 (AEDT) From: tataac@latcs1.lat.oz.au Message-Id: <199512021444.BAA01942@latcs2.lat.oz.au> Subject: unsubscribe To: mbone Date: Sun, 3 Dec 1995 01:44:31 +1100 (AEDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit unsubscribe From list-mgr@ISI.EDU Sat Dec 2 14:00:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27056>; Sat, 2 Dec 1995 22:00:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27044>; Sat, 2 Dec 1995 22:00:04 -0800 Received: from nsd-www.MKT.3Com.COM ([139.87.172.5]) by venera.isi.edu (5.65c/5.61+local-22) id <AA27037>; Sat, 2 Dec 1995 22:00:03 -0800 Received: from tmaufer.ops.3com.com (139.87.36.112) by nsd-www.MKT.3Com.COM with SMTP (Apple Internet Mail Server 1.1b2d4); Sat, 2 Dec 1995 22:00:00 -0800 X-Sender: maufer@nsd-www.mkt.3Com.com Message-Id: <v02110101ace59e28af29@tmaufer.ops.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Organization: 3Com Corporation X-Division: Network Systems Division; Product Marketing X-Url: <URL:http://www.3com.com/> X-Phone: +1 408 764-8814 X-Fax: +1 408 764-5002 X-Mailer: Eudora 2.1.1 for Power Macintosh Date: Sat, 2 Dec 1995 22:00:00 -0800 To: Dino Farinacci <dino@cisco.com> From: Tom Maufer <maufer@nsd.3Com.com> Subject: Re: 10.2 and 10.3 with non-contig mask fix Cc: mbone At 11:33 PM 12/1/95, Dino Farinacci wrote: > Is now available. 10.2(10.1) and 10.3(7.4) have the non-contig > DVMRP mask fix in. These are standard releases. > > ftp.cisco.com:{beta102_dir,beta103_dir} have your favorite images. Dino-- Well, since you mentioned it...I had our main DVMRP developer check our shipping DVMRP code the other day when this was happening. It turns out that he had added some extra sanity checking (over and above what was in mrouted 3.5) which was applied to received routes before they were added to the routing table. One of these extra checks ignored routes received with non-contig masks. Cheers, Tom -- Tom Maufer ....\ 3 \....... .....\ C \...... NETBuilder II Marketing Engineer ......\ o \..... Network Systems Division .......\ m \.... From list-mgr@ISI.EDU Sun Dec 3 12:16:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18234>; Sun, 3 Dec 1995 14:17:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18220>; Sun, 3 Dec 1995 14:16:32 -0800 Received: from burdell.cc.gatech.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA18213>; Sun, 3 Dec 1995 14:16:30 -0800 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.7.1/8.6.9) with ESMTP id RAA10858; Sun, 3 Dec 1995 17:16:29 -0500 (EST) Received: (from kevin@localhost) by flora.cc.gatech.edu (8.7.1/8.6.9) id RAA00894; Sun, 3 Dec 1995 17:16:27 -0500 (EST) Date: Sun, 3 Dec 1995 17:16:27 -0500 (EST) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199512032216.RAA00894@flora.cc.gatech.edu> To: mbone Subject: Georgia Tech's BTC Kickoff Cc: dolors@cc.gatech.edu, limb@cc.gatech.edu The Broadband Telecommunications Center at Georgia Tech is planning an MBONE presentation of its formal kickoff celebration on December 8th. The BTC has a WWW page at: http://www.cc.gatech.edu/BTC/ The kickoff will start at 8:00am on Dec 8th and end at 12:30. A tentative outline is as follows: 8:00 - 8:15 Welcome to Georgia Tech 8:15 - 8:30 Overview of BTC 8:45 - 9:30 Introduction to Georgia Tech * Electrical and Computer Engineering * College of Computing * Georgia Tech Research Institute * Georgia Center for Advantaced Telecommunications Technology 9:30 - 9:50 The Broadband Testbed 9:50 - 10:10 Applications in FutureNet 10:20 - 12:30 The Technical Program * Telecommunications Project * Networking Project * Software and Systems Project * Applications * Economic Modelling and Business Issues If you have any questions about the BTC, contact John Limb, Director at limb@cc. If you have any questions about the broadcast, contact me. -Kevin Almeroth From list-mgr@ISI.EDU Sun Dec 3 15:37:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23204>; Sun, 3 Dec 1995 17:37:08 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23182>; Sun, 3 Dec 1995 17:35:17 -0800 Received: from maelstrom.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA23175>; Sun, 3 Dec 1995 17:35:14 -0800 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.7.1/8.6.6) id UAA04404 for mbone@isi.edu; Sun, 3 Dec 1995 20:37:49 -0500 (EST) Date: Sun, 3 Dec 1995 20:37:49 -0500 (EST) From: Yves Lepage <yves@CC.McGill.CA> Message-Id: <199512040137.UAA04404@maelstrom.cc.mcgill.ca> To: mbone Subject: Admin Scopes Hi, I'd like to experiment with admin scopes and I was wondering if anyone played with them already. I saw that SDR (which is already awesome even if it is still an alpha) allows for the creation of events using admin scopes. How do they interact with multicast routers? Via the boundary option to the tunnel config command? If so, I also saw that we can give names to boundaries using the name command. But where do the addresses in there come from? Are they assigned? I know this is a lot of questions but I think using admin scopes for creating events is a much more user friendly to do it and that's why I'd like to enable that for my users. Thanks a lot. Yves Lepage From list-mgr@ISI.EDU Mon Dec 4 21:00:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25440>; Sun, 3 Dec 1995 19:01:51 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25423>; Sun, 3 Dec 1995 19:00:20 -0800 Received: from sh.iij-mc.co.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA25416>; Sun, 3 Dec 1995 19:00:14 -0800 Received: from mcgw.iij-mc.co.jp (root@mcgw.iij-mc.co.jp [192.168.10.2]) by sh.iij-mc.co.jp (8.6.12+2.4W/3.4W2) with ESMTP id MAA00669 for <mbone@isi.edu>; Mon, 4 Dec 1995 12:00:11 +0900 Received: from teapot (bunji@localhost [127.0.0.1]) by mcgw.iij-mc.co.jp (8.6.12+2.5Wb7/3.4W) with ESMTP id MAA22902; Mon, 4 Dec 1995 12:00:10 +0900 Message-Id: <199512040300.MAA22902@mcgw.iij-mc.co.jp> To: mbone Cc: hiroshima@iij-mc.co.jp Subject: The FUTURE OF HOPE Conference From: YAMAMOTO Bunji <bunji@iij-mc.co.jp> In-Reply-To: Your message of "Mon, 04 Dec 1995 11:42:31 +0900" References: <199512040242.LAA22780@mcgw.iij-mc.co.jp> X-Mailer: Mew version 1.00.4 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 04 Dec 1995 12:00:09 +0900 Sender: bunji@mcgw.iij-mc.co.jp We will broadcast this session at Dec 6. This session is for "The FUTURE OF HOPE Conference" from Hiroshima, JAPAN and will be used for conference via the Internet from Hiroshima, Pretoria, Jerusalem and Atlanta. We will use IIJ's international link for this session. Contents: The Future of Hope Internet Conference Session Name: Future of Hope Media: vat, nv Bandwidth: 70kbps(vat), 127kbps(nv) From: Dec 6 06:00 UTC Till: Dec 6 15:00 UTC Init TTL: 191(vat), 127(nv) Contact: hiroshima@iij-mc.co.jp WWW: http://www.iijnet.or.jp/HIROSHIMA/mbone.html (Mbone Info) http://www.iijnet.or.jp/HIROSHIMA/ -- YAMAMOTO Bunji <bunji@iij-mc.co.jp> IIJ Media Communications Inc. From list-mgr@ISI.EDU Mon Dec 4 10:58:22 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28638>; Sun, 3 Dec 1995 21:00:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28619>; Sun, 3 Dec 1995 20:59:35 -0800 Received: from redgate.vislab.usyd.edu.au by venera.isi.edu (5.65c/5.61+local-22) id <AA28612>; Sun, 3 Dec 1995 20:59:30 -0800 Received: from cazneaux.vislab.usyd.edu.au by redgate.vislab.usyd.edu.au via ESMTP (950911.SGI.8.6.12.PATCH825/940406.SGI) id PAA17318; Mon, 4 Dec 1995 15:58:26 +1000 Received: by cazneaux.vislab.usyd.edu.au (950911.SGI.8.6.12.PATCH825/940406.SGI) id PAA04465; Mon, 4 Dec 1995 15:58:23 +1000 From: "Chris Willing" <chris@vislab.usyd.edu.au> Message-Id: <9512041558.ZM4463@cazneaux.vislab.usyd.edu.au> Date: Mon, 4 Dec 1995 15:58:22 -0500 In-Reply-To: kevin@cc.gatech.edu (Kevin C. Almeroth) "Georgia Tech's BTC Kickoff" (Dec 3, 5:16pm) References: <199512032216.RAA00894@flora.cc.gatech.edu> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: kevin@cc.gatech.edu (Kevin C. Almeroth), mbone Subject: Re: Georgia Tech's BTC Kickoff Cc: dolors@cc.gatech.edu, limb@cc.gatech.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Dec 3, 5:16pm, Kevin C. Almeroth wrote: > Subject: Georgia Tech's BTC Kickoff > The Broadband Telecommunications Center at Georgia Tech is planning an > MBONE presentation of its formal kickoff celebration on December 8th. (snip) > If you have any questions about the broadcast, contact me. > > -Kevin Almeroth >-- End of excerpt from Kevin C. Almeroth Could you use an audio format other than idvi? I'm quite interested in tuning in but my vat (v4.0a2) doesn't recognize that format. Presumeably others with the same version of vat will have the same problem. I don't know if this is a bug or feature of this vat version. chris willing -- +--------------------------------------------------------------------------+ | Chris Willing Telephone (61-2) 351 3914 | | VisLab, A28 Facsimile (61-2) 660 2903 | | University of Sydney email chris@vislab.usyd.edu.au | | NSW 2006 Australia http://www.cs.su.oz.au/~chrisw/index.cgi | +--------------------------------------------------------------------------+ From list-mgr@ISI.EDU Sun Dec 3 16:00:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01000>; Sun, 3 Dec 1995 22:13:50 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00927>; Sun, 3 Dec 1995 22:11:46 -0800 Received: from challenge.TCEL.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA00920>; Sun, 3 Dec 1995 22:11:43 -0800 Received: (from sean@localhost) by challenge.tcel.com (8.6.12/1.2) id 199512040600.XAA29585 for mbone@ISI.EDU; Sun, 3 Dec 1995 23:00:59 -0700 From: Sean Watkins <sean@tcel.com> Message-Id: <199512040600.XAA29585@challenge.tcel.com> Subject: mrouted for Linux? To: mbone Date: Sun, 3 Dec 1995 23:00:58 -0700 (MST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 394 Does mrouted exist for linux? We'd like to setup MBone up on a PC before we put it on anything commercial? -- Sean Watkins Telnet Canada email: sean@corp.tcel.com 1500, 540 5th Ave. S.W. voice: **(403) 262-5859** fax: (403) 228-9702 Calgary, AB, Canada From list-mgr@ISI.EDU Mon Dec 4 10:44:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01789>; Sun, 3 Dec 1995 22:46:17 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01765>; Sun, 3 Dec 1995 22:44:58 -0800 Received: from castor.cc.utu.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA01758>; Sun, 3 Dec 1995 22:44:53 -0800 Received: by utu.fi id <167397-4>; Mon, 4 Dec 1995 08:44:41 +0200 Subject: Re: mrouted for Linux? From: Matti Aarnio <mea@utu.fi> To: sean@tcel.com (Sean Watkins) Date: Mon, 4 Dec 1995 08:44:02 +0200 (EET) Cc: mbone In-Reply-To: <199512040600.XAA29585@challenge.tcel.com> from "Sean Watkins" at Dec 3, 95 11:00:58 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 768 Message-Id: <95Dec4.084441eet.167397-4+135@utu.fi> > Does mrouted exist for linux? We'd like to setup MBone up on a PC > before we put it on anything commercial? Yes and no -- the kernel aspects do exist to a certain degree in the lattest releases (1.3.40+), however there are still many things which are a bit unfinished before it can be said to work. The daemon itself is fairly small part of the beast, after all.. At the moment I would suggest NetBSD/FreeBSD instead of Linux. (This from a person using Linux on his machines...) > -- > Sean Watkins Telnet Canada > email: sean@corp.tcel.com 1500, 540 5th Ave. S.W. > voice: **(403) 262-5859** fax: (403) 228-9702 Calgary, AB, Canada /Matti Aarnio <mea@utu.fi> From list-mgr@ISI.EDU Sun Dec 3 16:28:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04827>; Mon, 4 Dec 1995 00:29:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04820>; Mon, 4 Dec 1995 00:28:49 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA04812>; Mon, 4 Dec 1995 00:28:46 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id AAA03463; Mon, 4 Dec 1995 00:28:31 -0800 Message-Id: <199512040828.AAA03463@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Matti Aarnio <mea@utu.fi> Cc: sean@tcel.com (Sean Watkins), mbone Subject: Re: mrouted for Linux? In-Reply-To: Your message of "Mon, 04 Dec 1995 08:44:02 +0200." <95Dec4.084441eet.167397-4+135@utu.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Dec 1995 00:28:31 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> To the linux fans: You can install FreeBSD on a small partition and still use your linux ip multicast apps . And if you have problems with running linux apps on FreeBSD just send me a note. Last but not least is no big deal to run either FreeBSD or Linux , be happy that we got choices and good choices at that 8) Enjoy, Amancio >>> Matti Aarnio said: > > Does mrouted exist for linux? We'd like to setup MBone up on a PC > > before we put it on anything commercial? > > Yes and no -- the kernel aspects do exist to a certain degree > in the lattest releases (1.3.40+), however there are still many > things which are a bit unfinished before it can be said to work. > > The daemon itself is fairly small part of the beast, after all.. > > > At the moment I would suggest NetBSD/FreeBSD instead of Linux. > (This from a person using Linux on his machines...) > > > -- > > Sean Watkins Telnet Can ada > > email: sean@corp.tcel.com 1500, 540 5th Ave. S .W. > > voice: **(403) 262-5859** fax: (403) 228-9702 Calgary, AB, Can ada > > /Matti Aarnio <mea@utu.fi> From list-mgr@ISI.EDU Sun Dec 3 16:28:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04804>; Mon, 4 Dec 1995 00:28:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04782>; Mon, 4 Dec 1995 00:27:15 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA04775>; Mon, 4 Dec 1995 00:27:13 -0800 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id AAA07516; Mon, 4 Dec 1995 00:28:35 -0800 Message-Id: <199512040828.AAA07516@rx7.ee.lbl.gov> To: mbone Subject: user root@india.URZ.Uni-Magdeburg.DE sending 1Mb/s to mbone video Date: Mon, 04 Dec 95 00:28:35 PST From: Van Jacobson <van@ee.lbl.gov> User "root@india.URZ.Uni-Magdeburg.DE" (who may also be "pnowak@sunny.cs.uni-magdeburg.de" has been sending 1 Mb/s of black nv video to MBone Video (224.2.1.1/4444) for the past two hours. Mail seems to be misconfigured on this machines & I haven't been able to email this user. Perhaps someone in Germany would like to suggest that they stop. Thanks. - Van From list-mgr@ISI.EDU Mon Dec 4 12:46:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05385>; Mon, 4 Dec 1995 00:48:09 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05370>; Mon, 4 Dec 1995 00:47:05 -0800 Received: from sc-uni.ktu.lt (nemunas.sc-uni.ktu.lt) by venera.isi.edu (5.65c/5.61+local-22) id <AA05361>; Mon, 4 Dec 1995 00:46:54 -0800 Received: from sefas.soften.ktu.lt (sefas.soften.ktu.lt [193.219.33.99]) by sc-uni.ktu.lt (8.6.9/8.6.9) with SMTP id KAA09057 for <mbone@ISI.EDU>; Mon, 4 Dec 1995 10:45:24 +0200 Received: by sefas.soften.ktu.lt (5.x/SMI-4.1) id AA16524; Mon, 4 Dec 1995 10:46:26 +0200 Date: Mon, 4 Dec 1995 10:46:25 +0200 (EET) From: Audrius Dziaugys <dziaugys@sefas.soften.ktu.lt> To: mbone Subject: Unsubscribe Message-Id: <Pine.SOL.3.91.951204104602.16494A-100000@sefas> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From list-mgr@ISI.EDU Sun Dec 3 17:41:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06668>; Mon, 4 Dec 1995 01:41:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06648>; Mon, 4 Dec 1995 01:40:21 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA06641>; Mon, 4 Dec 1995 01:40:19 -0800 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id BAA07560; Mon, 4 Dec 1995 01:41:42 -0800 Message-Id: <199512040941.BAA07560@rx7.ee.lbl.gov> To: mbone Subject: faui45r.informatik.uni-erlangen.de sending 200kb/s to mbone Date: Mon, 04 Dec 95 01:41:41 PST From: Van Jacobson <van@ee.lbl.gov> For more than an hour, host faui45r.informatik.uni-erlangen.de has been sending 200kb/s of god-knows-what to 224.2.231.173/7000 at ttl 127. The Mbone is very busy this week with IETF & several other events. Perhaps someone in Germany could suggest that this user either stop or do whatever strange thing they're doing at a more appropriate ttl (say 15 or less). Thanks. - Van From list-mgr@ISI.EDU Mon Dec 4 13:47:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06895>; Mon, 4 Dec 1995 01:49:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06870>; Mon, 4 Dec 1995 01:47:48 -0800 Received: from castor.cc.utu.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA06863>; Mon, 4 Dec 1995 01:47:46 -0800 Received: by utu.fi id <167482-2>; Mon, 4 Dec 1995 11:47:35 +0200 Subject: Re: mrouted for Linux? From: Matti Aarnio <mea@utu.fi> To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Mon, 4 Dec 1995 11:47:24 +0200 (EET) Cc: mea@utu.fi, sean@tcel.com, mbone In-Reply-To: <199512040828.AAA03463@rah.star-gate.com> from "Amancio Hasty Jr." at Dec 4, 95 00:28:31 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 729 Message-Id: <95Dec4.114735eet.167482-2+181@utu.fi> > To the linux fans: > > You can install FreeBSD on a small partition and still use your linux > ip multicast apps . And if you have problems with running linux apps > on FreeBSD just send me a note. I was thinking only of the DVMRP router functionality, not about running applications on it. (Your emphasis may vary, of course..) > Last but not least is no big deal to run either FreeBSD or Linux , be > happy that we got choices and good choices at that 8) Yes, both are very good tools -- and I prefer to choose working tools instead of cute pink/green ones, if I can.. > Enjoy, > Amancio /Matti Aarnio <mea@utu.fi> -- Participating on multicast network via FUNET ATM-backbone, which uses cisco PIM... From list-mgr@ISI.EDU Mon Dec 4 12:41:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08008>; Mon, 4 Dec 1995 02:45:29 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07960>; Mon, 4 Dec 1995 02:42:57 -0800 Received: from faui40.informatik.uni-erlangen.de by venera.isi.edu (5.65c/5.61+local-22) id <AA07924>; Mon, 4 Dec 1995 02:41:17 -0800 Received: from faui46e.informatik.uni-erlangen.de (ehmeier@faui46e.informatik.uni-erlangen.de [131.188.34.89]) by immd4.informatik.uni-erlangen.de with SMTP id LAA04335 (8.7.2/7.5a-FAU);; Mon, 4 Dec 1995 11:41:09 +0100 (MET) From: Erich Meier <Erich.Meier@informatik.uni-erlangen.de> Message-Id: <199512041041.LAA04335@faui40.informatik.uni-erlangen.de> Subject: Re: faui45r.informatik.uni-erlangen.de sending 200kb/s to mbone To: van@ee.lbl.gov (Van Jacobson) Date: Mon, 4 Dec 1995 11:41:08 +0100 (MET) Cc: mbone In-Reply-To: <199512040941.BAA07560@rx7.ee.lbl.gov> from "Van Jacobson" at Dec 4, 95 01:41:41 am X-Mailer: ELM [version 2.4 PL24 ME8b] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > > For more than an hour, host faui45r.informatik.uni-erlangen.de > has been sending 200kb/s of god-knows-what to 224.2.231.173/7000 > at ttl 127. The Mbone is very busy this week with IETF & > several other events. Perhaps someone in Germany could suggest > that this user either stop or do whatever strange thing they're > doing at a more appropriate ttl (say 15 or less). Thanks. > > - Van > Hmm, I found an application named "push" running on that machine and terminated it. Does this solve the problem? I do apollogize to the MBone community for any inconveniences this might have caused. Greetings, Erich -- Erich Meier Erich.Meier@informatik.uni-erlangen.de http://www4.informatik.uni-erlangen.de/~meier "102854-01 SunOS 5.4: Windows 95 PPP causes Solaris to crash every time" From list-mgr@ISI.EDU Sun Dec 3 18:47:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08061>; Mon, 4 Dec 1995 02:49:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08018>; Mon, 4 Dec 1995 02:46:21 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA08011>; Mon, 4 Dec 1995 02:46:19 -0800 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id CAA07631; Mon, 4 Dec 1995 02:47:30 -0800 Message-Id: <199512041047.CAA07631@rx7.ee.lbl.gov> To: Erich Meier <Erich.Meier@informatik.uni-erlangen.de> Cc: mbone Subject: Re: faui45r.informatik.uni-erlangen.de sending 200kb/s to mbone In-Reply-To: Your message of Mon, 04 Dec 95 11:41:08 N. Date: Mon, 04 Dec 95 02:47:29 PST From: Van Jacobson <van@ee.lbl.gov> Erich, > Hmm, I found an application named "push" running on that machine > and terminated it. Does this solve the problem? Yes, that solved the problem. Thanks! - Van From list-mgr@ISI.EDU Mon Dec 4 05:23:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20977>; Mon, 4 Dec 1995 09:27:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20839>; Mon, 4 Dec 1995 09:26:39 -0800 Received: from dfw.net by venera.isi.edu (5.65c/5.61+local-22) id <AA20832>; Mon, 4 Dec 1995 09:26:38 -0800 Received: by dfw.net (8.7.1/SMI-4.1) id LAA17375; Mon, 4 Dec 1995 11:23:45 -0600 (CST) Date: Mon, 4 Dec 1995 11:23:45 -0600 (CST) From: Aleph One <aleph1@dfw.net> To: mbone Subject: MBONE Connection Message-Id: <Pine.SUN.3.91.951204112028.17219A@dfw.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello everyone. I'am looking to get an MBONE tunnel from someone. I have contacted my ISP Net99 but so far have gotten nothign from them. So if anyone a few short hops away from cyberworks.net can offer a tunnel I would be greatfull. (BTW it would have to be using old mrouter software since Sun has not ported the patches from 2.4 solaris to 2.5) Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 From list-mgr@ISI.EDU Mon Dec 4 04:11:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24198>; Mon, 4 Dec 1995 10:22:55 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24178>; Mon, 4 Dec 1995 10:22:32 -0800 Received: from challenge.TCEL.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA24169>; Mon, 4 Dec 1995 10:22:30 -0800 Received: (from sean@localhost) by challenge.tcel.com (8.6.12/1.2) id 199512041811.LAA06526 for mbone@ISI.EDU; Mon, 4 Dec 1995 11:11:44 -0700 From: Sean Watkins <sean@tcel.com> Message-Id: <199512041811.LAA06526@challenge.tcel.com> Subject: Tunnel Request To: mbone Date: Mon, 4 Dec 1995 11:11:44 -0700 (MST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 477 Hi I would like to request a MBONE Tunnel. We are 2 hops off the SprintLink Stockton NAP. Our provider Insinc/Sprint Canada does not do MBone... Our end will be 198.161.236.27 Thanks -- Sean Watkins Telnet Canada email: sean@corp.tcel.com 1500, 540 5th Ave. S.W. voice: **(403) 262-5859** fax: (403) 228-9702 Calgary, AB, Canada From list-mgr@ISI.EDU Mon Dec 4 12:15:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06270>; Mon, 4 Dec 1995 14:17:51 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06250>; Mon, 4 Dec 1995 14:17:05 -0800 Received: from davinci.gmu.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA06242>; Mon, 4 Dec 1995 14:16:59 -0800 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id RAA01862; Mon, 4 Dec 1995 17:15:11 -0500 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199512042215.RAA01862@davinci.gmu.edu> Subject: Re: MBONE To: mbone Date: Mon, 4 Dec 1995 17:15:06 -0500 (EST) Cc: vlaviano@cne.gmu.edu In-Reply-To: <9512042213.AA02733@cne.gmu.edu> from "Vince Laviano" at Dec 4, 95 05:13:51 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 403 Is anyone else having problems receiving the IETF conference from Dallas? Michael > > BTW, are they multicasting from down there. We're not receiving > anything here, haven't been since around 3 pm EST. > > Vince > -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Tue Dec 5 04:24:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06707>; Mon, 4 Dec 1995 14:25:20 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06690>; Mon, 4 Dec 1995 14:24:59 -0800 Received: from boy.nmd.msu.ru by venera.isi.edu (5.65c/5.61+local-22) id <AA06680>; Mon, 4 Dec 1995 14:24:54 -0800 Received: (from kent@localhost) by boy.nmd.msu.ru (8.6.9/8.6.6) id BAA13981 for mbone@ISI.EDU; Tue, 5 Dec 1995 01:24:51 +0300 Date: Tue, 5 Dec 1995 01:24:51 +0300 From: "Konstantin M. Scherbatukh" <kent@boy.nmd.msu.ru> Message-Id: <199512042224.BAA13981@boy.nmd.msu.ru> To: mbone Subject: DVMRP/PIM in Gated 3.5 B1 Hello! Does anybody test DVMRP or PIM implementation in Gated 3.5 B1? -- ---- Konstantin Shcherbatykh Moscow State University Phone: +7-095-939-2829 kent@msu.ru From list-mgr@ISI.EDU Mon Dec 4 14:20:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12550>; Mon, 4 Dec 1995 16:20:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12525>; Mon, 4 Dec 1995 16:20:13 -0800 Received: from glock.com by venera.isi.edu (5.65c/5.61+local-22) id <AA12518>; Mon, 4 Dec 1995 16:20:11 -0800 Received: (from mmead@localhost) by Glock.COM (8.7.1/8.7.1) id TAA04991; Mon, 4 Dec 1995 19:20:05 -0500 (EST) Date: Mon, 4 Dec 1995 19:20:05 -0500 (EST) From: "matthew c. mead" <mmead@Glock.COM> Message-Id: <199512050020.TAA04991@Glock.COM> To: mbone Subject: obtaining a tunnel I'd like to obtain a mbone tunnel from whoever my closest neighbor is, and was told to ask here for it. I'm not on this list, so I'd appreciate replies at least CC'd to this address. Could either my nearest neighbor, or whoever I need to contact in finding my nearest neighbor please get in touch with me? Thanks! -matt -- Matthew C. Mead mmead@Glock.COM | Network Administration and Software Development http://www.Glock.COM/~mmead/ | Consulting: BizNet Technologies -> mmead@bnt.com From list-mgr@ISI.EDU Mon Dec 4 15:15:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15264>; Mon, 4 Dec 1995 17:14:26 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15017>; Mon, 4 Dec 1995 17:12:26 -0800 Received: from maelstrom.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA15006>; Mon, 4 Dec 1995 17:12:25 -0800 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.7.1/8.6.6) id UAA07742 for mbone@isi.edu; Mon, 4 Dec 1995 20:15:02 -0500 (EST) Date: Mon, 4 Dec 1995 20:15:02 -0500 (EST) From: Yves Lepage <yves@CC.McGill.CA> Message-Id: <199512050115.UAA07742@maelstrom.cc.mcgill.ca> To: mbone Subject: Repository Hello, Is there a place where past MBONE events are stored after they were recorded? If not, is there a place with just sample images from these events? Thanks a lot Yves Lepage From list-mgr@ISI.EDU Tue Dec 5 17:23:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15613>; Mon, 4 Dec 1995 17:24:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15597>; Mon, 4 Dec 1995 17:23:43 -0800 Received: from oversteer.library.uwa.edu.au by venera.isi.edu (5.65c/5.61+local-22) id <AA15585>; Mon, 4 Dec 1995 17:23:36 -0800 Received: (from carl@localhost) by oversteer.library.uwa.edu.au (8.7.2/8.7) id JAA17398 for mbone@ISI.EDU; Tue, 5 Dec 1995 09:23:31 +0800 (WST) Date: Tue, 5 Dec 1995 09:23:31 +0800 (WST) From: Carl Brewer <carl@oversteer.library.uwa.edu.au> Message-Id: <199512050123.JAA17398@oversteer.library.uwa.edu.au> To: mbone Subject: remedial question on tunnel setup G'day, I posted this last week, but I think I sent it to the wrong address, so I'll try again, if you've already seen this, I appologise, and will accept any chastisement necessary :) I've just upgraded to 3.8 (from 3.4beta, hides head in shame) and we've had a lot of ongoing problems (I don't think related to the upgrade), and I've decided to stick my neck out and see if anyone can spot a problem. We've got a CISCO that I am supposed to have a tunnel to, when I run map-mbone like this, I see this : root{2} : ./map-mbone diablo 130.95.128.19 (diablo.uwa.edu.au): <v10.3> 130.95.128.19: 139.130.47.2 (savoy.aarnet.edu.au) [1/32/tunnel/querier] 130.95.106.12 (oversteer.library.uwa.edu.au) [1/8/tunnel/querier] 130.95.128.19 (diablo.uwa.edu.au) [1/0/querier] (diablo is the name of the CISCO) When I run map-mbone on my host (SunOS 4.1.3, with the 3.5 kernel and mrouted 3.8) I get this : root{1} : ./map-mbone Multicast Router Connectivity: Which doesn't seem right. I've got one entry in mrouted.conf : tunnel 130.95.106.12 130.95.128.19 metric 3 rate_limit 500 and a traceroute to diable looks like this : traceroute to diablo.uwa.edu.au (130.95.128.19), 30 hops max, 40 byte packets 1 hacienda.library.uwa.edu.au (130.95.106.1) 3 ms 2 ms 2 ms 2 diablo.uwa.edu.au (130.95.128.19) 3 ms * 3 ms Can anyone see what I've done wrong? Have I got the metric wrong? Or maybe the CISCO isn't set correctly? It has worked in the past when hooked up to another router (an Alpha running mrouted) but when we were switched over to the CISCO we have not been able to get any reliable service, which leads me to believe that somehow the CISCO, or my mrouted.conf, has the problem. Thanks for any advice, or pointers to FAQ's. Carl carl@oversteer.library.uwa.edu.au #include <generic_disclaimer.h> finger cbrewer@uniwa.uwa.edu.au for my pgp public key From list-mgr@ISI.EDU Mon Dec 4 16:24:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18814>; Mon, 4 Dec 1995 18:31:40 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18607>; Mon, 4 Dec 1995 18:27:56 -0800 Received: from lhc.nlm.nih.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA18598>; Mon, 4 Dec 1995 18:27:50 -0800 Received: from billings.nlm.nih.gov by lhc.nlm.nih.gov (4.1/SMI-4.0) id AA27587; Mon, 4 Dec 95 21:27:01 EST Received: by billings.nlm.nih.gov (5.x/SMI-SVR4) id AA12431; Mon, 4 Dec 1995 21:24:28 -0500 Date: Mon, 4 Dec 1995 21:24:28 -0500 From: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Message-Id: <9512050224.AA12431@billings.nlm.nih.gov> To: mbone, yves@CC.McGill.CA Subject: Re: Repository Cc: likavec@igd.fhg.de, rodgers@nlm.nih.gov X-Sun-Charset: US-ASCII Yves, There is no master repository that I have ever heard of, though individual conferences sometimes make efforts along these lines. One example is AVWOD, the media on-demand system set up to serve archived MBONE materials from the Third International World Wide Web Conference (Darmstadt, April 1995). Connect to the Conference server document: http://www.igd.fhg.de/www95.html and look for the AVWOD link. I think they did quite a fine job. Cheerio, Rick Rodgers > From list-mgr@ISI.EDU Mon Dec 4 20:26 EST 1995 > Date: Mon, 4 Dec 1995 20:15:02 -0500 (EST) > From: Yves Lepage <yves@CC.McGill.CA> > To: mbone@ISI.EDU > Subject: Repository > Content-Type: text > Content-Length: 182 > > Hello, > > Is there a place where past MBONE events are stored after they > were recorded? > > If not, is there a place with just sample images from these events? > > Thanks a lot > Yves Lepage > From list-mgr@ISI.EDU Tue Dec 5 23:45:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25233>; Mon, 4 Dec 1995 21:53:41 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25148>; Mon, 4 Dec 1995 21:50:10 -0800 Received: from cskinetgw.cskb.csk.co.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA25133>; Mon, 4 Dec 1995 21:49:44 -0800 Received: from cskdaemon.cske.csk.co.jp by cskinetgw.cskb.csk.co.jp (8.6.12+2.5Wb4/3.3W995101912) with SMTP id OAA25431 for <mbone@ISI.edu>; Tue, 5 Dec 1995 14:48:30 +0900 Received: from csktecnogw.tecno.csk.co.jp by cskdaemon.cske.csk.co.jp (4.1/6.4J.6) id AA22374; Tue, 5 Dec 95 14:50:36 JST Received: from [133.166.52.29] (junkopc.tecno.csk.co.jp) by csktecnogw.tecno.csk.co.jp (4.1/6.4J.6) id AA15524; Tue, 5 Dec 95 14:51:05 JST Message-Id: <9512050551.AA15524@csktecnogw.tecno.csk.co.jp> Date: Tue, 5 Dec 1995 14:45:46 +0900 To: mbone From: jota@tecno.csk.co.jp (Junko Ota) X-Sender: jota@csktecnogw.tecno.csk.co.jp Cc: jota@tecno.csk.co.jp (Junko Ota) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Eudora-J(1.3.8.5-J13) unsubscribe Junko Ota ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $BB@ED=g;R(B <jota@jrsummit.org>$B!!(B GII$B%8%e%K%"%5%_%C%H!G#9#5(B $B!!!!!!!!!!(B 169 $B?7=I6h@>Aa0pED(B1-21-1$B!!AaBg@>Aa0pED%S%k#3(BF $B!!!!!!!!!!!!!!!!!!(B Tel: 03-5386-7150 Fax: 03-5286-7169 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From list-mgr@ISI.EDU Mon Dec 4 20:15:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26093>; Mon, 4 Dec 1995 22:20:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26055>; Mon, 4 Dec 1995 22:18:08 -0800 Received: from portal (portal.netedge.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA26048>; Mon, 4 Dec 1995 22:18:06 -0800 Received: from NetEdge.COM by portal id AA28778; Tue, 5 Dec 95 01:15:54 EST Received: from suicidesix.NetEdge.COM by NetEdge.COM id AA23180; Tue, 5 Dec 95 01:18:21 EST Return-Path: <Tom_Pusateri@NetEdge.COM> Received: from localhost by suicidesix.NetEdge.COM (4.1/NECL-6.14) id AA12248; Tue, 5 Dec 95 01:15:51 EST Message-Id: <9512050615.AA12248@NetEdge.COM> To: "Konstantin M. Scherbatukh" <kent@boy.nmd.msu.ru> Cc: mbone Subject: Re: DVMRP/PIM in Gated 3.5 B1 In-Reply-To: Your message of "Tue, 05 Dec 1995 01:24:51 +0300." <199512042224.BAA13981@boy.nmd.msu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <12245.818144150.1@suicidesix.netedge.com> Date: Tue, 05 Dec 1995 01:15:51 -0500 From: Thomas Pusateri <pusateri@NetEdge.COM> In message <199512042224.BAA13981@boy.nmd.msu.ru> you write: > >Hello! > >Does anybody test DVMRP or PIM implementation in Gated 3.5 B1? Gated PIM and DVMRP are being tested at Merit. PIM (dense) requires a kernel bug fix for Asserts in the 3.5 kernel but should be released soon for people to play with. DVMRP still has to go through the test -> bug fix -> test cycle. Tom From list-mgr@ISI.EDU Mon Dec 4 21:00:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27494>; Mon, 4 Dec 1995 23:08:30 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27259>; Mon, 4 Dec 1995 23:00:32 -0800 Received: from foghorn.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA27252>; Mon, 4 Dec 1995 23:00:30 -0800 Received: from localhost (young@localhost) by foghorn.reston.mci.net (8.6.12/8.6.9) with SMTP id CAA25649; Tue, 5 Dec 1995 02:00:25 -0500 Message-Id: <199512050700.CAA25649@foghorn.reston.mci.net> X-Authentication-Warning: foghorn.reston.mci.net: young owned process doing -bs X-Authentication-Warning: foghorn.reston.mci.net: Host localhost didn't use HELO protocol To: mbenson@davinci.gmu.edu (Michael Benson) Cc: mbone, vlaviano@cne.gmu.edu Subject: Re: MBONE In-Reply-To: Your message of "Mon, 04 Dec 1995 17:15:06 EST." <199512042215.RAA01862@davinci.gmu.edu> Date: Tue, 05 Dec 1995 02:00:24 -0500 From: "Jeff Young" <young@mci.net> can you provide details, mtraces, etc? Jeff Young young@mci.net > Date: Mon, 4 Dec 1995 17:15:06 -0500 (EST) > > Is anyone else having problems receiving the IETF conference from Dallas? > > Michael > > > > BTW, are they multicasting from down there. We're not receiving > > anything here, haven't been since around 3 pm EST. > > > > Vince > > > > > -- > Michael Benson > Computer science graduate student at George Mason University > WWW: http://cne.gmu.edu/~mbenson > Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Mon Dec 4 15:22:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27997>; Mon, 4 Dec 1995 23:23:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27980>; Mon, 4 Dec 1995 23:22:43 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA27973>; Mon, 4 Dec 1995 23:22:41 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id XAA00458; Mon, 4 Dec 1995 23:22:33 -0800 Message-Id: <199512050722.XAA00458@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: "Jeff Young" <young@mci.net> Cc: mbenson@davinci.gmu.edu (Michael Benson), mbone, vlaviano@cne.gmu.edu Subject: Re: MBONE In-Reply-To: Your message of "Tue, 05 Dec 1995 02:00:24 EST." <199512050700.CAA25649@foghorn.reston.mci.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Dec 1995 23:22:33 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Well, I watched tonite the MBONE BOF meeting right here on my home FreeBSD box 8) Cheers, Amancio >>> "Jeff Young" said: > can you provide details, mtraces, etc? > > Jeff Young > young@mci.net > > > Date: Mon, 4 Dec 1995 17:15:06 -0500 (EST) > > > > Is anyone else having problems receiving the IETF conference from Dallas? > > > > Michael > > > > > > BTW, are they multicasting from down there. We're not receiving > > > anything here, haven't been since around 3 pm EST. > > > > > > Vince > > > > > > > > > -- > > Michael Benson > > Computer science graduate student at George Mason University > > WWW: http://cne.gmu.edu/~mbenson > > Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson > From list-mgr@ISI.EDU Tue Dec 5 07:57:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19464>; Tue, 5 Dec 1995 10:00:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19445>; Tue, 5 Dec 1995 10:00:40 -0800 Received: from msf.psi.net. (msf.psi.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA19438>; Tue, 5 Dec 1995 10:00:39 -0800 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA05489; Tue, 5 Dec 1995 12:57:43 +0500 Message-Id: <9512051757.AA05489@msf.psi.net.> To: mbone Subject: mae-bone off the air Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <5487.818186262.1@msf.psi.net> Date: Tue, 05 Dec 1995 12:57:43 -0500 From: "Mark S. Fedor" <fedor@msf.psi.net> Content-Length: 156 Mae-bone.psi.net is now off the air. The MAE-East connection has hung again. MFS has been alerted and they are resetting now. Thanks, Mark Fedor PSINet From list-mgr@ISI.EDU Tue Dec 5 05:47:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03186>; Tue, 5 Dec 1995 13:40:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03159>; Tue, 5 Dec 1995 13:40:02 -0800 Received: from gatekeeper.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA03151>; Tue, 5 Dec 1995 13:39:59 -0800 Received: from able.MKT.3Com.COM by gatekeeper.3Com.COM with SMTP id AA16642 (5.65c/IDA-1.4.4-910725 for <mbone@isi.edu>); Tue, 5 Dec 1995 13:39:58 -0800 Received: by Able.MKT.3Com.Com id AA25678 (5.65c/IDA-1.4.4 for mbone@isi.edu); Tue, 5 Dec 1995 13:47:30 -0800 Date: Tue, 5 Dec 1995 13:47:30 -0800 From: Tom Maufer <maufer@mkt.3com.com> Message-Id: <199512052147.AA25678@Able.MKT.3Com.Com> To: mbone Subject: My slides from last night's MBONENG BOF Hi all-- I knew that Steve was running behind schedule last night, so I went kinda fast. If anyone wants a copy, I can mail it to you. I'll try to get it on the WWW, too. Cheers, Tom From list-mgr@ISI.EDU Tue Dec 5 05:50:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07604>; Tue, 5 Dec 1995 15:14:50 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07427>; Tue, 5 Dec 1995 15:13:04 -0800 Received: from darkstar.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA07420>; Tue, 5 Dec 1995 15:13:02 -0800 Received: from alpha.Xerox.COM by darkstar.isi.edu (5.65c/5.61+local-20) id <AA22017>; Tue, 5 Dec 1995 15:12:41 -0800 Received: from olympus.parc.xerox.com ([13.2.116.186]) by alpha.xerox.com with SMTP id <15527(9)>; Tue, 5 Dec 1995 13:50:41 PST Received: from localhost ([127.0.0.1]) by olympus.parc.xerox.com with SMTP id <14606>; Tue, 5 Dec 1995 13:50:26 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: mbone Subject: Re: MBONE In-Reply-To: Your message of "Mon, 04 Dec 1995 23:00:24 PST." <199512050700.CAA25649@foghorn.reston.mci.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 5 Dec 1995 13:50:14 PST From: Anders Klemets <klemets@parc.xerox.com> Message-Id: <95Dec5.135026pst.14606@olympus.parc.xerox.com> >> Is anyone else having problems receiving the IETF conference from Dallas? I am testing mrouted 4.0 on parts of Dartnet. Please report any problems that seem to involve Dartnet to me. Anders From list-mgr@ISI.EDU Wed Dec 6 20:25:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09361>; Tue, 5 Dec 1995 15:59:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09345>; Tue, 5 Dec 1995 15:59:27 -0800 Received: from mail.telstra.com.au by venera.isi.edu (5.65c/5.61+local-22) id <AA09334>; Tue, 5 Dec 1995 15:59:23 -0800 Received: from mail_gw.fwall.telecom.com.au(192.148.147.10) by mail via smap (V1.3) id sma009953; Wed Dec 6 04:32:42 1995 Received: from cdn_mail.dn.itg.telecom.com.au(144.135.109.134) by mail_gw.telecom.com.au via smap (V1.3) id sma005021; Wed Dec 6 10:25:57 1995 Received: from shiva.trl.OZ.AU (shiva.trl.OZ.AU [137.147.20.34]) by cdn_mail.dn.itg.telecom.com.au (8.6.11/8.6.9) with ESMTP id KAA22156 for <mbone@ISI.EDU>; Wed, 6 Dec 1995 10:25:56 +1100 Received: from [137.147.13.75] (arethusa.trl.OZ.AU [137.147.13.75]) by shiva.trl.OZ.AU (8.6.10/8.6.12) with SMTP id KAA01881 for <mbone@ISI.EDU>; Wed, 6 Dec 1995 10:25:51 +1100 Message-Id: <199512052325.KAA01881@shiva.trl.OZ.AU> X-Sender: oneill@shiva (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 6 Dec 1995 10:25:54 +1000 To: mbone From: c.oneill@trl.oz.au (Chris O'Neill) Subject: Plea to subscribers and unsubscribers who broadcast Given that there is a significant number of people who for some reason need to broadcast their requests to subscribe or unsubscribe, I'd appreciate it if you could put a subject in your message (i.e. "subscribe" or "unsubscribe"). This will help reduce the time I waste on such messages. Chris From list-mgr@ISI.EDU Tue Dec 5 09:39:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15080>; Tue, 5 Dec 1995 17:32:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15066>; Tue, 5 Dec 1995 17:31:52 -0800 Received: from gatekeeper.3Com.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA15056>; Tue, 5 Dec 1995 17:31:48 -0800 Received: from able.MKT.3Com.COM by gatekeeper.3Com.COM with SMTP id AA23681 (5.65c/IDA-1.4.4-910725 for <mbone@isi.edu>); Tue, 5 Dec 1995 17:31:46 -0800 Received: by Able.MKT.3Com.Com id AA26521 (5.65c/IDA-1.4.4); Tue, 5 Dec 1995 17:39:18 -0800 From: Tom Maufer <maufer@mkt.3com.com> Message-Id: <199512060139.AA26521@Able.MKT.3Com.Com> Subject: Re: My slides from last night's MBONENG BOF To: peppar@cdt.luth.se (Peter Parnes) Date: Tue, 5 Dec 95 17:39:17 PST Cc: mbone In-Reply-To: <199512052220.XAA07033@kalkyl.cdt.luth.se>; from "Peter Parnes" at Dec 5, 95 11:20 pm X-Mailer: ELM [version 2.3 PL11] > I'd like a copy of your slides (a url will be enough). Peter-- Well, the best I can do from here is to get an ftp site set up. Anyone can feel free to ftp to nsd-beta.3com.com and log in as 'mboneng' with password 'bof' (omit the quotes in both cases, of course). There is a .ps file in the directory you'll be dropped into, and a mbonengbof.GIF subdirectory that has 11 GIF images in it. Feel free to direct any questions to me. Cheers, Tom From list-mgr@ISI.EDU Thu Dec 7 03:27:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14987>; Tue, 5 Dec 1995 17:30:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14966>; Tue, 5 Dec 1995 17:29:47 -0800 Received: from grace.waikato.ac.nz by venera.isi.edu (5.65c/5.61+local-22) id <AA14959>; Tue, 5 Dec 1995 17:29:44 -0800 Received: from waikato.ac.nz by waikato.ac.nz (PMDF V5.0-4 #11755) id <01HYHNTFYQGKAI96AQ@waikato.ac.nz> for MBONE@ISI.EDU; Wed, 06 Dec 1995 14:27:17 +1300 Date: Wed, 06 Dec 1995 14:27:17 +1300 From: Hamish Marson <HAMISH@waikato.ac.nz> Subject: unsubscribe To: MBONE Message-Id: <01HYHNTFYQGMAI96AQ@waikato.ac.nz> X-Vms-To: IN%"MBONE@ISI.EDU" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT From list-mgr@ISI.EDU Wed Dec 6 20:01:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16472>; Tue, 5 Dec 1995 18:03:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16366>; Tue, 5 Dec 1995 18:01:20 -0800 Received: from sh.iij-mc.co.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA16356>; Tue, 5 Dec 1995 18:01:13 -0800 Received: from mcgw.iij-mc.co.jp (root@mcgw.iij-mc.co.jp [192.168.10.2]) by sh.iij-mc.co.jp (8.6.12+2.4W/3.4W2) with ESMTP id LAA09327 for <mbone@isi.edu>; Wed, 6 Dec 1995 11:01:08 +0900 Received: from teapot (bunji@localhost [127.0.0.1]) by mcgw.iij-mc.co.jp (8.6.12+2.5Wb7/3.4W) with ESMTP id LAA18132; Wed, 6 Dec 1995 11:01:07 +0900 Message-Id: <199512060201.LAA18132@mcgw.iij-mc.co.jp> To: mbone Cc: hiroshima@iij-mc.co.jp Subject: The FUTURE OF HOPE Conference In-Reply-To: Your message of "Mon, 04 Dec 1995 11:42:31 +0900" References: <199512040242.LAA22780@mcgw.iij-mc.co.jp> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii From: YAMAMOTO Bunji <bunji@iij-mc.co.jp> X-Mailer: Mew version 1.00.4 on Emacs 19.28.2, Mule 2.3 Date: Wed, 06 Dec 1995 11:01:06 +0900 Sender: bunji@mcgw.iij-mc.co.jp [This is re-announce. But session planning is changed.] We will broadcast this session at Dec 6. This session is for "The FUTURE OF HOPE Conference" from Hiroshima, JAPAN and will be used for conference via the Internet from Hiroshima, Pretoria, Jerusalem and Atlanta. Contents: The Future of Hope Internet Conference Session Name: Future of Hope Media: vat, nv Bandwidth: 50kbps(vat), 32kbps(nv) From: Dec 6 02:00 UTC Till: Dec 6 13:00 UTC Init TTL: 191(vat), 223(nv) Contact: hiroshima@iij-mc.co.jp WWW: http://www.iijnet.or.jp/HIROSHIMA/mbone.html (Mbone Info) http://www.iijnet.or.jp/HIROSHIMA/ -- YAMAMOTO Bunji <bunji@iij-mc.co.jp> IIJ Media Communications Inc. From list-mgr@ISI.EDU Wed Dec 6 06:53:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22009>; Tue, 5 Dec 1995 20:55:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21978>; Tue, 5 Dec 1995 20:54:32 -0800 Received: from ncc.ripe.net by venera.isi.edu (5.65c/5.61+local-22) id <AA21971>; Tue, 5 Dec 1995 20:54:30 -0800 Received: from ncc.ripe.net by ncc.ripe.net with SMTP id AA18444 (5.65a/NCC-2.30); Wed, 6 Dec 1995 05:53:50 +0100 Message-Id: <9512060453.AA18444@ncc.ripe.net> To: c.oneill@trl.oz.au (Chris O'Neill) Cc: mbone From: Geert Jan de Groot <GeertJan.deGroot@ripe.net> X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: Re: broadcasting (un)subscribers In-Reply-To: Your message of "Wed, 06 Dec 1995 10:25:54 +1000." <199512052325.KAA01881@shiva.trl.OZ.AU> Date: Wed, 06 Dec 1995 05:53:47 +0100 Sender: GeertJan.deGroot@ripe.net Sending (un)subscribe messages to the mailing list is *never* appropiate. If you want to get off, always use the -request address. (you ought to know - you managed to subscribe too, remember?). Please don't *ever* send subscribe requests to any mailing list. You will only reach many people who cannot help you, and it is likely that you will *not* reach the person who *can* help you. I kindly ask everyone who receives an (un)subscribe message to respond to the original sender individually and not via the list. The many responses ought to have educational value without disturbing the list. The amount of responses will reduce the chance of having the mistake repeated. Thanks, Geert Jan On Wed, 6 Dec 1995 10:25:54 +1000 Chris O'Neill wrote: > Given that there is a significant number of people who for some reason need > to broadcast their requests to subscribe or unsubscribe, I'd appreciate it > if you could put a subject in your message (i.e. "subscribe" or > "unsubscribe"). This will help reduce the time I waste on such messages. From list-mgr@ISI.EDU Thu Dec 7 03:21:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00353>; Wed, 6 Dec 1995 01:26:30 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00159>; Wed, 6 Dec 1995 01:24:47 -0800 Received: from glory.kaist.ac.kr by venera.isi.edu (5.65c/5.61+local-22) id <AA00152>; Wed, 6 Dec 1995 01:24:36 -0800 Received: (from joyoon@localhost) by glory.kaist.ac.kr (8.6.9H1/8.6.9) id SAA01066 for mbone@ISI.EDU; Wed, 6 Dec 1995 18:21:26 +0900 From: Joong-One Yoon <joyoon@glory.kaist.ac.kr> Message-Id: <199512060921.SAA01066@glory.kaist.ac.kr> Subject: Unsubscribe To: mbone Date: Wed, 6 Dec 1995 18:21:26 +0900 (JST) X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 13 Unsubscribe From list-mgr@ISI.EDU Wed Dec 6 09:38:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00820>; Wed, 6 Dec 1995 01:42:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00755>; Wed, 6 Dec 1995 01:39:03 -0800 Received: from mailsun.aber.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA00746>; Wed, 6 Dec 1995 01:38:54 -0800 Received: from mailhost.aber.ac.uk (actually host saturn.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Wed, 6 Dec 1995 09:38:36 +0000 To: Tom Maufer <maufer@mkt.3com.com> Cc: mbone, dap@aber.ac.uk Subject: Re: My slides from last night's MBONENG BOF In-Reply-To: Your message of Tue, 05 Dec 1995 13:47:30 -0800. <199512052147.AA25678@Able.MKT.3Com.Com> Date: Wed, 06 Dec 1995 09:38:30 +0000 Message-Id: <14383.818242710@mailhost.aber.ac.uk> From: D E PRICE <dap@aber.ac.uk> Dear Tom, I'm afraid we missed all your talk.... An email of the slides you used you be very much appreciated. Dave Price From list-mgr@ISI.EDU Wed Dec 6 11:45:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01351>; Wed, 6 Dec 1995 01:58:50 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01331>; Wed, 6 Dec 1995 01:58:09 -0800 Received: from mailgate.ericsson.se by venera.isi.edu (5.65c/5.61+local-22) id <AA01323>; Wed, 6 Dec 1995 01:58:00 -0800 Received: from eua.ericsson.se (eua.ericsson.se [134.138.132.16]) by mailgate.ericsson.se (8.6.11/1.0) with SMTP id KAA04395 for <mbone@ISI.EDU>; Wed, 6 Dec 1995 10:57:46 +0100 Received: from ms.eua.ericsson.se by eua.ericsson.se (4.1/EUA-2.1) id AA00375; Wed, 6 Dec 95 10:45:27 +0100 Received: from euas78c16.eua.ericsson.se by ms.eua.ericsson.se (4.1/MS-2.1) id AA01470; Wed, 6 Dec 95 10:45:26 +0100 From: Jakob.Ellerstedt@eua.ericsson.se (Jakob Ellerstedt) Received: by euas78c16.eua.ericsson.se (5.x/client-1.3) id AA16675; Wed, 6 Dec 1995 10:45:26 +0100 Date: Wed, 6 Dec 1995 10:45:26 +0100 Message-Id: <9512060945.AA16675@euas78c16.eua.ericsson.se> To: mbone Subject: h261 on vic2.6/vic2.7alpha X-Sun-Charset: ISO-8859-1 Hi! Running vic2.6 on monday evening's session from IETF resulted in error messages about unknown h261 format. Though, with vic2.7alpha, h261 was no problem. Why? Is one of them 'tuned', inserting a discrepancy in comparison to the standard? /Jakob @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@ Jakob Ellerstedt, @@ @@ Ericsson Telecom Systems Labs, Stockholm, Sweden @@ @@ Box 1505 @@ @@ 125 25 DLVSJV @@ @@ phone + 46 8 727 43 82 @@ @@ fax + 46 8 647 82 76 @@ @@ e-mail: Jakob.Ellerstedt@eua.ericsson.se @@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ From list-mgr@ISI.EDU Wed Dec 6 09:38:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00820>; Wed, 6 Dec 1995 01:42:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00755>; Wed, 6 Dec 1995 01:39:03 -0800 Received: from mailsun.aber.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA00746>; Wed, 6 Dec 1995 01:38:54 -0800 Received: from mailhost.aber.ac.uk (actually host saturn.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Wed, 6 Dec 1995 09:38:36 +0000 To: Tom Maufer <maufer@mkt.3com.com> Cc: mbone, dap@aber.ac.uk Subject: Re: My slides from last night's MBONENG BOF In-Reply-To: Your message of Tue, 05 Dec 1995 13:47:30 -0800. <199512052147.AA25678@Able.MKT.3Com.Com> Date: Wed, 06 Dec 1995 09:38:30 +0000 Message-Id: <14383.818242710@mailhost.aber.ac.uk> From: D E PRICE <dap@aber.ac.uk> Dear Tom, I'm afraid we missed all your talk.... An email of the slides you used you be very much appreciated. Dave Price From list-mgr@ISI.EDU Tue Dec 5 19:20:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02556>; Wed, 6 Dec 1995 03:20:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02544>; Wed, 6 Dec 1995 03:20:10 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA02537>; Wed, 6 Dec 1995 03:20:09 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id DAA00918 for <mbone@ISI.EDU>; Wed, 6 Dec 1995 03:20:05 -0800 Message-Id: <199512061120.DAA00918@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: mbone Subject: Re: My slides from last night's MBONENG BOF In-Reply-To: Your message of "Tue, 05 Dec 1995 17:39:17 PST." <199512060139.AA26521@Able.MKT.3Com.Com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Dec 1995 03:20:04 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Actually can the MBONE BOF be re-brocasted , I caught a portion of the meeting;however, I missed a lot of it. Quite a few things caught my interest: o The robustness of the MBONE o Demand for MBONE services --- I think that once mbone tools get deployed to Win95 we will see a sharp increase on demand for MBONE services. o Bandwidth --- althought 500mbits may seem like a lot I think that it may not be enough to transmit something like mpeg-1 system streams. o mrouted 2.2 support to be drop out in the near future (grin) Enjoy, Amancio From list-mgr@ISI.EDU Wed Dec 6 12:28:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04550>; Wed, 6 Dec 1995 04:39:09 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04528>; Wed, 6 Dec 1995 04:38:39 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA04315>; Wed, 6 Dec 1995 04:33:16 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id MAA01072; Wed, 6 Dec 1995 12:29:06 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id MAA05592; Wed, 6 Dec 1995 12:29:01 GMT Date: Wed, 6 Dec 1995 12:28:58 +0000 (GMT) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: mbone Subject: Re: My slides from last night's MBONENG BOF In-Reply-To: <199512061120.DAA00918@rah.star-gate.com> Message-Id: <Pine.SV4.3.91.951206122807.5378A-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 6 Dec 1995, Amancio Hasty Jr. wrote: > o Bandwidth --- althought 500mbits may seem like a lot I think that it may > not be enough to transmit something like mpeg-1 system streams. I assume you mean 500kbits. I think you could transfer a large number of mpeg-1 streams over 500mbits. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Wed Dec 6 14:54:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05382>; Wed, 6 Dec 1995 05:10:34 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05359>; Wed, 6 Dec 1995 05:09:18 -0800 Received: from hydra.informatik.uni-ulm.de by venera.isi.edu (5.65c/5.61+local-22) id <AA05343>; Wed, 6 Dec 1995 05:08:14 -0800 Received: from octavian.informatik.uni-ulm.de (octavian [134.60.69.144]) by hydra.informatik.uni-ulm.de (8.6.9/8.6.9) with SMTP id OAA05056 for <mbone@isi.edu>; Wed, 6 Dec 1995 14:05:03 +0100 Received: by octavian.informatik.uni-ulm.de (5.x/SMI-SVR4) id AA00451; Wed, 6 Dec 1995 13:54:53 +0100 Date: Wed, 6 Dec 1995 13:54:53 +0100 From: aspecker@hydra.informatik.uni-ulm.de (Alexander Specker) Message-Id: <9512061254.AA00451@octavian.informatik.uni-ulm.de> To: mbone Subject: vic2.7 X-Sun-Charset: US-ASCII When I am using vic2.7 I get the following error message: vic: "init_resources": can't read "name": no such variable Any hints? Thanks alex ---------------------------------------------------------------- Alexander Specker aspecker@hydra.informatik.uni-ulm.de Gerbergasse 1 specker@faw.uni-ulm.de 89073 Ulm, Germany URL: http://www.uni-ulm.de/~s_aspec1/ Tel. 0731/63643 Tel.(FAW): 0731/501-8691 From list-mgr@ISI.EDU Wed Dec 6 15:17:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05843>; Wed, 6 Dec 1995 05:28:15 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05830>; Wed, 6 Dec 1995 05:27:29 -0800 Received: from piraya.electrum.kth.se by venera.isi.edu (5.65c/5.61+local-22) id <AA05823>; Wed, 6 Dec 1995 05:27:26 -0800 Received: from it.kth.se (drum.electrum.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id OAA05276; Wed, 6 Dec 1995 14:13:39 +0100 Message-Id: <199512061313.OAA05276@piraya.electrum.kth.se> X-Mailer: exmh version 1.5.2 12/21/94 To: aspecker@hydra.informatik.uni-ulm.de (Alexander Specker) Cc: mbone, e93_mda@it.kth.se Subject: Re: vic2.7 In-Reply-To: Your message of "Wed, 06 Dec 1995 13:54:53 +0100." <9512061254.AA00451@octavian.informatik.uni-ulm.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Dec 1995 14:17:44 +0100 From: Magnus <e93_mda@it.kth.se> > > When I am using vic2.7 I get the following > error message: > > vic: "init_resources": can't read "name": no such variable > > Any hints? try adding -N <your name> to the command line, something like: vat -N Magnus -t 42 239.93.17.11/9512 Bring in a -C <your session> also, it usually complains about that too... Why doesn't it just display an window with those questions? Magnus From list-mgr@ISI.EDU Wed Dec 6 15:49:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06597>; Wed, 6 Dec 1995 05:51:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06585>; Wed, 6 Dec 1995 05:50:31 -0800 Received: from survis.surfnet.nl by venera.isi.edu (5.65c/5.61+local-22) id <AA06578>; Wed, 6 Dec 1995 05:50:29 -0800 Received: from SURFnet.nl (actually surah.surfnet.nl) by survis.surfnet.nl with SMTP (PP); Wed, 6 Dec 1995 14:49:52 +0100 X-Mailer: exmh version 1.6.4 10/10/95 To: Magnus <e93_mda@it.kth.se> Cc: aspecker@hydra.informatik.uni-ulm.de (Alexander Specker), mbone Subject: Re: vic2.7 In-Reply-To: Your message of Wed, 06 Dec 1995 14:17:44 +0100 with id <199512061313.OAA05276@piraya.electrum.kth.se> Organisation: SURFnet Expertisecentrum Address: Radboudburcht, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 2305305 Telefax: +31 30 2305329 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Dec 1995 14:49:52 +0100 Message-Id: <2091.818257792@SURFnet.nl> From: Xander Jansen <Xander.Jansen@SURFnet.nl> In your message of Wed, 06 Dec 1995 14:17:44 +0100 you wrote: + > When I am using vic2.7 I get the following + > error message: + > + > vic: "init_resources": can't read "name": no such variable + > + > Any hints? + + try adding -N <your name> to the command line, something like: + + vat -N Magnus -t 42 239.93.17.11/9512 + + Bring in a -C <your session> also, it usually complains about that too... + + Why doesn't it just display an window with those questions? vic2.7a30 has a bug which prevents it from starting when it cannot find a specific font (I think it's a times font somewhere). If you have the font all's well, if not, vic just won't start complaining about the "name" variable. vic2.7a31 has a fix for this problem. a31 just complains about the missing font and reverts to the default font (fixed or whatever your server has as default). All credits go to Steven McCanne for this fix and for the fastest bug fix I've ever encountered (less than half an hour after I sent him a message about this error I got a working a31 ;-) Xander From list-mgr@ISI.EDU Wed Dec 6 08:00:47 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17131>; Wed, 6 Dec 1995 10:01:35 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17105>; Wed, 6 Dec 1995 10:01:03 -0800 Received: from relay.nswc.navy.mil by venera.isi.edu (5.65c/5.61+local-22) id <AA17090>; Wed, 6 Dec 1995 10:00:51 -0800 Received: from sunoco (sunoco.nswc.navy.mil) by relay.nswc.navy.mil (4.1/SMI-4.1) id AA17498; Wed, 6 Dec 95 13:00:20 EST Received: from sparhawk.b35ita.sunoco by sunoco (5.x/SMI-SVR4) id AA13416; Wed, 6 Dec 1995 13:00:47 -0500 Received: by sparhawk.b35ita.sunoco (5.x/SMI-SVR4) id AA27115; Wed, 6 Dec 1995 13:00:47 -0500 Date: Wed, 6 Dec 1995 13:00:47 -0500 From: tplunke@relay.nswc.navy.mil (Tim Plunkett) Message-Id: <9512061800.AA27115@sparhawk.b35ita.sunoco> Subject: recording a vic session To: mbone It looks like the video for the IETF sessions are being sent using vic instead of nv. I was wondering if there is a way to record vic video sessions similarly to the way that nv_record works. If tools such as "vic_record" and "vic_play" exist, could someone point me in the right direction for getting them. Thanks in advance. Tim Plunkett tplunke@relay.nswc.navy.mil From list-mgr@ISI.EDU Wed Dec 6 08:28:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18177>; Wed, 6 Dec 1995 10:26:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18158>; Wed, 6 Dec 1995 10:26:12 -0800 Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-22) id <AA18150>; Wed, 6 Dec 1995 10:26:11 -0800 Received: from esherk.uu.net by rodan.UU.NET with SMTP id QQzsyz01790; Wed, 6 Dec 1995 13:26:11 -0500 Received: from localhost by esherk.uu.net with SMTP (leaf) id QQzsyz03531; Wed, 6 Dec 1995 13:28:45 -0500 Message-Id: <QQzsyz03531.199512061828@esherk.uu.net> To: mbone Subject: What do these messages mean? Date: Wed, 06 Dec 1995 13:28:45 -0500 From: Erik Sherk <sherk@uunet.uu.net> Hi, I can't recall what these messages mean. Can someone refresh me? Also, 192.41.177.197 is running 3.8. Erik ------- Forwarded Message Return-Path: rromine@nsf.gov Received: from relay3.UU.NET by rodan.UU.NET with SMTP id QQzsyt10902; Wed, 6 Dec 1995 11:45:32 -0500 From: rromine@nsf.gov Received: from mailbox.sura.net by relay3.UU.NET with SMTP id QQzsyt04130; Wed, 6 Dec 1995 11:45:31 -0500 (EST) Received: from note1.nsf.gov (note1.nsf.gov [128.150.11.1]) by mailbox.sura.net (8.6.12/8.6.6) with SMTP id LAA27673 for <sherk@sura.net>; Wed, 6 Dec 1995 11:45:30 -0500 Received: from localhost by note1.nsf.gov with SMTP id AA22255 (5.65c/IDA-1.4.4 for <sherk@sura.net>); Wed, 6 Dec 1995 11:47:51 -0500 To: Erik Sherk <sherk@sura.net> Cc: rromine@nsf.gov Subject: Mrouted error messages Date: Wed, 06 Dec 95 11:47:51 EST Message-Id: <18669.818268471@nsf.gov> Erik, I'm getting *lots* of error messages from mrouted about "192.41.177.197 reports an invalid origin (204.94.248.0) and/or mask (fffffe00)" The origin and mask numbers change. The message is coming up every few seconds. Any ideas? My syslog is filling up my disk. Raleigh ------- End of Forwarded Message From list-mgr@ISI.EDU Wed Dec 6 07:04:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20176>; Wed, 6 Dec 1995 11:05:24 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20108>; Wed, 6 Dec 1995 11:04:59 -0800 Received: from achilles.ctd.anl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA20101>; Wed, 6 Dec 1995 11:04:57 -0800 Received: (from curtis@localhost) by achilles.ctd.anl.gov (8.6.11/8.6.11) id NAA27185 for mbone@isi.edu; Wed, 6 Dec 1995 13:04:56 -0600 Date: Wed, 6 Dec 1995 13:04:56 -0600 Message-Id: <199512061904.NAA27185@achilles.ctd.anl.gov> To: mbone Subject: ipmulti-3.5 breaks SunOS multiple le From: "Jeffrey S. Curtis" <curtis@anl.gov> Installing the v3.5 multicasting patches onto a SunOS 4.1.3 or 4.1.4 machine with more than one le ethernet interface causes all of the le interfaces except for le0 to not function. This may be related to Sun patch number 101954-06; I'm not sure. When the machine is brought up with the patched kernel, the console shows errors such as: le1: TINT but buffer owned by LANCE Has anyone found a way to get multicasting kernels onto a Sun with multiple le interfaces? Is there any hope of getting a new if_le.o that has multicast functionality but supports multiple le interfaces? Thanks, Jeff -- Jeffrey S. Curtis | Internetwork Manager Argonne National Laboratory | Email: curtis@anl.gov 9700 South Cass Avenue, ECT-221 | Voice: 708/252-1789 Argonne, IL 60439 | Fax: 708/252-9689 From list-mgr@ISI.EDU Wed Dec 6 03:16:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20864>; Wed, 6 Dec 1995 11:17:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20827>; Wed, 6 Dec 1995 11:17:19 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA20820>; Wed, 6 Dec 1995 11:17:18 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id LAA01724; Wed, 6 Dec 1995 11:16:31 -0800 Message-Id: <199512061916.LAA01724@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Graeme.Wood@ucs.ed.ac.uk Cc: mbone Subject: Re: My slides from last night's MBONENG BOF In-Reply-To: Your message of "Wed, 06 Dec 1995 12:28:58 GMT." <Pine.SV4.3.91.951206122807.5378A-100000@scorpio.ucs.ed.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Dec 1995 11:16:30 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> >>> Graeme Wood said: > On Wed, 6 Dec 1995, Amancio Hasty Jr. wrote: > > > o Bandwidth --- althought 500mbits may seem like a lot I think that it may > > not be enough to transmit something like mpeg-1 system streams. > > I assume you mean 500kbits. I think you could transfer a large number of > mpeg-1 streams over 500mbits. > There I go again dreaming about public ATM network 8) Yes, I meant 500kilobits/second Amancio From list-mgr@ISI.EDU Wed Dec 6 04:14:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24702>; Wed, 6 Dec 1995 12:15:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24667>; Wed, 6 Dec 1995 12:15:14 -0800 Received: from puli.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA24660>; Wed, 6 Dec 1995 12:15:13 -0800 Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with ESMTP id MAA02408; Wed, 6 Dec 1995 12:14:39 -0800 Message-Id: <199512062014.MAA02408@puli.cisco.com> To: "Jeffrey S. Curtis" <curtis@anl.gov> Cc: mbone Subject: Re: ipmulti-3.5 breaks SunOS multiple le In-Reply-To: Your message of "Wed, 06 Dec 1995 13:04:56 CST." <199512061904.NAA27185@achilles.ctd.anl.gov> Date: Wed, 06 Dec 1995 12:14:38 -0800 From: "John M. Zwiebel" <jzwiebel@cisco.com> > Installing the v3.5 multicasting patches onto a SunOS 4.1.3 or 4.1.4 > machine with more than one le ethernet interface causes all of the le I don't think so. I have installed it on sparc 5, 10 and 20 all with multiple le interfaces. See the example below. z jzwiebel@media1-ss5% ifconfig -a le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING> inet 172.21.120.53 netmask ffffff00 broadcast 172.21.120.255 le1: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING> inet 171.69.215.44 netmask fffffff8 broadcast 171.69.215.47 le2: flags=843<UP,BROADCAST,RUNNING> inet 171.69.214.70 netmask fffffff8 broadcast 171.69.214.71 lo0: flags=849<UP,LOOPBACK,RUNNING> inet 127.0.0.1 netmask ff000000 jzwiebel@media1-ss5% uname -a SunOS media1-ss 4.1.3_U1 1 sun4m From list-mgr@ISI.EDU Wed Dec 6 05:24:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29056>; Wed, 6 Dec 1995 13:22:47 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA29049>; Wed, 6 Dec 1995 13:22:45 -0800 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id NAA10667; Wed, 6 Dec 1995 13:24:06 -0800 Message-Id: <199512062124.NAA10667@rx7.ee.lbl.gov> To: daw@sunergos.cray.com Cc: mbone-na, dab@berserkly.cray.com Subject: daw@sunergos.cray.com "Artesian Dreams" session is trashing other mbone sessions Date: Wed, 06 Dec 95 13:24:05 PST From: Van Jacobson <van@ee.lbl.gov> I don't know if you realize it but your "Artesian Dreams" is going out to about 20,000 hosts all over the world. The MBone only has a total of 500kb/s of bandwidth (about 3 active session's worth) and is carefully scheduled to avoid conflicts. This week it is completely booked with a number of events including two sessions from the Dallas IETF meeting, seminars from UCB, CERN and MIT, etc. The audio and video you are sending pushes the total traffic over the 500kb/s limit and that causes losses on all sessions, not just yours. Could you please stop your session or recreate it at a much lower ttl (<16). Thanks. - Van Jacobson ps- Whatever video tool you are using is completely broken. It is sending out video frames as a burst of 12 back-to-back packets followed by 5 seconds of nothing. These huge traffic bursts are doing quite a lot of damage. If you plan to send wide area video in the future, I would suggest you get the current versions of either vic or nv -- both have smoothing rate limiters that prevent this kind of behavior and are much kinder to the Mbone infrastructure. From list-mgr@ISI.EDU Wed Dec 6 09:40:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01270>; Wed, 6 Dec 1995 13:42:46 -0800 Received: from timbuk.cray.com by venera.isi.edu (5.65c/5.61+local-22) id <AA01263>; Wed, 6 Dec 1995 13:42:44 -0800 Received: from berserkly.cray.com (berserkly.cray.com [128.162.96.70]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id PAA29357 for <mbone-na@isi.edu>; Wed, 6 Dec 1995 15:42:43 -0600 Received: by berserkly.cray.com id AA26900; 5.64/CRI-4.9; Wed, 6 Dec 95 15:40:05 -0600 Date: Wed, 6 Dec 95 15:40:05 -0600 From: dab@berserkly.cray.com (David Borman) Message-Id: <9512062140.AA26900@berserkly.cray.com> To: daw@berserkly.cray.com, van@ee.lbl.gov Subject: Re: daw@sunergos.cray.com "Artesian Dreams" session is trashing other mbone sessions Cc: aal@berserkly.cray.com, mbone-na, rtf@berserkly.cray.com I am unable to get a hold of David Wright, so in the meantime I have temporarly shut off our tunnel to the MBONE until this is fixed. -David Borman, dab@cray.com > From van@ee.lbl.gov Wed Dec 6 15:20:13 1995 > To: daw@sunergos.cray.com > Cc: mbone-na@isi.edu, dab@berserkly.cray.com > Subject: daw@sunergos.cray.com "Artesian Dreams" session is trashing other mbone sessions > Date: Wed, 06 Dec 95 13:24:05 PST > From: Van Jacobson <van@ee.lbl.gov> > > I don't know if you realize it but your "Artesian Dreams" is going > out to about 20,000 hosts all over the world. The MBone only has > a total of 500kb/s of bandwidth (about 3 active session's worth) > and is carefully scheduled to avoid conflicts. This week it is > completely booked with a number of events including two sessions > from the Dallas IETF meeting, seminars from UCB, CERN and MIT, etc. > The audio and video you are sending pushes the total traffic over > the 500kb/s limit and that causes losses on all sessions, not just > yours. Could you please stop your session or recreate it at a much > lower ttl (<16). Thanks. > > - Van Jacobson > > ps- Whatever video tool you are using is completely broken. It is > sending out video frames as a burst of 12 back-to-back packets > followed by 5 seconds of nothing. These huge traffic bursts > are doing quite a lot of damage. If you plan to send wide area > video in the future, I would suggest you get the current versions > of either vic or nv -- both have smoothing rate limiters that > prevent this kind of behavior and are much kinder to the Mbone > infrastructure. From list-mgr@ISI.EDU Wed Dec 6 12:14:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04593>; Wed, 6 Dec 1995 14:18:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04080>; Wed, 6 Dec 1995 14:14:07 -0800 Received: from foghorn.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA04072>; Wed, 6 Dec 1995 14:14:05 -0800 Received: from localhost (young@localhost) by foghorn.reston.mci.net (8.6.12/8.6.9) with SMTP id RAA02347; Wed, 6 Dec 1995 17:14:03 -0500 Message-Id: <199512062214.RAA02347@foghorn.reston.mci.net> X-Authentication-Warning: foghorn.reston.mci.net: young owned process doing -bs X-Authentication-Warning: foghorn.reston.mci.net: Host localhost didn't use HELO protocol To: mbone Cc: mbone@mci.net Subject: Tunnels which transit the MCI backbone Date: Wed, 06 Dec 1995 17:14:03 -0500 From: "Jeff Young" <young@mci.net> I've done a quick and easy compare of Matt Mathis's mbone global.map (ftp://ftp.psc.edu/pub/mbone/global.map) and the MCI routing registry. This indicates tunnels which may be using the MCI internet backbone as transit. Some tunnels listed may not exist (global.map was last produced in september) and others may not transit MCI (if the routes are backup, not primary). I expect that this is going to cause some controversy, but i'd like to post it here with the suggestion that we try to clean this up a bit. At this point we have a pretty good infrastructure and i'd like to begin moving tunnels which transit us to the nearest service provider or to MCI directly where this is possible. The list has a self explanatory form, first number is tunnel endpoint #1 the second number is tunnel endpoint #2. At the end of each line the orginization(s) responsible for the MCI routing registry entry/entries is/are listed. Multiple route maintainers are separated by a colon. for example the first entry is a tunnel between 192.187.8.2 and 130.94.40.6. the first machine's network is not listed in the MCI RR, the second is listed and maintained by JVNCnet. I've not yet checked the dns to see who owns this machine. Once you see the list you'll understand my motivation :-) ns2# grok_mbone_paths 192.187.8.2 to 130.94.40.6 may be routed thru MCI unknown:JVNCNET 192.187.8.2 to 192.101.21.8 may be routed thru MCI unknown:NCREN-MAINT-MCI 199.26.254.13 to 206.197.101.5 may be routed thru MCI unknown:SURA 192.31.48.211 to 192.203.230.241 may be routed thru MCI BARRNET:SURA 199.45.11.20 to 130.65.151.50 may be routed thru MCI BARRNET:CSU 199.45.11.20 to 130.65.44.2 may be routed thru MCI BARRNET:CSU 199.45.11.20 to 45.0.12.159 may be routed thru MCI BARRNET:SURA 199.45.11.20 to 45.0.13.147 may be routed thru MCI BARRNET:SURA 137.82.112.4 to 192.35.180.20 may be routed thru MCI BARRNET:NWNET-MAINT-MCI 132.203.2.15 to 35.12.7.198 may be routed thru MCI BARRNET:MERIT-MAINT-MCI 192.217.65.100 to 128.241.0.91 may be routed thru MCI CICNET-NS:SESQUINET-MAINT-MCI 192.217.65.100 to 198.108.2.20 may be routed thru MCI CICNET-NS:MERIT-MAINT-MCI 129.89.9.30 to 204.188.121.18 may be routed thru MCI CICNET-NS:RGNET-MAINT-MCI 128.146.116.8 to 199.18.104.2 may be routed thru MCI CICNET-NS:OARNET-MAINT-MCI 192.17.2.8 to 128.241.0.91 may be routed thru MCI CICNET-NS:SESQUINET-MAINT-MCI 192.17.2.8 to 192.52.106.7 may be routed thru MCI CICNET-NS:MAINT-AS194 192.17.2.8 to 192.88.114.10 may be routed thru MCI CICNET-NS:PSC-MAINT-MCI 204.188.121.18 to 129.89.9.30 may be routed thru MCI RGNET-MAINT-MCI:CICNET-NS 130.94.40.6 to 198.108.2.20 may be routed thru MCI JVNCNET:MERIT-MAINT-MCI 130.94.40.6 to 192.187.8.2 may be routed thru MCI JVNCNET:MERIT-MAINT-MCI 130.94.40.6 to 140.116.2.8 may be routed thru MCI JVNCNET:MERIT-MAINT-MCI 130.94.40.6 to 132.206.35.8 may be routed thru MCI JVNCNET:MERIT-MAINT-MCI 198.108.2.20 to 130.94.40.6 may be routed thru MCI MERIT-MAINT-MCI:JVNCNET 198.108.2.20 to 192.88.114.10 may be routed thru MCI MERIT-MAINT-MCI:PSC-MAINT-MCI 198.108.2.20 to 192.217.65.100 may be routed thru MCI MERIT-MAINT-MCI:CICNET-NS 198.247.225.251 to 192.65.218.14 may be routed thru MCI MID-MAINT-MCI:DRA-MAINT-MCI 129.237.125.70 to 198.207.141.151 may be routed thru MCI MID-MAINT-MCI:MRNET-MAINT-MCI 129.237.125.70 to 198.207.141.46 may be routed thru MCI MID-MAINT-MCI:MRNET-MAINT-MCI 129.237.125.70 to 198.207.141.127 may be routed thru MCI MID-MAINT-MCI:MRNET-MAINT-MCI 129.237.125.70 to 198.207.141.4 may be routed thru MCI MID-MAINT-MCI:MRNET-MAINT-MCI 198.112.8.2 to 192.88.114.10 may be routed thru MCI NEARNET:PSC-MAINT-MCI 18.24.0.1 to 132.174.43.192 may be routed thru MCI NEARNET:OARNET-MAINT-MCI 18.24.0.1 to 132.176.41.192 may be routed thru MCI NEARNET:OARNET-MAINT-MCI 18.24.0.1 to 132.178.42.192 may be routed thru MCI NEARNET:OARNET-MAINT-MCI 18.24.0.1 to 132.191.41.192 may be routed thru MCI NEARNET:OARNET-MAINT-MCI 18.24.0.1 to 132.194.40.192 may be routed thru MCI NEARNET:WESTNET-MAINT-MCI 18.24.0.1 to 132.195.43.192 may be routed thru MCI NEARNET:WESTNET-MAINT-MCI 18.24.0.1 to 132.196.42.192 may be routed thru MCI NEARNET:WESTNET-MAINT-MCI 18.24.0.1 to 134.192.42.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 135.23.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 139.206.51.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 147.166.41.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 149.94.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 149.97.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 151.100.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 153.156.38.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 153.182.41.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 154.81.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 154.82.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 154.83.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 154.84.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 154.85.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 154.86.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 154.87.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 154.88.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 154.90.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 160.189.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 160.190.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 160.253.40.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 160.94.43.192 may be routed thru MCI NEARNET:CICNET-NS 18.24.0.1 to 168.200.47.192 may be routed thru MCI NEARNET:WESTNET-MAINT-MCI 18.24.0.1 to 168.201.47.192 may be routed thru MCI NEARNET:WESTNET-MAINT-MCI 18.24.0.1 to 168.203.47.192 may be routed thru MCI NEARNET:WESTNET-MAINT-MCI 18.24.0.1 to 168.204.47.192 may be routed thru MCI NEARNET:WESTNET-MAINT-MCI 18.24.0.1 to 168.205.47.192 may be routed thru MCI NEARNET:WESTNET-MAINT-MCI 18.24.0.1 to 168.208.47.192 may be routed thru MCI NEARNET:MRNET-MAINT-MCI 18.24.0.1 to 168.209.47.192 may be routed thru MCI NEARNET:MRNET-MAINT-MCI 18.24.0.1 to 168.22.50.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 168.25.49.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 168.26.50.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 168.28.50.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 168.31.50.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 168.32.50.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 168.34.50.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 168.44.39.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 171.4.42.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 187.130.44.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 187.138.44.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 187.8.38.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 188.121.42.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 188.126.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 190.252.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 190.74.43.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 194.252.44.192 may be routed thru MCI NEARNET:SURA 18.24.0.1 to 206.25.43.192 may be routed thru MCI NEARNET:MCI 18.24.0.1 to 216.188.38.192 may be routed thru MCI NEARNET:MCI 18.24.0.1 to 217.65.37.192 may be routed thru MCI NEARNET:MCI 18.24.0.1 to 221.3.43.192 may be routed thru MCI NEARNET:MCI 18.24.0.1 to 149.141.38.192 may be routed thru MCI NEARNET:SESQUINET-MAINT-MCI 18.24.0.1 to 157.36.44.192 may be routed thru MCI NEARNET:SESQUINET-MAINT-MCI 192.35.180.20 to 192.52.106.7 may be routed thru MCI NWNET-MAINT-MCI:MAINT-AS194 198.104.204.20 to 198.106.201.2 may be routed thru MCI NWNET-MAINT-MCI:NERO-MAINT-MCI 198.106.201.2 to 198.104.204.20 may be routed thru MCI NERO-MAINT-MCI:NWNET-MAINT-MCI 131.252.20.155 to 198.106.195.3 may be routed thru MCI NWNET-MAINT-MCI:NERO-MAINT-MCI 128.241.0.92 to 192.231.8.130 may be routed thru MCI SESQUINET-MAINT-MCI:SURA 128.241.0.91 to 192.17.2.3 may be routed thru MCI SESQUINET-MAINT-MCI:CICNET-NS 128.241.0.91 to 204.140.133.4 may be routed thru MCI SESQUINET-MAINT-MCI:LN-MAINT-MCI 128.241.0.91 to 198.17.47.39 may be routed thru MCI SESQUINET-MAINT-MCI:LN-MAINT-MCI 128.241.0.91 to 144.34.1.1 may be routed thru MCI SESQUINET-MAINT-MCI:MRNET-MAINT-MCI 128.241.0.91 to 140.148.1.16 may be routed thru MCI SESQUINET-MAINT-MCI:MRNET-MAINT-MCI 128.9.16.4 to 128.241.0.91 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 128.9.16.4 to 192.203.230.242 may be routed thru MCI LN-MAINT-MCI:SURA 204.140.133.2 to 0.6.130.94 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 1.0.6.133 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 1.9.129.95 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 10.80.16.9 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 100.44.133.49 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 11.147.32.237 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 11.192.168.137 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 112.40.140.173 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 112.44.131.243 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 122.254.136.10 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 128.135.255.255 may be routed thru MCI LN-MAINT-MCI:CICNET-NS 204.140.133.2 to 128.41.140.173 may be routed thru MCI LN-MAINT-MCI:CICNET-NS 204.140.133.2 to 128.5.192.221 may be routed thru MCI LN-MAINT-MCI:MERIT-MAINT-MCI 204.140.133.2 to 130.83.253.0 may be routed thru MCI LN-MAINT-MCI:MERIT-MAINT-MCI 204.140.133.2 to 130.94.40.24 may be routed thru MCI LN-MAINT-MCI:JVNCNET 204.140.133.2 to 130.94.48.248 may be routed thru MCI LN-MAINT-MCI:JVNCNET 204.140.133.2 to 132.250.88.160 may be routed thru MCI LN-MAINT-MCI:SURA 204.140.133.2 to 139.100.18.153 may be routed thru MCI LN-MAINT-MCI:SURA 204.140.133.2 to 14.137.39.43 may be routed thru MCI LN-MAINT-MCI:SURA 204.140.133.2 to 144.40.140.173 may be routed thru MCI LN-MAINT-MCI:SURA 204.140.133.2 to 15.112.32.7 may be routed thru MCI LN-MAINT-MCI:BARRNET 204.140.133.2 to 15.16.10.192 may be routed thru MCI LN-MAINT-MCI:BARRNET 204.140.133.2 to 16.40.140.173 may be routed thru MCI LN-MAINT-MCI:BARRNET 204.140.133.2 to 176.48.6.193 may be routed thru MCI LN-MAINT-MCI:BARRNET 204.140.133.2 to 192.122.254.152 may be routed thru MCI LN-MAINT-MCI:BARRNET 204.140.133.2 to 192.188.104.96 may be routed thru MCI LN-MAINT-MCI:SURA 204.140.133.2 to 192.32.47.64 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 192.36.148.192 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 192.9.133.9 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 198.116.75.64 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 2.11.147.32 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 20.45.134.225 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 200.43.131.242 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 202.241.1.64 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 248.130.94.7 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 248.5.130.94 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 250.88.144.9 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 253.8.10.128 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 255.129.95.48 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 255.252.128.43 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 32.135.255.255 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 32.192.32.43 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 32.237.5.11 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 32.40.140.173 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 32.45.128.7 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 4.44.133.49 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 40.0.4.130 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 43.253.44.11 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 44.128.8.192 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 46.248.5.130 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.1CI:NEARNET 204.140.133.2 to 48.8.192.50 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 5.130.94.45 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 5.202.249.9 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 51.240.137.255 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 58.16.7.202 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 62.159.32.11 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 63.3.9.130 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 64.39.133.17 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 64.4.192.32 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 64.40.140.173 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 64.9.132.250 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 7.11.147.32 may be routed thru MCI LN-MAINT-MCI:NEARNET 20AINT-MCI:NEARNET 204.140.133.2 to 7.198.116.75 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 72.42.131.174 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 72.48.140.173 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 72.49.131.174 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 72.7.192.32 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 76.246.16.14 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 8.147.32.237 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 8.41.140.173 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 80.40.140.173 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 83.249.2.14 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 88.128.9.132 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 9.132.250.88 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 9.192.188.104 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 94.40.8.5 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 94.47.248.5 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 96.40.140.173 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 96.6.202.13 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 99.111.141.135 may be routed thru MCI LN-MAINT-MCI:NEARNET 204.140.133.2 to 147.32.237.6 may be routed thru MCI LN-MAINT-MCI:NEARNET 192.231.8.130 to 199.93.0.243 may be routed thru MCI SURA:DELPHI-MAINT-MCI 199.2.252.10 to 144.34.1.1 may be routed thru MCI SURA:MRNET-MAINT-MCI 131.178.38.6 to 148.202.3.222 may be routed thru MCI SURA:SESQUINET-MAINT-MCI 131.178.38.6 to 148.204.103.2 may be routed thru MCI SURA:SESQUINET-MAINT-MCI 146.88.1.103 to 192.52.106.7 may be routed thru MCI SESQUINET-MAINT-MCI:MAINT-AS194 144.34.1.1 to 128.101.24.55 may be routed thru MCI MRNET-MAINT-MCI:CICNET-NS 144.34.1.1 to 134.84.134.120 may be routed thru MCI MRNET-MAINT-MCI:CICNET-NS 144.34.1.1 to 128.101.25.79 may be routed thru MCI MRNET-MAINT-MCI:CICNET-NS 144.34.1.1 to 199.2.252.10 may be routed thru MCI MRNET-MAINT-MCI:CICNET-NS 137.192.2.5 to 199.17.128.2 may be routed thru MCI MRNET-MAINT-MCI:CICNET-NS 128.101.25.79 to 144.34.1.1 may be routed thru MCI CICNET-NS:MRNET-MAINT-MCI 198.207.141.151 to 152.61.192.2 may be routed thru MCI MRNET-MAINT-MCI:MID-MAINT-MCI 134.55.20.198 to 192.5.186.3 may be routed thru MCI MRNET-MAINT-MCI:CICNET-NS 134.55.20.198 to 147.155.32.31 may be routed thru MCI MRNET-MAINT-MCI:MID-MAINT-MCI 134.55.20.198 to 192.5.180.43 may be routed thru MCI MRNET-MAINT-MCI:CICNET-NS 134.55.12.229 to 192.203.230.241 may be routed thru MCI MRNET-MAINT-MCI:SURA 134.55.12.133 to 18.77.1.243 may be routed thru MCI MRNET-MAINT-MCI:NEARNET 134.55.12.133 to 131.225.57.200 may be routed thru MCI MRNET-MAINT-MCI:CICNET-NS 147.155.32.31 to 134.55.20.198 may be routed thru MCI MID-MAINT-MCI:CICNET-NS 131.225.57.200 to 134.55.12.133 may be routed thru MCI CICNET-NS:MID-MAINT-MCI 134.55.13.4 to 129.57.35.32 may be routed thru MCI CICNET-NS:SURA 134.55.13.4 to 143.4 to 144.174.135.12 may be routed thru MCI CICNET-NS:SURA 128.3.112.48 to 204.162.81.11 may be routed thru MCI CICNET-NS:BARRNET 129.57.35.32 to 134.55.13.4 may be routed thru MCI SURA:BARRNET 128.63.2.86 to 129.190.22.134 may be routed thru MCI SURA:NEARNET 129.190.22.134 to 128.63.2.86 may be routed thru MCI NEARNET:SURA 129.164.10.21 to 157.182.44.98 may be routed thru MCI NEARNET:SURA 192.203.230.241 to 137.78.160.8 may be routed thru MCI SURA:LN-MAINT-MCI 192.203.230.241 to 147.6.9.103 may be routed thru MCI SURA:LN-MAINT-MCI 192.203.230.241 to 134.55.12.229 may be routed thru MCI SURA:LN-MAINT-MCI 192.203.230.241 to 128.183.251.129 may be routed thru MCI SURA:LN-MAINT-MCI 192.203.230.241 to 130.134.128.34 may be routed thru MCI SURA:LN-MAINT-MCI 192.203.230.241 to 202.241.2.71 may be routed thru MCI SURA:LN-MAINT-MCI 192.203.230.241 to 198.17.47.39 may be routed thru MCI SURA:LN-MAINT-MCI 192.203.230.241 to 192.31.48.211 may be routed thru MCI SURA:BARRNET 192.203.230.241 to 131.119.244.10 may be rout.21 may be routed thru MCI SURA:PSC-MAINT-MCI 157.182.44.98 to 129.164.10.21 may be routed thru MCI SURA:PSC-MAINT-MCI 137.78.160.8 to 192.203.230.241 may be routed thru MCI LN-MAINT-MCI:SURA 147.6.9.103 to 192.203.230.241 may be routed thru MCI LN-MAINT-MCI:SURA 128.183.10.47 to 139.88.27.222 may be routed thru MCI LN-MAINT-MCI:OARNET-MAINT-MCI 128.183.10.47 to 192.203.230.241 may be routed thru MCI LN-MAINT-MCI:SURA 128.183.10.47 to 146.165.4.24 may be routed thru MCI LN-MAINT-MCI:SURA 202.241.2.71 to 192.203.230.241 may be routed thru MCI LN-MAINT-MCI:SURA 192.203.230.242 to 204.140.133.4 may be routed thru MCI SURA:LN-MAINT-MCI 192.203.230.242 to 198.116.62.5 may be routed thru MCI SURA:LN-MAINT-MCI 192.203.230.242 to 198.106.193.1 may be routed thru MCI SURA:NERO-MAINT-MCI 128.171.3.21 to 132.160.3.28 may be routed thru MCI SURA:AARNET 137.79.116.201 to 137.187.156.20 may be routed thru MCI LN-MAINT-MCI:SURA 143.248.172.41 to 203.255.112.3 may be routed thru MCI LN-MAINT-MCI:INET-MAINT-MCI 128.183.253.55 to 132.250.116.34 may be routed thru MCI OARNET-MAINT-MCI:SURA 129.171.98.59 to 128.183.121.16 may be routed thru MCI SURA:LN-MAINT-MCI 192.107.190.132 to 192.107.194.7 may be routed thru MCI LN-MAINT-MCI:WESTNET-MAINT-MCI 137.39.43.34 to 206.40.72.100 may be routed thru MCI OARNET-MAINT-MCI:MAINT-AS3967 137.39.43.34 to 192.80.214.200 may be routed thru MCI OARNET-MAINT-MCI:SURA 137.39.43.34 to 192.47.242.61 may be routed thru MCI OARNET-MAINT-MCI:SURA 137.39.43.34 to 204.27.65.51 may be routed thru MCI OARNET-MAINT-MCI:MAINT-AS3844 137.39.229.98 to 192.208.45.230 may be routed thru MCI OARNET-MAINT-MCI:NEARNET 137.39.229.98 to 192:MID-MAINT-MCI 144.228.1.40 to 128.138.213.1 may be routed thru MCI OARNET-MAINT-MCI:WESTNET-MAINT-MCI 144.228.1.40 to 128.252.169.30 may be routed thru MCI OARNET-MAINT-MCI:MAINT-CBM10-MCI 206.40.72.100 to 137.39.43.34 may be routed thru MCI MAINT-AS3967:MAINT-CBM10-MCI 206.40.72.100 to 137.39.246.98 may be routed thru MCI MAINT-AS3967:MAINT-CBM10-MCI 192.12.88.3 to 137.39.229.98 may be routed thru MCI JVNCNET:SURA 199.18.96.226 to 128.146.116.8 may be routed thru MCI OARNET-MAINT-MCI:CICNET-NS 199.18.96.226 to 144.228.1.40 may be routed thru MCI OARNET-MAINT-MCI:CICNET-NS 198.17.47.39 to 128.241.0.91 may be routed thru MCI OARNET-MAINT-MCI:SESQUINET-MAINT-MCI 198.17.47.39 to 192.203.230.241 may be routed thru MCI OARNET-MAINT-MCI:SURA 192.5.180.43 to 134.55.20.198 may be routed thru MCI CICNET-NS:SURA 192.35.82.97 to 18.180.0.2 may be routed thru MCI CICNET-NS:NEARNET 192.35.82.97 AINT-MCI 192.52.106.7 to 128.138.213.1 may be routed thru MCI MAINT-AS194:WESTNET-MAINT-MCI 192.52.106.7 to 192.17.2.8 may be routed thru MCI MAINT-AS194:CICNET-NS 192.52.106.7 to 134.129.125.191 may be routed thru MCI MAINT-AS194:MCI 192.52.106.7 to 192.35.180.20 may be routed thru MCI MAINT-AS194:NWNET-MAINT-MCI 192.52.106.7 to 140.197.30.30 may be routed thru MCI MAINT-AS194:NWNET-MAINT-MCI 192.52.106.7 to 141.142.121.32 may be routed thru MCI MAINT-AS194:CICNET-NS 128.138.213.1 to 163.185.68.164 may be routed thru MCI WESTNET-MAINT-MCI:MAINT-OMNES 128.138.213.1 to 192.52.106.7 may be routed thru MCI WESTNET-MAINT-MCI:MAINT-AS194 128.138.213.1 to 192.231.90.15 may be routed thru MCI WESTNET-MAINT-MCI:MAINT-AS194 134.129.125.191 to 192.52.106.7 may be routed thru MCI MCI:MAINT-AS194 141.142.121.32 to 192.52.106.7 may be routed thru MCI CICNET-NS:MAINT-AS194 141.142.121.32 to 128.182.72.28 may be routed thru MCI CICNET-NS:PSC-MAINT-MCI 129.82.152.25 to 128.138.213.1 may be routed thru MCI CICNET-NS:WESTNET-Mru MCI PSC-MAINT-MCI:JVNCNET 192.88.114.10 to 198.108.2.20 may be routed thru MCI PSC-MAINT-MCI:MERIT-MAINT-MCI 192.88.114.10 to 192.203.230.241 may be routed thru MCI PSC-MAINT-MCI:SURA 192.88.114.10 to 198.112.8.2 may be routed thru MCI PSC-MAINT-MCI:NEARNET 130.91.16.46 to 134.82.20.31 may be routed thru MCI JVNCNET:PREPNET-MAINT-MCI 130.91.16.46 to 192.88.114.10 may be routed thru MCI JVNCNET:PSC-MAINT-MCI 130.91.16.46 to 192.251.93.62 may be routed thru MCI JVNCNET:PREPNET-MAINT-MCI 130.91.16.46 to 192.231.162.254 may be routed thru MCI JVNCNET:PREPNET-MAINT-MCI 192.5.102.3 to 192.88.114.10 may be routed thru MCI JVNCNET:PSC-MAINT-MCI 198.106.192.24 to 129.95.20.54 may be routed thru MCI NERO-MAINT-MCI:NWNET-MAINT-MCI 198.106.192.24 to 129.95.20.200 may be routed thru MCI NERO-MAINT-MCI:NWNET-MAINT-MCI 198.106.192.21 to 198.107.238.1 may be routed thru MCI NERO-MAINT-MCI:NWNET-MAINT-MCI 198.106.192.21 to 192.203.230.242 may be routed thru MCI NERO-MAINT-MCI:SURA From list-mgr@ISI.EDU Wed Dec 6 06:14:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04495>; Wed, 6 Dec 1995 14:17:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04422>; Wed, 6 Dec 1995 14:16:32 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA04415>; Wed, 6 Dec 1995 14:16:31 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15020(6)>; Wed, 6 Dec 1995 14:15:32 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 6 Dec 1995 14:15:07 -0800 To: "Jeffrey S. Curtis" <curtis@anl.gov> Cc: mbone Subject: Re: ipmulti-3.5 breaks SunOS multiple le In-Reply-To: Your message of "Wed, 06 Dec 95 11:04:56 PST." <199512061904.NAA27185@achilles.ctd.anl.gov> Date: Wed, 6 Dec 1995 14:14:57 PST Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Dec6.141507pst.177478@crevenia.parc.xerox.com> In message <199512061904.NAA27185@achilles.ctd.anl.gov> you write: >Installing the v3.5 multicasting patches onto a SunOS 4.1.3 or 4.1.4 >machine with more than one le ethernet interface causes all of the le >interfaces except for le0 to not function. I'm afraid I don't see this behavior; PARC's multicast topology is all supplied by multiple-interface sparcstations. We have three machines with three le devices and one with two, all running the 3.5 multicast release just fine. Bill From list-mgr@ISI.EDU Wed Dec 6 11:56:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13381>; Wed, 6 Dec 1995 15:57:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13363>; Wed, 6 Dec 1995 15:56:32 -0800 Received: from achilles.ctd.anl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA13353>; Wed, 6 Dec 1995 15:56:29 -0800 Received: (from curtis@localhost) by achilles.ctd.anl.gov (8.6.11/8.6.11) id RAA12968; Wed, 6 Dec 1995 17:56:27 -0600 Date: Wed, 6 Dec 1995 17:56:27 -0600 Message-Id: <199512062356.RAA12968@achilles.ctd.anl.gov> To: fenner@parc.xerox.com Subject: Re: ipmulti-3.5 breaks SunOS multiple le Cc: mbone From: "Jeffrey S. Curtis" <curtis@anl.gov> Bill Fenner writes: }I'm afraid I don't see this behavior; PARC's multicast topology is all }supplied by multiple-interface sparcstations. We have three machines }with three le devices and one with two, all running the 3.5 multicast }release just fine. I just got done reinstalling 4.1.4 on the SS5 from scratch. I then moved "ip_le.o.patch" to "ip_le.o" in the 4.1.4 OBJ directory of the multicast installation tree and installed ipmulti-3.5 with default answers to the installation questions (non-upgrade, full install, support mrouting, RSVP, etc.). Upon rebooting with the new kernel, I was greeted with the same old "le1: RINT but buffer owned by LANCE" and "le1: TINT but buffer owned by LANCE" errors, and le1 was nonfunctional. I also tried the "ip_le.o.bpf.patch" version (didn't compile, of course, since it's a non-BPF box) as well as the "ip_le.o" unpatched version. All give the same results - errors on the console and a nonfunctional le1 interface. A few people mentioned being able to get this to work on an SS5; could those people please send me the "ls -l" output of their if_le.o module so that I can compare to what I'm trying to install? Any other ideas, anyone? Thanks, Jeff [P.S. I may have overgeneralized in my previous message - the more I think about it, the more I believe that this problem is pretty much restricted to SS5s, although I could've sworn I ran into it on some other platform a year or so ago. It obviously does work on at least some SunOS platforms with multiple le interfaces, though, as I have two such machines running (both IPCs).] -- Jeffrey S. Curtis | Internetwork Manager Argonne National Laboratory | Email: curtis@anl.gov 9700 South Cass Avenue, ECT-221 | Voice: 708/252-1789 Argonne, IL 60439 | Fax: 708/252-9689 From list-mgr@ISI.EDU Wed Dec 6 08:11:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14417>; Wed, 6 Dec 1995 16:10:32 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA14408>; Wed, 6 Dec 1995 16:10:29 -0800 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id QAA10895; Wed, 6 Dec 1995 16:11:51 -0800 Message-Id: <199512070011.QAA10895@rx7.ee.lbl.gov> To: dmeyers@vod.arc.nasa.gov, lamaster@vod.arc.nasa.gov Cc: mbone-na Subject: multicast seriously broken on vod.arc.nasa.gov Date: Wed, 06 Dec 95 16:11:50 PST From: Van Jacobson <van@ee.lbl.gov> Host vod.arc.nasa.gov seems to be broken. It is currently sending vat & wb session packets at around 300 p/s (attached is about 8ms of stuff it's sending to the IETF chan 1 audio session). This is doing bad things to the mbone. Since the ip id is different on all these packets, it looks like a broken host, not a multicast routing loop. I think it would be a good idea to power off or reboot this host. - Van ---------- 16:01:42.026075 vod.arc.nasa.gov.8862 > IETF-1-AUDIO.MCAST.NET.21011: udp 30 (tt l 185, id 38675) 16:01:42.030411 vod.arc.nasa.gov.8856 > IETF-1-AUDIO.MCAST.NET.21011: udp 30 (tt l 185, id 38677) 16:01:42.038391 vod.arc.nasa.gov.8856 > IETF-1-AUDIO.MCAST.NET.21011: udp 30 (tt l 185, id 38679) 16:01:42.045166 vod.arc.nasa.gov.8856 > IETF-1-AUDIO.MCAST.NET.21011: udp 30 (tt l 185, id 38681) 16:01:42.048806 vod.arc.nasa.gov.8856 > IETF-1-AUDIO.MCAST.NET.21011: udp 30 (tt l 185, id 38683) 16:01:42.052538 vod.arc.nasa.gov.8856 > IETF-1-AUDIO.MCAST.NET.21011: udp 30 (tt l 185, id 38685) 16:01:42.057633 dolphin.nosc.mil.1805 > IETF-1-AUDIO.MCAST.NET.21011: udp 35 (tt l 184, id 44073) 16:01:42.064099 vod.arc.nasa.gov.8859 > IETF-1-AUDIO.MCAST.NET.21011: udp 30 (tt l 185, id 38687) 16:01:42.069861 vod.arc.nasa.gov.8859 > IETF-1-AUDIO.MCAST.NET.21011: udp 30 (tt l 185, id 38689) 16:01:42.076686 vod.arc.nasa.gov.8859 > IETF-1-AUDIO.MCAST.NET.21011: udp 30 (tt l 185, id 38691) 16:01:42.080844 vod.arc.nasa.gov.8859 > IETF-1-AUDIO.MCAST.NET.21011: udp 30 (tt l 185, id 38693) 16:01:42.086813 vod.arc.nasa.gov.8859 > IETF-1-AUDIO.MCAST.NET.21011: udp 30 (tt l 185, id 38695) 16:01:42.097997 vod.arc.nasa.gov.8862 > IETF-1-AUDIO.MCAST.NET.21011: udp 30 (tt l 185, id 38697) From list-mgr@ISI.EDU Wed Dec 6 08:26:23 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15606>; Wed, 6 Dec 1995 16:25:01 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA15598>; Wed, 6 Dec 1995 16:24:59 -0800 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id QAA10928; Wed, 6 Dec 1995 16:26:23 -0800 Message-Id: <199512070026.QAA10928@rx7.ee.lbl.gov> To: mbone-na Subject: missouri.edu sending 300kb/s nv video Date: Wed, 06 Dec 95 16:26:23 PST From: Van Jacobson <van@ee.lbl.gov> User c615552@indy62.gclab.missouri.edu is sending 300kb/s nv video to the "WWW Channel 1 Video" session. Presumably this is some student who isn't aware of the mbone usage guidelines. Perhaps someone nearby could tell them this isn't appropriate behavior. Thanks. - Van From list-mgr@ISI.EDU Wed Dec 6 14:15:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28288>; Wed, 6 Dec 1995 22:16:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28159>; Wed, 6 Dec 1995 22:16:16 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA28152>; Wed, 6 Dec 1995 22:16:13 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14434(1)>; Wed, 6 Dec 1995 22:16:06 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 6 Dec 1995 22:15:54 -0800 To: Erik Sherk <sherk@uunet.uu.net> Cc: mbone Subject: Re: What do these messages mean? In-Reply-To: Your message of "Wed, 06 Dec 95 10:28:45 PST." <QQzsyz03531.199512061828@esherk.uu.net> Date: Wed, 6 Dec 1995 22:15:41 PST Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Dec6.221554pst.177478@crevenia.parc.xerox.com> In message <QQzsyz03531.199512061828@esherk.uu.net> you write: > I can't recall what these messages mean. > >an invalid origin (204.94.248.0) and/or mask (fffffe00)" The origin and mask My "checkroutes" script reports: 204.94.112/21 is a CIDR route 204.94.248/23 is a CIDR route 204.119.248/21 is a CIDR route 204.148.104/21 is a CIDR route 204.149.160/21 is a CIDR route 204.182.232/21 is a CIDR route 206.127.224/20 is a CIDR route Your customer is running a pre-3.5 mrouted which cannot handle CIDR routes, and someone is injecting these CIDR routes into the DVMRP routing tables. Bill From list-mgr@ISI.EDU Fri Dec 8 02:29:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02467>; Thu, 7 Dec 1995 00:41:33 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02234>; Thu, 7 Dec 1995 00:34:02 -0800 Received: from sol.nuri.net by venera.isi.edu (5.65c/5.61+local-22) id <AA02227>; Thu, 7 Dec 1995 00:33:57 -0800 Received: from sosaria.inet.co.kr (sosaria.inet.co.kr [203.255.113.40]) by sol.nuri.net (8.6.12H1/8.6.9) with SMTP id RAA21921 for <mbone@ISI.EDU>; Thu, 7 Dec 1995 17:29:09 +0900 Date: Thu, 7 Dec 1995 17:29:09 +0900 Message-Id: <199512070829.RAA21921@sol.nuri.net> X-Sender: sosarian@sol.nuri.net X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: "Kyungsoon 'Sosarian' Park" <sosarian@nuri.net> Subject: Where is mrouted? Where can I find 'mrouted' in sun sparc machine? Thanks. From list-mgr@ISI.EDU Thu Dec 7 16:15:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22952>; Thu, 7 Dec 1995 10:51:23 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22927>; Thu, 7 Dec 1995 10:51:00 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA22915>; Thu, 7 Dec 1995 10:50:50 -0800 Received: from cd1.lrz-muenchen.de by quark.isi.edu (5.65c/5.61+local-20) id <AA19618>; Thu, 7 Dec 1995 10:50:04 -0800 Received: from sunmanager.lrz-muenchen.de by cd1.lrz-muenchen.de; Thu, 7 Dec 95 15:15:52 +0100 Received: by sunmanager.lrz-muenchen.de (4.1/SMI-4.1) id AA02555; Thu, 7 Dec 95 15:15:51 +0100 From: Thomas.Bonk@lrz-muenchen.de (Thomas Bonk) Message-Id: <9512071415.AA02555@sunmanager.lrz-muenchen.de> Subject: configuring snmp-Port of mrouted3.8 To: mbone Date: Thu, 7 Dec 1995 15:15:50 +0100 (MET) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1248 Hi I tried to change the snmp-port of mrouted3.8 by using the Option -P proposed in the README file. But this didn's succeed: mrouted.snmp.rsrr -P 7161 -d 1 yields the output: 14:59:55.591 mrouted version 3.8 Opening port(s): 161 bind: Address already in use Ok. So I tried to compile the appropriate sources using the distribution from ftp.parc.xerox.com (mirrored to www-ks.rus.uni-stuttgart.de). But compilation failed due to missing includefiles: snmp.c: 5: Can't find include file snmplib/asn1.h snmp.c: 6: Can't find include file snmplib/party.h snmp.c: 7: Can't find include file snmplib/snmp_impl.h snmp.c: 9: Can't find include file snmpd/snmp_vars.h Does there exist a complete mrouted3.8-source-version on any ftp-server (preferred in Europe)? Is it possible to fix the bug described above in the next release? Thanks -- ============================================================================= Dr. Thomas Bonk Leibniz Rechenzentrum, Barer Str. 21, D-80333 Muenchen, Germany, Tel: ++49-89-2105-8839, Fax ++49-89-2809460 EMAIL: Thomas.Bonk@lrz-muenchen.de URL: http://www.lrz-muenchen.de/Persons/thomas_bonk_ge.html IRC: Jamesb ============================================================================= From list-mgr@ISI.EDU Fri Dec 8 13:15:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24637>; Thu, 7 Dec 1995 11:15:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24619>; Thu, 7 Dec 1995 11:15:13 -0800 Received: from kidgw.kyushu-id.ac.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA24612>; Thu, 7 Dec 1995 11:15:09 -0800 Received: from cocoa.kyushu-id.ac.jp by kidgw.kyushu-id.ac.jp (8.6.11+2.4W/3.3W9-16Mar94) id EAA25784; Fri, 8 Dec 1995 04:13:57 +0900 Received: (from hori@localhost) by cocoa.kyushu-id.ac.jp (8.6.10+2.4W/3.3W9-KID-COCOA) id EAA25648; Fri, 8 Dec 1995 04:15:18 +0900 Message-Id: <199512071915.EAA25648@cocoa.kyushu-id.ac.jp> To: fenner@parc.xerox.com Cc: curtis@anl.gov, mbone Subject: Re: ipmulti-3.5 breaks SunOS multiple le From: Yoshiaki Hori <hori@kyushu-id.ac.jp> In-Reply-To: Your message of "Wed, 6 Dec 1995 14:14:57 PST" References: <95Dec6.141507pst.177478@crevenia.parc.xerox.com> X-Mailer: Mew version 1.00.4 on Emacs 19.28.1, Mule 2.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 08 Dec 1995 04:15:18 +0900 Sender: hori@cocoa.kyushu-id.ac.jp >Date: Wed, 6 Dec 1995 14:14:57 PST >From: Bill Fenner <fenner@parc.xerox.com> > >In message <199512061904.NAA27185@achilles.ctd.anl.gov> you write: >>Installing the v3.5 multicasting patches onto a SunOS 4.1.3 or 4.1.4 >>machine with more than one le ethernet interface causes all of the le >>interfaces except for le0 to not function. > >I'm afraid I don't see this behavior; PARC's multicast topology is all >supplied by multiple-interface sparcstations. We have three machines >with three le devices and one with two, all running the 3.5 multicast >release just fine. I have ever seen this behavior with SS5 and 4.1.4. I changed the sencond (le1) OLD ethernet card into NEW one. It is no problem with NEW one. OLD is with 10base/2 and 5. NEW is with 10base/T and SCSI2. Jeff, your card is the same as my OLD ? Yoshiaki Hori From list-mgr@ISI.EDU Thu Dec 7 07:31:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25478>; Thu, 7 Dec 1995 11:32:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25456>; Thu, 7 Dec 1995 11:32:19 -0800 Received: from achilles.ctd.anl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA25449>; Thu, 7 Dec 1995 11:32:18 -0800 Received: (from curtis@localhost) by achilles.ctd.anl.gov (8.6.11/8.6.11) id NAA13696; Thu, 7 Dec 1995 13:31:48 -0600 Date: Thu, 7 Dec 1995 13:31:48 -0600 Message-Id: <199512071931.NAA13696@achilles.ctd.anl.gov> To: hori@kyushu-id.ac.jp Subject: Re: ipmulti-3.5 breaks SunOS multiple le Cc: mbone From: "Jeffrey S. Curtis" <curtis@anl.gov> Yoshiaki Hori writes: }I have seen this behavior with SS5 and 4.1.4. I changed }the second (le1) OLD ethernet card into NEW one. It is no }problem with NEW one. }OLD is with 10base/2 and 5. NEW is with 10base/T and SCSI2. }Jeff, your card is the same as my OLD ? Yes! My le1 is the AUI/thinnet variety, as you described. Thanks for the explanation! I was at a loss; I had just loaded a kernel provided by a member of this list from their SS5 with multiple le interfaces - works for them, didn't work for me - I didn't understand how that could be until I read your message. Thank you! Jeff -- Jeffrey S. Curtis | Internetwork Manager Argonne National Laboratory | Email: curtis@anl.gov 9700 South Cass Avenue, ECT-221 | Voice: 708/252-1789 Argonne, IL 60439 | Fax: 708/252-9689 From list-mgr@ISI.EDU Thu Dec 7 04:00:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27189>; Thu, 7 Dec 1995 12:02:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27116>; Thu, 7 Dec 1995 12:00:34 -0800 Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA27108>; Thu, 7 Dec 1995 12:00:32 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.8+c/8.6.5) id MAA22367; Thu, 7 Dec 1995 12:00:31 -0800 Date: Thu, 7 Dec 1995 12:00:31 -0800 From: Dino Farinacci <dino@cisco.com> Message-Id: <199512072000.MAA22367@stilton.cisco.com> To: mbone Subject: Default route warning alert We found a bug last week where DVMRP default routes are being propagated with a metric of 1 rather than with the routing table metric. This problem has been fixed in 10.2(10.3), 10.3(7.6), 11.0(3.4), and 11.1(0.9). However, there is no problem originating DVMRP default routes. A workaround is to create an access-list entry to not advertise 0.0.0.0/0 on each of your tunnels. You achieve this by doing: access-list 1 permit 0.0.0.0 0.0.0.0 interface tunnel0 ip dvmrp metric 0 list 1 If you have any questions, send them to multicast-support@cisco.com. Dino From list-mgr@ISI.EDU Thu Dec 7 09:35:34 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02999>; Thu, 7 Dec 1995 13:35:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02985>; Thu, 7 Dec 1995 13:35:36 -0800 Received: from achilles.ctd.anl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA02978>; Thu, 7 Dec 1995 13:35:34 -0800 Received: (from curtis@localhost) by achilles.ctd.anl.gov (8.6.11/8.6.11) id PAA05307 for mbone@isi.edu; Thu, 7 Dec 1995 15:35:34 -0600 Date: Thu, 7 Dec 1995 15:35:34 -0600 Message-Id: <199512072135.PAA05307@achilles.ctd.anl.gov> To: mbone Subject: Re: ipmulti-3.5 breaks SunOS multiple le From: "Jeffrey S. Curtis" <curtis@anl.gov> }I have ever seen this behavior with SS5 and 4.1.4. I changed }the sencond (le1) OLD ethernet card into NEW one. It is no }problem with NEW one. } }OLD is with 10base/2 and 5. NEW is with 10base/T and SCSI2. } }Jeff, your card is the same as my OLD ? Incidentally, I have now confirmed what is written above. I managed to scrounge up the "new" style le interface with the SCSI board, inserted it into the machine under test, and the ipmulti kernel patches work with no problems whatsoever. So, the moral of the story is: SPARC 5 + ipmulti patches + old style sbus ethernets = failure Thanks to everyone who assisted in tracking this problem down. I appreciate the help. Jeff -- Jeffrey S. Curtis | Internetwork Manager Argonne National Laboratory | Email: curtis@anl.gov 9700 South Cass Avenue, ECT-221 | Voice: 708/252-1789 Argonne, IL 60439 | Fax: 708/252-9689 From list-mgr@ISI.EDU Thu Dec 7 05:49:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03793>; Thu, 7 Dec 1995 13:52:16 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03723>; Thu, 7 Dec 1995 13:50:08 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA03714>; Thu, 7 Dec 1995 13:50:07 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14645(4)>; Thu, 7 Dec 1995 13:49:53 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Thu, 7 Dec 1995 13:49:28 -0800 To: "Kyungsoon 'Sosarian' Park" <sosarian@nuri.net> Cc: mbone Subject: Re: Where is mrouted? In-Reply-To: Your message of "Thu, 07 Dec 95 00:29:09 PST." <199512070829.RAA21921@sol.nuri.net> Date: Thu, 7 Dec 1995 13:49:15 PST Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Dec7.134928pst.177478@crevenia.parc.xerox.com> In message <199512070829.RAA21921@sol.nuri.net> you write: >Where can I find 'mrouted' in sun sparc machine? If you don't have a 3.5 multicast kernel on your machine, you want that first. You don't mention whether you are running SunOS or Solaris, but: SunOS 4.1.x: mrouted: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.8-sparc-sunos41x.tar.Z kernel: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/ipmulti3.5-sunos41x.tar.Z Solaris 2.4: mrouted: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mrouted3.8-sparc-solaris2.tar.Z kernel: ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/Solaris/Solaris_mc35.tar.Z Bill From list-mgr@ISI.EDU Thu Dec 7 06:09:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04732>; Thu, 7 Dec 1995 14:10:08 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04713>; Thu, 7 Dec 1995 14:09:48 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA04703>; Thu, 7 Dec 1995 14:09:46 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15277(7)>; Thu, 7 Dec 1995 14:09:34 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Thu, 7 Dec 1995 14:09:29 -0800 To: Dino Farinacci <dino@cisco.com> Cc: mbone Subject: Re: Default route warning alert In-Reply-To: Your message of "Thu, 07 Dec 95 12:00:31 PST." <199512072000.MAA22367@stilton.cisco.com> Date: Thu, 7 Dec 1995 14:09:14 PST Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Dec7.140929pst.177478@crevenia.parc.xerox.com> In message <199512072000.MAA22367@stilton.cisco.com> Dino wrote: > We found a bug last week where DVMRP default routes are being propagated > with a metric of 1 rather than with the routing table metric. Since the implications of this behavior are not necessarily obvious to non-routing people, I feel that I should point out that this behavior will cause the default route to be regenerated by any router that is in the middle of a topology loop. Since the presence of a default route causes various different problems for mrouted's 3.5 and below, it would be best to get rid of it as soon as possible. Therefore, I strongly encourage everyone to upgrade as soon as they can. If you can't upgrade, please note that the access-list example in Dino's message was slightly incorrect; the proper command to filter out default DVMRP routes is: access-list 1 permit 0.0.0.0 0.0.0.0 interface tunnel0 ip dvmrp metric 0 list 1 dvmrp (the difference is the addition of the 'dvmrp' keyword at the end of the last line.) This command only needs to be added to interfaces pointing towards the MBONE; if you route on default inside your stub network you still want to be able to pass the route on. The default route itself shouldn't cause any problems, since no sources should actually match it, but if it passes through a 3.5 it can re-create the bogus routes that can destabilize routing. Bill From list-mgr@ISI.EDU Thu Dec 7 07:27:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08218>; Thu, 7 Dec 1995 15:26:34 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08208>; Thu, 7 Dec 1995 15:26:14 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA08201>; Thu, 7 Dec 1995 15:26:13 -0800 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id PAA12620; Thu, 7 Dec 1995 15:27:37 -0800 Message-Id: <199512072327.PAA12620@rx7.ee.lbl.gov> To: mbone Cc: dmeyers@vod.arc.nasa.gov, lamaster@george.arc.nasa.gov Subject: host hstf-dr1.home.interop.net trashing NASA Galileo broadcast Date: Thu, 07 Dec 95 15:27:36 PST From: Van Jacobson <van@ee.lbl.gov> Host hstf-dr1.home.interop.net (199.45.6.10) is sending ICMP Unreachables in response to multicast datagrams and this is currently causing 40-50% loss rates on the Galileo Jupiter Orbit Insertion broadcast. This is probably some IBM AIX machine - or a Vines server (both are known to exhibit this behavior if placed on an ethernet with multicast traffic.) It would be nice if this host could be shut off or moved to a subnet not connected to the Mbone. To work around the problem, the NASA people might consider switching to vic in nv mode (i.e., replace "nv" in .sd.tcl with "vic -Anv"). Vic is a completely compatible replacement for nv but it will ignore the ICMP unreachables rather than letting them cause packet loss. - Van From list-mgr@ISI.EDU Thu Dec 7 07:37:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08698>; Thu, 7 Dec 1995 15:38:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08687>; Thu, 7 Dec 1995 15:37:45 -0800 Received: from puli.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA08680>; Thu, 7 Dec 1995 15:37:44 -0800 Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with ESMTP id PAA01298 for <mbone@ISI.EDU>; Thu, 7 Dec 1995 15:37:43 -0800 Message-Id: <199512072337.PAA01298@puli.cisco.com> To: mbone Subject: Nasa video? Date: Thu, 07 Dec 1995 15:37:42 -0800 From: "John M. Zwiebel" <jzwiebel@cisco.com> I'm getting the audio for the Jupiter probe but no video. Anyone else having better luck? I note that the audio is coming from 128.102.192.19 rather than what sd is advertising. Thanks z From list-mgr@ISI.EDU Thu Dec 7 09:16:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15203>; Thu, 7 Dec 1995 17:15:51 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15168>; Thu, 7 Dec 1995 17:15:21 -0800 Received: from rx7.ee.lbl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA15160>; Thu, 7 Dec 1995 17:15:19 -0800 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id RAA12840; Thu, 7 Dec 1995 17:16:39 -0800 Message-Id: <199512080116.RAA12840@rx7.ee.lbl.gov> To: "John M. Zwiebel" <jzwiebel@cisco.com> Cc: mbone Subject: Re: Nasa video? In-Reply-To: Your message of Thu, 07 Dec 95 15:37:42 PST. Date: Thu, 07 Dec 95 17:16:38 PST From: Van Jacobson <van@ee.lbl.gov> The video is showing up here but is being trashed by ICMP Unreachables from an InterOp host (hstf-dr1.home.interop.net, 199.45.6.10). Since I know how often Dino vanishes from our PIM design meetings because of cisco PIM pruning bugs, I'm not surprised to hear they happen to others in cisco. You might be able to find what did the spurious prune with mtrace 128.102.192.19 224.2.223.82 but BBN/Barrnet has so little mtrace support deployed that you're probably SOL. - Van From list-mgr@ISI.EDU Thu Dec 7 15:24:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15702>; Thu, 7 Dec 1995 17:26:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15664>; Thu, 7 Dec 1995 17:24:37 -0800 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA15657>; Thu, 7 Dec 1995 17:24:36 -0800 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.7.2/8.7.2) id UAA28844; Thu, 7 Dec 1995 20:24:36 -0500 (EST) From: Dave Thaler <thalerd@eecs.umich.edu> Message-Id: <199512080124.UAA28844@dip.eecs.umich.edu> Subject: Re: configuring snmp-Port of mrouted3.8 To: Thomas.Bonk@lrz-muenchen.de (Thomas Bonk) Date: Thu, 7 Dec 1995 20:24:35 -0500 (EST) Cc: mbone In-Reply-To: <9512071415.AA02555@sunmanager.lrz-muenchen.de> from "Thomas Bonk" at Dec 7, 95 03:15:50 pm X-Mailer: ELM [version 2.4 PL24 PGP1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I tried to change the snmp-port of mrouted3.8 by using the Option > -P proposed in the README file. But this didn's succeed: This is a known bug which was fixed in the "3.8.1" SNMP-release, which will be early next week. > Ok. So I tried to compile the appropriate sources using the distribution > from ftp.parc.xerox.com (mirrored to www-ks.rus.uni-stuttgart.de). > But compilation failed due to missing includefiles: > > snmp.c: 5: Can't find include file snmplib/asn1.h > snmp.c: 6: Can't find include file snmplib/party.h > snmp.c: 7: Can't find include file snmplib/snmp_impl.h > snmp.c: 9: Can't find include file snmpd/snmp_vars.h That distribution didn't include the snmplib and snmpd source directories (as you noticed :). For SNMP support of the as-is 3.8 distribution, these directories are unchanged from the 3.6.2 SNMP-distribution. However, I'd advise you to wait until Monday or so for the 3.8.1 SNMP release if you can. > Is it possible to fix the bug described above in the next release? Already done. Dave Thaler From list-mgr@ISI.EDU Thu Dec 7 16:31:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18247>; Thu, 7 Dec 1995 18:33:16 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18215>; Thu, 7 Dec 1995 18:31:32 -0800 Received: from bbnplanet.com (poblano.near.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA18208>; Thu, 7 Dec 1995 18:31:30 -0800 Subject: Re: Nasa video? To: Van Jacobson <van@ee.lbl.gov> Date: Thu, 7 Dec 1995 21:31:25 -0500 (EST) From: John Hawkinson <jhawk@bbnplanet.com> Cc: jzwiebel@cisco.com, mbone In-Reply-To: <199512080116.RAA12840@rx7.ee.lbl.gov> from "Van Jacobson" at Dec 7, 95 05:16:38 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1550 Message-Id: <9512072131.aa22855@poblano.bbnplanet.com> > Since I know how often Dino vanishes from our PIM design > meetings because of cisco PIM pruning bugs, I'm not surprised > to hear they happen to others in cisco. You might be able > to find what did the spurious prune with > mtrace 128.102.192.19 224.2.223.82 Said mtrace is attached. > but BBN/Barrnet has so little mtrace support deployed that you're > probably SOL. We apologize, and are working on it. One major sticking point (utumno.barrnet.net) that was long a 3.4 mrouted is now a 3.8, and seems to no longer exhibit mtrace weirdness. --jhawk John Hawkinson Mtrace from 128.102.192.19 to 192.31.48.211 via group 224.2.223.82 From source (nren-vod.arc.nasa.gov) to destination (morgul.barrnet.net) Querying full reverse path... 0 morgul.barrnet.net (192.31.48.211) -1 morgul.barrnet.net (192.31.48.211) DVMRP thresh^ 0 0 ms -2 dec3800-2-fddi-1.SanFrancisco.mci.net (204.70.158.77) DVMRP thresh^ 32 -18631 ms -3 dec3800-1-fddi-0.LosAngeles.mci.net (204.70.170.29) DVMRP thresh^ 1 42372 ms -4 dec3800-1-fddi-0.Dallas.mci.net (204.70.114.29) DVMRP thresh^ 1 -138999 ms -5 VINEGAR.SESQUI.NET (128.241.0.91) DVMRP thresh^ 32 7270 ms -6 mbone.sdsc.edu (198.17.47.39) DVMRP thresh^ 64 7294 ms -7 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 64 6954 ms -8 mbone2.nsi.nasa.gov (192.203.230.242) DVMRP thresh^ 1 6493 ms -9 arcbone.arc.nasa.gov (128.102.84.150) DVMRP thresh^ 32 179116 ms Next router no mtrace -10 vod.arc.nasa.gov (128.102.192.17) [version mrouted 2.2] didn't respond From list-mgr@ISI.EDU Thu Dec 7 12:17:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02375>; Thu, 7 Dec 1995 20:19:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02362>; Thu, 7 Dec 1995 20:18:05 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA02355>; Thu, 7 Dec 1995 20:18:03 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id UAA05766; Thu, 7 Dec 1995 20:17:49 -0800 Message-Id: <199512080417.UAA05766@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Van Jacobson <van@ee.lbl.gov> Cc: mbone, dmeyers@vod.arc.nasa.gov, lamaster@george.arc.nasa.gov Subject: Re: host hstf-dr1.home.interop.net trashing NASA Galileo broadcast In-Reply-To: Your message of "Thu, 07 Dec 1995 15:27:36 PST." <199512072327.PAA12620@rx7.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Dec 1995 20:17:48 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> >>> Van Jacobson said: > To work around the problem, the NASA people might consider > switching to vic in nv mode (i.e., replace "nv" in .sd.tcl > with "vic -Anv"). Vic is a completely compatible replacement > for nv but it will ignore the ICMP unreachables rather than > letting them cause packet loss. Hi, It would be nice and kind if the NASA folks switched the transmission from nv to vic / h.261 .... Tnks, Amancio From list-mgr@ISI.EDU Mon Dec 11 06:26:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01749>; Mon, 11 Dec 1995 14:24:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01722>; Mon, 11 Dec 1995 14:24:14 -0800 Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA01713>; Mon, 11 Dec 1995 14:24:12 -0800 Date: Mon, 11 Dec 1995 14:26:28 -0800 From: braden@ISI.EDU Posted-Date: Mon, 11 Dec 1995 14:26:28 -0800 Message-Id: <199512112226.AA05169@can.isi.edu> Received: by can.isi.edu (5.65c/4.0.3-4) id <AA05169>; Mon, 11 Dec 1995 14:26:28 -0800 To: mbone Subject: What I wish I had said at the time... Cc: braden At the MBone Engineering BOF at IETF, the Sprint representative characterized the MBone as a "toy". As I remember well, ten years ago the carriers were dismissing the Internet itself as a toy. There seems to be some congenital failure of vision here. Bob Braden From list-mgr@ISI.EDU Tue Dec 12 04:45:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20034>; Mon, 11 Dec 1995 16:46:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19990>; Mon, 11 Dec 1995 16:45:25 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA19983>; Mon, 11 Dec 1995 16:45:22 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id CAA16107; Tue, 12 Dec 1995 02:45:19 +0200 Date: Tue, 12 Dec 1995 02:45:19 +0200 Message-Id: <199512120045.CAA16107@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: braden Cc: mbone Subject: What I wish I had said at the time... In-Reply-To: <199512112226.AA05169@can.isi.edu> References: <199512112226.AA05169@can.isi.edu> braden@isi.edu writes: > > At the MBone Engineering BOF at IETF, the Sprint representative > characterized the MBone as a "toy". > > As I remember well, ten years ago the carriers were dismissing > the Internet itself as a toy. There seems to be some congenital > failure of vision here. > At the very same time the big ISPs are just getting into the IP Multicast deployment as a "service", at least within their backbone, their backbone is being flooded by a horde of unicast-replication-based techniques, such as CUseeME, StreamWorks (which does support also IP multicast) that are mostly used on listening to/viewing live content. This gives impressive traffic growth patterns though. What really should be happen that the MBone should be usable by content provider X for a "reasonable use" Y. It's up to us (of whom I think many were at the MBone BOF) to define the Y. The Y has unfortunately been "500kbps max at any given time with nothing running 24/7". I would see that more real content coming online and the "bandwidth of MBone" going up to, say, 2Mbps would actually do the Internet as a whole a great service because the MBone is traversing, usually multiple times, the exactly same infrastructure the Internet is. At least enabling the choice of getting the data via efficient transport should be a goal in the immediate future. Pete From list-mgr@ISI.EDU Mon Dec 11 14:57:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20539>; Mon, 11 Dec 1995 16:59:10 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20502>; Mon, 11 Dec 1995 16:58:03 -0800 Received: from nic.hq.cic.net by venera.isi.edu (5.65c/5.61+local-22) id <AA20495>; Mon, 11 Dec 1995 16:58:01 -0800 Received: (from dorian@localhost) by nic.hq.cic.net (8.7.3/8.6.12) id TAA06528; Mon, 11 Dec 1995 19:57:56 -0500 (EST) Date: Mon, 11 Dec 1995 19:57:56 -0500 (EST) From: Dorian Kim <dorian@CIC.Net> X-Sender: dorian@nic.hq.cic.net To: braden Cc: mbone Subject: Re: What I wish I had said at the time... In-Reply-To: <199512112226.AA05169@can.isi.edu> Message-Id: <Pine.OSF.3.91.951211195337.26970S-100000@nic.hq.cic.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Dec 1995 braden@ISI.EDU wrote: > > At the MBone Engineering BOF at IETF, the Sprint representative > characterized the MBone as a "toy". > > As I remember well, ten years ago the carriers were dismissing > the Internet itself as a toy. There seems to be some congenital > failure of vision here. I disagree. The current state of mbone is indeed little more than a "toy". A toy with a great deal of potential, just like Internet was ten years ago, but a toy nonetheless. There are many issues to be resolved before mbone can step into the limelight the way Internet has done over the last year or so, and mbone BOF pointed out those issues. -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From list-mgr@ISI.EDU Tue Dec 12 17:25:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21769>; Mon, 11 Dec 1995 17:25:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21750>; Mon, 11 Dec 1995 17:25:17 -0800 Received: from mimos.my by venera.isi.edu (5.65c/5.61+local-22) id <AA21743>; Mon, 11 Dec 1995 17:25:13 -0800 Received: from ms.mimos.my (ms.mimos.my [192.228.129.33]) by mimos.my (8.7.1/8.7.1) with SMTP id JAA17374 for <mbone@ISI.EDU>; Tue, 12 Dec 1995 09:25:11 +0800 (MYT) Received: by ms.mimos.my (5.64/7.0) id AA26114; Tue, 12 Dec 95 09:25:10 +0800 Date: Tue, 12 Dec 1995 09:25:09 +0800 From: Norsuzana Harun <ana@ms.mimos.my> To: mbone Message-Id: <Pine.CVX.3.91.951212092447.23558B-100000@ms.mimos.my> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe me From list-mgr@ISI.EDU Mon Dec 11 15:30:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25860>; Mon, 11 Dec 1995 19:32:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25815>; Mon, 11 Dec 1995 19:31:07 -0800 Received: from sgi20.phlab.missouri.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA25808>; Mon, 11 Dec 1995 19:31:03 -0800 Received: (from ccshag@localhost) by sgi20.phlab.missouri.edu (8.7.1/8.7.1) id VAA23130; Mon, 11 Dec 1995 21:30:43 -0600 (CST) Date: Mon, 11 Dec 1995 21:30:43 -0600 (CST) From: "Paul 'Shag' Walmsley" <ccshag@cclabs.missouri.edu> X-Sender: ccshag@sgi20.phlab.missouri.edu To: Dorian Kim <dorian@CIC.Net> Cc: braden, mbone Subject: Re: What I wish I had said at the time... In-Reply-To: <Pine.OSF.3.91.951211195337.26970S-100000@nic.hq.cic.net> Message-Id: <Pine.SGI.3.91.951211212036.23037D-100000@sgi20.phlab.missouri.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Dec 1995, Dorian Kim wrote: > On Mon, 11 Dec 1995 braden@ISI.EDU wrote: > > > > > At the MBone Engineering BOF at IETF, the Sprint representative > > characterized the MBone as a "toy". > > > > As I remember well, ten years ago the carriers were dismissing > > the Internet itself as a toy. There seems to be some congenital > > failure of vision here. > > I disagree. The current state of mbone is indeed little more than a > "toy". A toy with a great deal of potential, just like Internet was ten > years ago, but a toy nonetheless. There are many issues to be resolved > before mbone can step into the limelight the way Internet has done over > the last year or so, and mbone BOF pointed out those issues. An immature technology is one thing; a "toy" is another. One must learn to crawl before one can walk - how else could a system as complex as multicast be developed? Certainly, multicast right now has some serious problems -- problems that are being addressed. Many of the technologies in today's Internet are also in this situation. To me, claiming that the MBONE is a toy is like claiming that IPv4 is a toy. - Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu> "Praise and blame alike mean nothing." -- Virginia Woolf From list-mgr@ISI.EDU Mon Dec 11 18:01:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26908>; Mon, 11 Dec 1995 20:04:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26854>; Mon, 11 Dec 1995 20:02:27 -0800 Received: from foghorn.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA26847>; Mon, 11 Dec 1995 20:02:26 -0800 Received: from localhost (young@localhost) by foghorn.reston.mci.net (8.6.12/8.6.9) with SMTP id XAA02777; Mon, 11 Dec 1995 23:01:54 -0500 Message-Id: <199512120401.XAA02777@foghorn.reston.mci.net> X-Authentication-Warning: foghorn.reston.mci.net: young owned process doing -bs X-Authentication-Warning: foghorn.reston.mci.net: Host localhost didn't use HELO protocol To: Dorian Kim <dorian@cic.net> Cc: braden, mbone Subject: Re: What I wish I had said at the time... In-Reply-To: Your message of "Mon, 11 Dec 1995 19:57:56 EST." <Pine.OSF.3.91.951211195337.26970S-100000@nic.hq.cic.net> Date: Mon, 11 Dec 1995 23:01:54 -0500 From: "Jeff Young" <young@mci.net> i suppose it depends on the definition of "toy" toy as plaything that will never be anything more? or toy as proving ground for further application? in some ways right now it may be a toy, the quality of the video isn't impressive which leads some to believe that the technology will never fly. as we all know the technology (save 200:1 compression) isn`t the gating factor here - the bandwidth is. i did, however sneak into a pim mcast session before the ietf where the idmr architects were discussing the latest and greatest. just audio and whiteboard. in the right hands, this technology is not a toy. it's damn useful. there is more to life that broadcast quality video :-). and perhaps someday we'll have that as well. Jeff Young young@mci.net > Date: Mon, 11 Dec 1995 19:57:56 -0500 (EST) > From: Dorian Kim <dorian@CIC.Net> > To: braden@ISI.EDU > Cc: mbone@ISI.EDU > Subject: Re: What I wish I had said at the time... > > On Mon, 11 Dec 1995 braden@ISI.EDU wrote: > > > > > At the MBone Engineering BOF at IETF, the Sprint representative > > characterized the MBone as a "toy". > > > > As I remember well, ten years ago the carriers were dismissing > > the Internet itself as a toy. There seems to be some congenital > > failure of vision here. > > I disagree. The current state of mbone is indeed little more than a > "toy". A toy with a great deal of potential, just like Internet was ten > years ago, but a toy nonetheless. There are many issues to be resolved > before mbone can step into the limelight the way Internet has done over > the last year or so, and mbone BOF pointed out those issues. > > -dorian > ______________________________________________________________________________ > Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive > Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 > CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian > From list-mgr@ISI.EDU Mon Dec 11 18:42:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28028>; Mon, 11 Dec 1995 20:44:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27953>; Mon, 11 Dec 1995 20:42:41 -0800 Received: from nic.hq.cic.net by venera.isi.edu (5.65c/5.61+local-22) id <AA27946>; Mon, 11 Dec 1995 20:42:39 -0800 Received: (from dorian@localhost) by nic.hq.cic.net (8.7.3/8.6.12) id XAA07729; Mon, 11 Dec 1995 23:42:35 -0500 (EST) Date: Mon, 11 Dec 1995 23:42:35 -0500 (EST) From: Dorian Kim <dorian@CIC.Net> X-Sender: dorian@nic.hq.cic.net To: "Paul 'Shag' Walmsley" <ccshag@cclabs.missouri.edu> Cc: braden, mbone Subject: Re: What I wish I had said at the time... In-Reply-To: <Pine.SGI.3.91.951211212036.23037D-100000@sgi20.phlab.missouri.edu> Message-Id: <Pine.OSF.3.91.951211233648.7525E-100000@nic.hq.cic.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Dec 1995, Paul 'Shag' Walmsley wrote: > On Mon, 11 Dec 1995, Dorian Kim wrote: > > I disagree. The current state of mbone is indeed little more than a > > "toy". A toy with a great deal of potential, just like Internet was ten > > years ago, but a toy nonetheless. There are many issues to be resolved > > before mbone can step into the limelight the way Internet has done over > > the last year or so, and mbone BOF pointed out those issues. > > An immature technology is one thing; a "toy" is another. One must learn > to crawl before one can walk - how else could a system as complex as > multicast be developed? > > Certainly, multicast right now has some serious problems -- problems that > are being addressed. Many of the technologies in today's Internet are > also in this situation. To me, claiming that the MBONE is a toy is like > claiming that IPv4 is a toy. Like Jeff Young pointed out, this depends on what you mean by a toy. I certainly would call any non production quality technology a toy, but this isn't in any reflection of the future potential of that technology. Mbone right now isn't mature yet. It'll, I think become more than just a toy in the next year or two, but we are not there yet. And yes, I'd have called IP a toy ten years ago. Maybe a better word to use would be experimental. When mbone is mature enough for me to be able to deploy on my unicast routing infrastructure, and make it generally available, I'll start calling it a production level technology. I'd very much like to see that happen, and happen soon. However, we are not there yet. It seems to me that this is veering off mbone and into semantics. As an English major, I'd love to take this off mbone and continue to argue, but.. :) -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From list-mgr@ISI.EDU Mon Dec 11 21:06:26 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28875>; Mon, 11 Dec 1995 21:11:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28634>; Mon, 11 Dec 1995 21:06:30 -0800 Received: from Bulldog.Stupi.SE (Relay.Stupi.SE) by venera.isi.edu (5.65c/5.61+local-22) id <AA28625>; Mon, 11 Dec 1995 21:06:26 -0800 Received: from junk.stupi.se(192.108.198.200) by Bulldog.Stupi.SE id sma021771; Tue Dec 12 06:06:16 1995 Date: Tue, 12 Dec 95 6:05:59 MET From: Peter Lothberg <roll@Stupi.SE> To: "Paul 'Shag' Walmsley" <ccshag@cclabs.missouri.edu> Cc: Dorian Kim <dorian@CIC.Net>, braden, mbone Subject: Re: What I wish I had said at the time... In-Reply-To: Your message of Mon, 11 Dec 1995 21:30:43 -0600 (CST) Message-Id: <CMM.0.90.0.818744776.roll@Junk.Stupi.SE> > On Mon, 11 Dec 1995, Dorian Kim wrote: > > > On Mon, 11 Dec 1995 braden@ISI.EDU wrote: > > > > > > > > At the MBone Engineering BOF at IETF, the Sprint representative > > > characterized the MBone as a "toy". > > > > > > As I remember well, ten years ago the carriers were dismissing > > > the Internet itself as a toy. There seems to be some congenital > > > failure of vision here. > > > > I disagree. The current state of mbone is indeed little more than a > > "toy". A toy with a great deal of potential, just like Internet was ten > > years ago, but a toy nonetheless. There are many issues to be resolved > > before mbone can step into the limelight the way Internet has done over > > the last year or so, and mbone BOF pointed out those issues. > > An immature technology is one thing; a "toy" is another. One must learn > to crawl before one can walk - how else could a system as complex as > multicast be developed? > > Certainly, multicast right now has some serious problems -- problems that > are being addressed. Many of the technologies in today's Internet are > also in this situation. To me, claiming that the MBONE is a toy is like > claiming that IPv4 is a toy. > > > - Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu> > "Praise and blame alike mean nothing." -- Virginia Woolf I'm pretty sure that someone misunderstod Sean at the bof. I knew for fact that a lot of people inside Sprint provided key assistance in order for us to get the Mbone router inside ICMnet at the NY-NAP up and running in time for the IETF. (eg friday dec-1) Other operators like MCI and Alternet also helped out to get tunnels configured etc, so saying that the operators doe not care in is not entirely fair. --Peter From list-mgr@ISI.EDU Tue Dec 12 09:57:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00634>; Mon, 11 Dec 1995 22:01:46 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00442>; Mon, 11 Dec 1995 21:58:01 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA00435>; Mon, 11 Dec 1995 21:57:58 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id HAA16711; Tue, 12 Dec 1995 07:57:52 +0200 Date: Tue, 12 Dec 1995 07:57:52 +0200 Message-Id: <199512120557.HAA16711@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Dorian Kim <dorian@CIC.Net> Cc: mbone Subject: Re: What I wish I had said at the time... In-Reply-To: <Pine.OSF.3.91.951211233648.7525E-100000@nic.hq.cic.net> References: <Pine.SGI.3.91.951211212036.23037D-100000@sgi20.phlab.missouri.edu> <Pine.OSF.3.91.951211233648.7525E-100000@nic.hq.cic.net> Dorian Kim writes: > On Mon, 11 Dec 1995, Paul 'Shag' Walmsley wrote: > > Maybe a better word to use would be experimental. When mbone is mature > enough for me to be able to deploy on my unicast routing infrastructure, > and make it generally available, I'll start calling it a production level > technology. > Why don't you do that today? The technology is there, unfortunately you have to carry two routing tables for "full interoperability". If you don't allow DVMRP on your leafs, your current routing protocol(s) will suffice. > I'd very much like to see that happen, and happen soon. However, we are > not there yet. > Please elaborate little more. Pete From list-mgr@ISI.EDU Mon Dec 11 20:10:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00980>; Mon, 11 Dec 1995 22:12:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00964>; Mon, 11 Dec 1995 22:11:01 -0800 Received: from nic.hq.cic.net by venera.isi.edu (5.65c/5.61+local-22) id <AA00956>; Mon, 11 Dec 1995 22:10:59 -0800 Received: (from dorian@localhost) by nic.hq.cic.net (8.7.3/8.6.12) id BAA08551; Tue, 12 Dec 1995 01:10:54 -0500 (EST) Date: Tue, 12 Dec 1995 01:10:54 -0500 (EST) From: Dorian Kim <dorian@CIC.Net> X-Sender: dorian@nic.hq.cic.net To: Petri Helenius <pete@sms.fi> Cc: mbone Subject: Re: What I wish I had said at the time... In-Reply-To: <199512120557.HAA16711@silver.sms.fi> Message-Id: <Pine.OSF.3.91.951212010748.8540A-100000@nic.hq.cic.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 12 Dec 1995, Petri Helenius wrote: > Dorian Kim writes: > Why don't you do that today? The technology is there, unfortunately you > have to carry two routing tables for "full interoperability". If you > don't allow DVMRP on your leafs, your current routing protocol(s) will > suffice. What would have happened if I ran mbone native on my router couple of weeks ago? Will mbone snafu not effect my unicast infrastructure? When I can be assured of that, I'll retire my mrouters. -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From list-mgr@ISI.EDU Mon Dec 11 14:26:00 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01363>; Mon, 11 Dec 1995 22:29:12 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01319>; Mon, 11 Dec 1995 22:26:17 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA01312>; Mon, 11 Dec 1995 22:26:15 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id WAA06053; Mon, 11 Dec 1995 22:26:00 -0800 Message-Id: <199512120626.WAA06053@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Dorian Kim <dorian@CIC.Net> Cc: braden, mbone Subject: Re: What I wish I had said at the time... In-Reply-To: Your message of "Mon, 11 Dec 1995 19:57:56 EST." <Pine.OSF.3.91.951211195337.26970S-100000@nic.hq.cic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Dec 1995 22:26:00 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> >>> Dorian Kim said: > On Mon, 11 Dec 1995 braden@ISI.EDU wrote: > I disagree. The current state of mbone is indeed little more than a > "toy". A toy with a great deal of potential, just like Internet was ten > years ago, but a toy nonetheless. There are many issues to be resolved > before mbone can step into the limelight the way Internet has done over > the last year or so, and mbone BOF pointed out those issues. Please characterize "toy" in the context for the MBONE. BTW: Are there any more "toys" like the MBONE 8) Amancio From list-mgr@ISI.EDU Mon Dec 11 14:31:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01599>; Mon, 11 Dec 1995 22:33:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01568>; Mon, 11 Dec 1995 22:32:25 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA01556>; Mon, 11 Dec 1995 22:32:13 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id WAA06123; Mon, 11 Dec 1995 22:31:43 -0800 Message-Id: <199512120631.WAA06123@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Dorian Kim <dorian@CIC.Net> Cc: "Paul 'Shag' Walmsley" <ccshag@cclabs.missouri.edu>, braden, mbone Subject: Re: What I wish I had said at the time... In-Reply-To: Your message of "Mon, 11 Dec 1995 23:42:35 EST." <Pine.OSF.3.91.951211233648.7525E-100000@nic.hq.cic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Dec 1995 22:31:37 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> >>> Dorian Kim said: > It seems to me that this is veering off mbone and into semantics. As an > English major, I'd love to take this off mbone and continue to argue, > but.. :) > You challenge is welcomed and in fact it is perhaps the best way to iron out the mbone by using it in real life scenarios. Oh, my last sound driver bug related to supporting full duplex audio was iron out on the mbone 8) Enjoy, Amancio From list-mgr@ISI.EDU Mon Dec 11 21:23:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03117>; Mon, 11 Dec 1995 23:25:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03093>; Mon, 11 Dec 1995 23:25:21 -0800 Received: from davinci.gmu.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA03085>; Mon, 11 Dec 1995 23:25:19 -0800 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id CAA03909; Tue, 12 Dec 1995 02:23:09 -0500 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199512120723.CAA03909@davinci.gmu.edu> Subject: Re: What I wish I had said at the time... To: young@mci.net (Jeff Young) Date: Tue, 12 Dec 1995 02:23:05 -0500 (EST) Cc: dorian@cic.net, braden, mbone In-Reply-To: <199512120401.XAA02777@foghorn.reston.mci.net> from "Jeff Young" at Dec 11, 95 11:01:54 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1647 Technology viewed from a person's perspective that sees no serious application, whether because it is not mature or not used in their eyes properly, is often catagorized as a toy. I have seen ONYX's, PCs, etc. called toys. This was usually from one person's perpective. I don't believe Mr. Doran saw the Mbone as being mature when he catagorized it several times at IETF as a toy. It IS experimental but still remains from many other people's perspective a valuable tool. It is not a widely used tool, but it is very valuable, especially for applications such as distance learning or distributive simulations. Furthermore, its uses and number of users are growing. Whether it is a toy or tool, highly depends on your background, perspective, and forsight into the future. Basically your vision. Michael > in some ways right now it may be a toy, the quality > of the video isn't impressive which leads some to > believe that the technology will never fly. as we > all know the technology (save 200:1 compression) isn`t > the gating factor here - the bandwidth is. > > i did, however sneak into a pim mcast session before the > ietf where the idmr architects were discussing the > latest and greatest. just audio and whiteboard. > in the right hands, this technology is not a toy. it's > damn useful. there is more to life that broadcast > quality video :-). > > and perhaps someday we'll have that as well. > > Jeff Young > young@mci.net -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Tue Dec 12 11:41:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03733>; Mon, 11 Dec 1995 23:44:54 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03553>; Mon, 11 Dec 1995 23:41:53 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA03543>; Mon, 11 Dec 1995 23:41:46 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id JAA16943; Tue, 12 Dec 1995 09:41:37 +0200 Date: Tue, 12 Dec 1995 09:41:37 +0200 Message-Id: <199512120741.JAA16943@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Dorian Kim <dorian@CIC.Net> Cc: Petri Helenius <pete@sms.fi>, mbone Subject: Re: What I wish I had said at the time... In-Reply-To: <Pine.OSF.3.91.951212010748.8540A-100000@nic.hq.cic.net> References: <199512120557.HAA16711@silver.sms.fi> <Pine.OSF.3.91.951212010748.8540A-100000@nic.hq.cic.net> Dorian Kim writes: > On Tue, 12 Dec 1995, Petri Helenius wrote: > > > Dorian Kim writes: > > Why don't you do that today? The technology is there, unfortunately you > > have to carry two routing tables for "full interoperability". If you > > don't allow DVMRP on your leafs, your current routing protocol(s) will > > suffice. > > What would have happened if I ran mbone native on my router couple of > weeks ago? Will mbone snafu not effect my unicast infrastructure? When I > can be assured of that, I'll retire my mrouters. > The effect would have been limited to your DVMRP domain. Depending on your configuration this would have been one or more boxes. If you would have done only one interoperability point between PIM and DVMRP, the effect and thus the need of manual configuration and/or upgrades would have been limited to single box also. Pete From list-mgr@ISI.EDU Tue Dec 12 08:47:30 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05779>; Tue, 12 Dec 1995 00:50:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05734>; Tue, 12 Dec 1995 00:48:15 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA05727>; Tue, 12 Dec 1995 00:48:13 -0800 Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-20) id <AA17707>; Tue, 12 Dec 1995 00:48:10 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.04694-0@bells.cs.ucl.ac.uk>; Tue, 12 Dec 1995 08:47:33 +0000 To: Dorian Kim <dorian@CIC.Net> Cc: braden, mbone Subject: Re: What I wish I had said at the time... In-Reply-To: Your message of "Mon, 11 Dec 1995 19:57:56 EST." <Pine.OSF.3.91.951211195337.26970S-100000@nic.hq.cic.net> Date: Tue, 12 Dec 1995 08:47:30 +0000 Message-Id: <757.818758050@cs.ucl.ac.uk> From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> >I disagree. The current state of mbone is indeed little more than a >"toy". A toy with a great deal of potential, just like Internet was ten >years ago, but a toy nonetheless. There are many issues to be resolved >before mbone can step into the limelight the way Internet has done over >the last year or so, and mbone BOF pointed out those issues. dorian there is a difference between the technology and the deployment i nthe UK, the Mbone is nationally engineered, and is superior technically to our national 2Mbps GPT Video Codec based confernecing system and is definitely not a toy the technology is professional, and serious the international deployment is ogften toy, but that is a reflection of perceived markets and of the fact that many ISPs do not own the transmissio ncapcity they are selling on, so canot afford to provision the lines at the levels required because of telco pricing... jon From list-mgr@ISI.EDU Mon Dec 11 17:28:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06953>; Tue, 12 Dec 1995 01:30:07 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06937>; Tue, 12 Dec 1995 01:29:23 -0800 Received: from blob.best.net by venera.isi.edu (5.65c/5.61+local-22) id <AA06917>; Tue, 12 Dec 1995 01:28:51 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by blob.best.net (8.6.12/8.6.5) with SMTP id BAA28948 for <mbone@isi.edu>; Tue, 12 Dec 1995 01:28:49 -0800 Date: Tue, 12 Dec 1995 01:28:49 -0800 Message-Id: <199512120928.BAA28948@blob.best.net> X-Sender: rsf@pop.best.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: Ross Finlayson <finlayson@live.com> Subject: Re: What I wish I had said at the time... At 02:45 AM 12/12/95 +0200, Petri Helenius wrote: >At the very same time the big ISPs are just getting into the IP Multicast >deployment as a "service", at least within their backbone, their backbone >is being flooded by a horde of unicast-replication-based techniques, such >as CUseeME, StreamWorks (which does support also IP multicast) that are >mostly used on listening to/viewing live content. ... >...I would see >that more real content coming online and the "bandwidth of MBone" going >up to, say, 2Mbps would actually do the Internet as a whole a great service... This is a good point, and I'd also like to take this a step further and propose that multicast-based application developers get more serious about low-bandwidth links. In recent months a slew of audio/video Internet products have emerged, most of them using unicast with mysterious proprietary encodings. (You could probably come up with the names of a lot of these products by enumerating all the combinations of {Net,Web,Internet,Real}x{Audio,Video,Phone,TV} :-) It's disappointing to see these folks going off on their own, rather than working within the open Internet standardization process that most of us are familiar with. (Also, there's probably a lot that we could learn from them about ease-of-use/configuration.) But to their credit, they've provided an existence proof that it's possible to implement reasonable-quality audio (and sorta-kinda-OK video) over 28.8 kbps, which is the baseline bandwidth for most of the leaves of the Internet. So, one more way we could help make the MBone 'real' is to set an informal goal that each MBone sessions should be useable over 28 kbps (and defining/standardizing RTP payload formats that work well over such a b/w). Of course, this doesn't preclude having a MBone session take advantage of higher bandwidths where it's available - e.g., using hierarchical encodings with multiple group addresses. People have been talking about this for years now; I think it's time now to get serious about doing it on a regular basis. Ross. From list-mgr@ISI.EDU Tue Dec 12 06:44:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18490>; Tue, 12 Dec 1995 08:44:30 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18464>; Tue, 12 Dec 1995 08:44:03 -0800 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA18455>; Tue, 12 Dec 1995 08:44:02 -0800 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.7.2/8.7.2) id LAA14053 for mbone@isi.edu; Tue, 12 Dec 1995 11:44:24 -0500 (EST) From: Dave Thaler <thalerd@eecs.umich.edu> Message-Id: <199512121644.LAA14053@dip.eecs.umich.edu> Subject: SNMP-mrouted release 3.8.1 To: mbone Date: Tue, 12 Dec 1995 11:44:24 -0500 (EST) X-Mailer: ELM [version 2.4 PL24 PGP1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The SNMP release of mrouted3.8 is now available: Source: ftp://ftp.merit.edu/net-research/mbone/snmp-mrouted3.8.1.tar.gz SunOS binaries: ftp://ftp.merit.edu/net-research/mbone/snmp-mrouted3.8.1-sparc-sunos41x.tar.gz Binaries for several other platforms will hopefully be available in the near future. This release supports the new DVMRP MIB objects (such as routing table size and the altnet table), offers the ability to remotely configure tunnels, and allows easy coexistence with other snmp daemons. If port 161 is in use, snmp-mrouted will use port 9161 instead. Mstat has also been modified to try both ports. Dave Thaler From list-mgr@ISI.EDU Tue Dec 12 19:18:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19025>; Tue, 12 Dec 1995 08:57:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19009>; Tue, 12 Dec 1995 08:56:33 -0800 Received: from iraun1.ira.uka.de by venera.isi.edu (5.65c/5.61+local-22) id <AA18949>; Tue, 12 Dec 1995 08:54:04 -0800 Received: from navajo.telematik.informatik.uni-karlsruhe.de by iraun1.ira.uka.de with SMTP (PP); Tue, 12 Dec 1995 17:53:25 +0100 Received: from localhost by navajo.telematik.informatik.uni-karlsruhe.de; (5.65v3.0/1.1.8.2/18Sep95-0244PM) id AA03822; Tue, 12 Dec 1995 18:18:09 +0100 Message-Id: <9512121718.AA03822@navajo.telematik.informatik.uni-karlsruhe.de> To: mbone Subject: MBones for Linux Date: Tue, 12 Dec 95 18:18:09 +0100 From: dolk@telematik.informatik.uni-karlsruhe.de X-Mts: smtp ------- Forwarded Message To:casner@isi.edu cc: Subject: mbones for Linux - -------- Hi, i'am planning to install MBones on PC's. During my search for the source-codes, i found your e-mail-adress and hope that you can help me. I have a (pentium) PC with Linux as operating system.We have MBones succesfully installed on SunOS Release 4.1.3_U1. So i wish to know, where i can find MBones for Linux as operating platform. You know something about ? Stefan ------- End of Forwarded Message From list-mgr@ISI.EDU Tue Dec 12 18:44:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26217>; Tue, 12 Dec 1995 10:45:09 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26204>; Tue, 12 Dec 1995 10:44:52 -0800 Received: from cancer.ucs.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA26184>; Tue, 12 Dec 1995 10:44:44 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with ESMTP id SAA26671; Tue, 12 Dec 1995 18:44:24 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id SAA24703; Tue, 12 Dec 1995 18:44:18 GMT Date: Tue, 12 Dec 1995 18:44:13 +0000 (GMT) From: Graeme Wood <jaw@ucs.ed.ac.uk> Reply-To: Graeme.Wood@ucs.ed.ac.uk To: dolk@telematik.informatik.uni-karlsruhe.de Cc: mbone Subject: Re: MBones for Linux In-Reply-To: <9512121718.AA03822@navajo.telematik.informatik.uni-karlsruhe.de> Message-Id: <Pine.SV4.3.91.951212184042.22400P-100000@scorpio.ucs.ed.ac.uk> X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 12 Dec 1995 dolk@telematik.informatik.uni-karlsruhe.de wrote: > i'am planning to install MBones on PC's. During my search for the source-codes, > i found your e-mail-adress and hope that you can help me. > I have a (pentium) PC with Linux as operating system.We have MBones succesfully > installed on SunOS Release 4.1.3_U1. So i wish to know, where i can find MBones > for Linux as operating platform. You know something about ? You will find an archive of Mbone software including stuff for Linux at the MICE National Support Centre for Germany: http://www-ks.rus.uni-stuttgart.de/mice-nsc/ ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From list-mgr@ISI.EDU Tue Dec 12 04:26:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25708>; Tue, 12 Dec 1995 10:38:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25671>; Tue, 12 Dec 1995 10:37:06 -0800 Received: from challenge.TCEL.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA25664>; Tue, 12 Dec 1995 10:37:04 -0800 Received: from indy.tcel.com (indy.TCEL.COM [198.161.236.27]) by challenge.tcel.com (8.6.12/1.2) with ESMTP id 199512121826.LAA22598; Tue, 12 Dec 1995 11:26:02 -0700 Received: (sean@localhost) by indy.tcel.com (940816.SGI.8.6.9/1.2) id LAA13959; Tue, 12 Dec 1995 11:26:43 -0700 From: "Sean Watkins" <sean@tcel.com> Message-Id: <9512121126.ZM13957@indy.tcel.com> Date: Tue, 12 Dec 1995 11:26:42 -0700 In-Reply-To: dolk@telematik.informatik.uni-karlsruhe.de "MBones for Linux" (Dec 12, 12:18pm) References: <9512121718.AA03822@navajo.telematik.informatik.uni-karlsruhe.de> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: dolk@telematik.informatik.uni-karlsruhe.de, mbone Subject: Re: MBones for Linux Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Dec 12, 12:18pm, dolk@telematik.informatik.uni-karlsruhe.de wrote: > Subject: MBones for Linux > > http://www.cs.virginia.edu/~mke2e/multicast.html -- Sean Watkins Telnet Canada email: sean@corp.tcel.com 1500, 540 5th Ave. S.W. voice: **(403) 262-5859** fax: (403) 228-9702 Calgary, AB, Canada From list-mgr@ISI.EDU Tue Dec 12 14:27:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02546>; Tue, 12 Dec 1995 12:27:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02527>; Tue, 12 Dec 1995 12:27:25 -0800 Received: from monolith (jtemplin.d.umn.edu) by venera.isi.edu (5.65c/5.61+local-22) id <AA02520>; Tue, 12 Dec 1995 12:27:24 -0800 Received: by monolith (Linux Smail3.1.28.1 #14) id m0tPVfs-000DFNC; Tue, 12 Dec 95 14:27 GMT Message-Id: <m0tPVfs-000DFNC@monolith> From: jtemplin@jtemplin.d.umn.edu (Josh Templin) Subject: MBONE Provider - US-MN-NE To: mbone Date: Tue, 12 Dec 1995 14:27:18 +0000 (GMT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 909 Greetings! It seems my ISP is not interested in dealing with MBONE issues at this time and I have been left to seek connectivity elsewhere .. beyond my ISP's scope. Since my ISP has 'given permission' for me to tunnel traffic through their systems, I am looking to run mrouted on my own machine (Linux, connected with 10mbs ethernet). Since MBONE traffic and tunneling needs to have physical considerations, I am asking the group to find someone physically near my site to tunnel traffic to me. My location is Duluth, Minnesota, USA. It it located in the North East region of Minnesota. Please let me know any suggestions you may have ... thank you! Joshua -- = jtemplin is Joshua Templin (KB9ENE) FDC Kisasian jtemplin@d.umn.edu = = "A dark and cold highway stretched off into the unforseeable distance. = = On it walked two lions, one real, and one a guide." = From list-mgr@ISI.EDU Tue Dec 12 06:42:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03288>; Tue, 12 Dec 1995 12:42:29 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03268>; Tue, 12 Dec 1995 12:42:08 -0800 Received: from agt.net (clgrps02.agt.net) by venera.isi.edu (5.65c/5.61+local-22) id <AA03260>; Tue, 12 Dec 1995 12:42:06 -0800 Received: (from walter@localhost) by agt.net (8.6.11/8.6.9) id NAA11848 for mbone@isi.edu; Tue, 12 Dec 1995 13:42:05 -0700 From: Jason Walters <walter@agt.net> Message-Id: <199512122042.NAA11848@agt.net> Subject: filtering To: mbone Date: Tue, 12 Dec 1995 13:42:04 -0700 (MST) X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 658 Dear Ppl: I am a newbie at MBONE stuff. We are getting a 500kb tunnel from ANS. We have a customer who is interested only in certain broadcasts as they only have 64kb access to our site. Is there anyway to "filter" and only transmit certain broadcasts into the tunnel to this site? Thanks in advance. RTFM's welcome. Jason -- Jason Walters walter@agt.net -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQBtAy/XKd4AAAEDANZeevJlDmCTe/VH9qAzF16IQQ9BApDf3QYefvDv5HKP4tqS wTHygxtXurycDJIQs2mn7RPcB46cT8Snb32U27Mu9zK0qwlYa0/M5UHSfDfKHJJE wc8d1tl4uZ1mC+4jJQAFEbQhSmFzb24gQy4gV2FsdGVycyA8d2FsdGVyQGFndC5u ZXQ+ =oSfu -----END PGP PUBLIC KEY BLOCK----- From list-mgr@ISI.EDU Tue Dec 12 11:21:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05319>; Tue, 12 Dec 1995 13:18:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05299>; Tue, 12 Dec 1995 13:18:30 -0800 Received: from maelstrom.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA05292>; Tue, 12 Dec 1995 13:18:28 -0800 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.7.1/8.6.6) id QAA05857; Tue, 12 Dec 1995 16:21:09 -0500 (EST) Message-Id: <199512122121.QAA05857@maelstrom.cc.mcgill.ca> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Yves Lepage <yves@CC.McGill.CA> Date: Tue, 12 Dec 95 16:21:06 -0500 To: Jason Walters <walter@agt.net> Subject: Re: filtering Cc: mbone Reply-To: yves@cc.mcgill.ca References: <199512122042.NAA11848@agt.net> Hello Jason, If your multicast router supports pruning and that of your customer also does, there should be no need for filtering as they will only receive the multicast traffic they asked for. Now, 64kbps will probably be good enough for an audio stream, but I would anticipate video as being very problematic. Regards, Yves Lepage From list-mgr@ISI.EDU Tue Dec 12 05:05:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06313>; Tue, 12 Dec 1995 13:40:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06300>; Tue, 12 Dec 1995 13:39:41 -0800 Received: from stone.ucs.indiana.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA06291>; Tue, 12 Dec 1995 13:39:37 -0800 Received: from localhost (localhost [127.0.0.1]) by stone.ucs.indiana.edu (8.6.10/8.7.Alpha.5) with SMTP id KAA15383 for <mbone@isi.edu>; Tue, 12 Dec 1995 10:05:40 -0500 Message-Id: <199512121505.KAA15383@stone.ucs.indiana.edu> To: mbone Subject: mbone administrator for U. of Hawaii? Date: Tue, 12 Dec 1995 10:05:39 -0500 From: Allen Robel <robelr@cell-relay.indiana.edu> Hi, I hope this is not an inappropriate question for this list. I am trying to find an email address for the person(s) (if they exist) that administer U. of Hawaii's mbone tunnel. Our Music Department is wanting to try some things with folks over there, and these folks, while musically proficient, are not so mbone proficient. Any leads appreciated, and apologies in advance if i'm off-topic... Allen Robel robelr@indiana.edu Indiana University Area Code + Prefix: 812-855 http://cell-relay.indiana.edu/allen Office 0962, Lab 3697, FAX 8299 From list-mgr@ISI.EDU Tue Dec 12 05:50:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07248>; Tue, 12 Dec 1995 13:51:54 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06956>; Tue, 12 Dec 1995 13:51:21 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA06947>; Tue, 12 Dec 1995 13:51:20 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14759(8)>; Tue, 12 Dec 1995 13:51:13 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 12 Dec 1995 13:51:05 -0800 To: Jason Walters <walter@agt.net> Cc: mbone, deering@parc.xerox.com Subject: Re: filtering In-Reply-To: walter's message of Tue, 12 Dec 95 12:42:04 -0800. <199512122042.NAA11848@agt.net> Date: Tue, 12 Dec 1995 13:50:52 PST Sender: Steve Deering <deering@parc.xerox.com> From: Steve Deering <deering@parc.xerox.com> Message-Id: <95Dec12.135105pst.75270@digit.parc.xerox.com> > I am a newbie at MBONE stuff. We are getting a 500kb tunnel from > ANS. We have a customer who is interested only in certain broadcasts > as they only have 64kb access to our site. Is there anyway to "filter" > and only transmit certain broadcasts into the tunnel to this site? Jason, As long as all of the customer's multicast routers, plus the multicast router on your end of the customer's tunnel, support "pruning", the only traffic streams that will be delivered down the customer's tunnel will be those that the customer has explicitly requested (by running an application that joins a specific multicast group). If the multicast routers are all Unix boxes running mrouted, you should use mrouted version 3.5 or later, preferably version 3.8. Steve From list-mgr@ISI.EDU Tue Dec 12 07:22:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13338>; Tue, 12 Dec 1995 15:23:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13307>; Tue, 12 Dec 1995 15:23:19 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA13298>; Tue, 12 Dec 1995 15:23:17 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id PAA02099; Tue, 12 Dec 1995 15:22:59 -0800 Message-Id: <199512122322.PAA02099@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: yves@CC.McGill.CA Cc: Jason Walters <walter@agt.net>, mbone Subject: Re: filtering In-Reply-To: Your message of "Tue, 12 Dec 1995 16:21:06 EST." <199512122121.QAA05857@maelstrom.cc.mcgill.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Dec 1995 15:22:59 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Well, a friend of mine has a 56kb line and we swap video back and forth with vic / h.261 /small picture. Is not bad 8) I have a 128kb isdn line . We use FreeBSD boxes with Matrox Meteor PCI video capture boards . Enjoy, Amancio >>> Yves Lepage said: > Hello Jason, > > If your multicast router supports pruning and that of your customer > also does, there should be no need for filtering as they will only > receive the multicast traffic they asked for. > > Now, 64kbps will probably be good enough for an audio stream, but I would > anticipate video as being very problematic. > > Regards, > Yves Lepage From list-mgr@ISI.EDU Tue Dec 12 16:11:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27382>; Tue, 12 Dec 1995 18:12:58 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27294>; Tue, 12 Dec 1995 18:11:55 -0800 Received: from foghorn.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA27235>; Tue, 12 Dec 1995 18:11:52 -0800 Received: from localhost (young@localhost) by foghorn.reston.mci.net (8.6.12/8.6.9) with SMTP id VAA10324; Tue, 12 Dec 1995 21:11:47 -0500 Message-Id: <199512130211.VAA10324@foghorn.reston.mci.net> X-Authentication-Warning: foghorn.reston.mci.net: young owned process doing -bs X-Authentication-Warning: foghorn.reston.mci.net: Host localhost didn't use HELO protocol To: jtemplin@jtemplin.d.umn.edu (Josh Templin) Cc: mbone, mbone@mci.net Subject: Re: MBONE Provider - US-MN-NE In-Reply-To: Your message of "Tue, 12 Dec 1995 14:27:18 GMT." <m0tPVfs-000DFNC@monolith> Date: Tue, 12 Dec 1995 21:11:46 -0500 From: "Jeff Young" <young@mci.net> greetings as well, i'm afraid to admit it but it looks like mci is your service provider, correct? i'd be really interested to know just who told you to tunnel through us (as i'm actively trying to redirect such tunnels). we're open for business on the mbone, we have a good start at an mbone infrastructure and i'd be happy to provide a tunnel (if you'll run mrouted 3.8 and agree not to feed anyone else on the mci network?). the tunnel is free, please send me your end-point address. Jeff Young young@mci.net young@home% traceroute d.umn.edu [~] traceroute to d.umn.edu (131.212.33.33) 30 hops max, 38 byte packets 1 goobernet-ppp.Reston.mci.net (204.70.130.1) 251 ms (ttl=64!) 237 ms (ttl=64!) 209 ms (ttl=64!) 2 cpe1-ethernet1-0.Reston.mci.net (204.70.128.2) 218 ms 257 ms 326 ms 3 borderx1-fddi-2.Reston.mci.net (204.70.176.101) 373 ms 301 ms 364 ms 4 core2-fddi-0.Reston.mci.net (204.70.176.49) 426 ms 415 ms 393 ms 5 core1-hssi-4.Greensboro.mci.net (204.70.1.161) 322 ms 238 ms 330 ms 6 core2-hssi-3.Washington.mci.net (204.70.1.130) 438 ms 408 ms 289 ms 7 core2-hssi-3.WestOrange.mci.net (204.70.1.105) 218 ms 408 ms 299 ms 8 core1-aip-4.WestOrange.mci.net (204.70.1.65) 313 ms 294 ms 441 ms 9 core1-hssi-3.NorthRoyalton.mci.net (204.70.1.101) 480 ms 727 ms 701 ms 10 core-hssi-2.Chicago.mci.net (204.70.1.93) 395 ms 268 ms 396 ms 11 border3-fddi-0.Chicago.mci.net (204.70.2.83) 436 ms 311 ms 276 ms 12 204.70.26.6 (204.70.26.6) 548 ms 378 ms 347 ms 13 tc0+.gw.umn.edu (198.174.96.4) 301 ms 250 ms 329 ms 14 tc1.gw.umn.edu (134.84.254.254) 299 ms 383 ms 494 ms 15 131.212.6.1 (131.212.6.1) 329 ms 131.212.7.1 (131.212.7.1) 372 ms 581 ms 16 mwah.d.umn.edu (131.212.254.254) 526 ms * 290 ms > From: jtemplin@jtemplin.d.umn.edu (Josh Templin) > Subject: MBONE Provider - US-MN-NE > To: mbone@ISI.EDU > Date: Tue, 12 Dec 1995 14:27:18 +0000 (GMT) > > Greetings! > > It seems my ISP is not interested in dealing with MBONE issues at this time > and I have been left to seek connectivity elsewhere .. beyond my ISP's > scope. Since my ISP has 'given permission' for me to tunnel traffic through > their systems, I am looking to run mrouted on my own machine (Linux, > connected with 10mbs ethernet). Since MBONE traffic and tunneling needs to > have physical considerations, I am asking the group to find someone > physically near my site to tunnel traffic to me. My location is Duluth, > Minnesota, USA. It it located in the North East region of Minnesota. > > > Please let me know any suggestions you may have ... thank you! > > Joshua > -- > = jtemplin is Joshua Templin (KB9ENE) FDC Kisasian jtemplin@d.umn.edu = > = "A dark and cold highway stretched off into the unforseeable distance. = > = On it walked two lions, one real, and one a guide." = From list-mgr@ISI.EDU Wed Dec 13 22:31:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07943>; Tue, 12 Dec 1995 22:22:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07920>; Tue, 12 Dec 1995 22:21:49 -0800 Received: from nficm2cb.com.tw ([202.39.221.2]) by venera.isi.edu (5.65c/5.61+local-22) id <AA07912>; Tue, 12 Dec 1995 22:21:45 -0800 Received: from 202.39.221.2 ([202.39.221.21]) by nficm2cb.com.tw (8.6.9/8.6.9) with SMTP id OAA07093 for <mbone@isi.edu>; Wed, 13 Dec 1995 14:31:42 +0800 Date: Wed, 13 Dec 1995 14:31:42 +0800 Message-Id: <199512130631.OAA07093@nficm2cb.com.tw> X-Sender: tyyang@nficm2cb.com.tw X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: tyyang@nficm2cb.com.tw (Tsang-Yuan Yang) subscribe mbone +---------------------------------------+----------------------------------- ------+ |Tsang-Yuan Yang | 10F-6, NO 351, Chung SHAN RD. SEC. 2,| |Manager | CHUNG HO CITY, TAIPEI, TAIWAN, R.O.C | |Multi-media & Communication DIV. | TEL: 886-2-226-4627 | |Formosa Industrial Computing, INC. | FAX: 886-2-226-0840 | +---------------------------------------+----------------------------------- ------+ From list-mgr@ISI.EDU Wed Dec 13 01:36:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17751>; Wed, 13 Dec 1995 05:36:47 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17743>; Wed, 13 Dec 1995 05:36:21 -0800 Received: from geordi.MR.Net by venera.isi.edu (5.65c/5.61+local-22) id <AA17736>; Wed, 13 Dec 1995 05:36:19 -0800 Received: (from bergum@localhost) by geordi.mr.net (8.6.12/8.6.12) id HAA13373; Wed, 13 Dec 1995 07:36:16 -0600 Date: Wed, 13 Dec 1995 07:36:16 -0600 X-Url: http://www.mr.net/~bergum/ Message-Id: <199512131336.HAA13373@geordi.mr.net> From: Dave Bergum <bergum@MR.Net> To: jtemplin@jtemplin.d.umn.edu (Josh Templin) Cc: mbone Subject: MBONE Provider - US-MN-NE In-Reply-To: <m0tPVfs-000DFNC@monolith> References: <m0tPVfs-000DFNC@monolith> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII >>>>> On Tue, 12 Dec 1995 14:27:18 +0000 (GMT), jtemplin@jtemplin.d.umn.edu (Josh Templin) said: Josh> Greetings! Josh> It seems my ISP is not interested in dealing with MBONE issues at this time Josh> and I have been left to seek connectivity elsewhere .. beyond my ISP's Josh> scope. Since my ISP has 'given permission' for me to tunnel traffic through Josh> their systems, I am looking to run mrouted on my own machine (Linux, Josh> connected with 10mbs ethernet). Since MBONE traffic and tunneling needs to Josh> have physical considerations, I am asking the group to find someone Josh> physically near my site to tunnel traffic to me. My location is Duluth, Josh> Minnesota, USA. It it located in the North East region of Minnesota. Josh> Please let me know any suggestions you may have ... thank you! Josh, Who is your ISP? Are you involved with umn.edu or are you just using UMD for email? umn.edu has mbone tunnels to it. this would be the best source if you are speaking for UMD. I do not think that the current access links to Duluth can handle the traffic, thought. Dave. From list-mgr@ISI.EDU Wed Dec 13 08:43:25 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05007>; Wed, 13 Dec 1995 10:43:32 -0800 Received: from shrug (shrug.whoi.edu) by venera.isi.edu (5.65c/5.61+local-22) id <AA04992>; Wed, 13 Dec 1995 10:43:28 -0800 Received: (from scott@localhost) by shrug (8.6.10/8.6.9) id NAA11247 for mbone-na@isi.edu; Wed, 13 Dec 1995 13:43:26 -0500 Date: Wed, 13 Dec 1995 13:43:25 -0500 (EST) From: "Scott A. McIntyre" <scott@shrug.whoi.edu> Subject: Unadvertised sessions To: mbone-na Message-Id: <951213134325.11071AACYK.scott@shrug> Mime-Version: 1.0 (Generated by Eloquent) Content-Type: text/plain; charset=US-ASCII X-Mailer: Eloquent[2.01]; Eloquent is a Trademark of Take 3 Hello, I've noticed recently that the contents of sd have been looking rather sparse; this is in direct contrast to all of the traffic this list has shown in relation to sessions currently underway and planned for the immediate future. The problem seems to be that we're only seeing the cisco beta, the house and senate, world radio network, internet town hall and radio free vat. Nothing else shows up at all. Our network guru has cleared the routing tables on the router a few times -- that fixed it once last year, but at the moment I think he said he's seeing several thousand advertised routes at one end of the link and only a few hundred on the other side... We are NOT running mrouted, but instead are relying upon two proteon routers and dvmrp over a microwave link...could this be the problem? Any advice is greatfully appreciated. Scott From list-mgr@ISI.EDU Wed Dec 13 10:34:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13581>; Wed, 13 Dec 1995 12:38:20 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA13562>; Wed, 13 Dec 1995 12:38:10 -0800 Received: from bbnplanet.com (poblano.near.net) by quark.isi.edu (5.65c/5.61+local-20) id <AA13052>; Wed, 13 Dec 1995 12:38:08 -0800 Subject: Re: Unadvertised sessions To: "Scott A. McIntyre" <scott@shrug.whoi.edu> Date: Wed, 13 Dec 1995 15:34:07 -0500 (EST) From: John Hawkinson <jhawk@bbnplanet.com> Cc: mbone-na In-Reply-To: <951213134325.11071AACYK.scott@shrug> from "Scott A. McIntyre" at Dec 13, 95 01:43:25 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1095 Message-Id: <9512131534.aa28864@poblano.bbnplanet.com> > From: "Scott A. McIntyre" <scott@shrug.whoi.edu> > Subject: Unadvertised sessions > To: mbone-na@isi.edu > The problem seems to be that we're only seeing the cisco beta, the house and > senate, world radio network, internet town hall and radio free vat. Nothing > else shows up at all. Our network guru has cleared the routing tables on > the router a few times -- that fixed it once last year, but at the moment I > think he said he's seeing several thousand advertised routes at one end of > the link and only a few hundred on the other side... > > We are NOT running mrouted, but instead are relying upon two proteon routers > and dvmrp over a microwave link...could this be the problem? In general the correct thing to do to diagnose mbone problems is to talk to the people providing you with mbone service, which is normally your Internet provider, rather than sending mail to mbone-na. Oddly enough, that's us. :-) So if you could have your "network guru" send me a precise description of the problem I'll be happy to take a look. Thanks. --jhawk@bbnplanet.com John Hawkinson From list-mgr@ISI.EDU Wed Dec 13 10:48:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14168>; Wed, 13 Dec 1995 12:48:38 -0800 Received: from stone.ucs.indiana.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA14159>; Wed, 13 Dec 1995 12:48:35 -0800 Received: from localhost (localhost [127.0.0.1]) by stone.ucs.indiana.edu (8.6.10/8.7.Alpha.5) with SMTP id PAA04286; Wed, 13 Dec 1995 15:48:19 -0500 Message-Id: <199512132048.PAA04286@stone.ucs.indiana.edu> To: "Scott A. McIntyre" <scott@shrug.whoi.edu> Cc: mbone-na, robelr@stone.ucs.indiana.edu Subject: Re: Unadvertised sessions In-Reply-To: Your message of "Wed, 13 Dec 1995 13:43:25 EST." <951213134325.11071AACYK.scott@shrug> Date: Wed, 13 Dec 1995 15:48:19 -0500 From: Allen Robel <robelr@cell-relay.indiana.edu> >I've noticed recently that the contents of sd have been looking rather >sparse; this is in direct contrast to all of the traffic this list has shown >in relation to sessions currently underway and planned for the immediate >future. I've noticed the same thing. Even though the cisco I'm using shows additional sessions (see below), sd on a Sparc20 (Solaris) attached to an ethernet off this router (configured with 'ip pim dense') sees just the limited entries that you describe... -allen atmlab1>sh ip sd SD Cache - 31 entries CERN: LEP 1.5 Seminar cisco Beta IMS: Internet Town Hall IMS: U.S. House IMS: U.S. Senate IMS: World Radio Network Kansas vs. San Diego MBone Audio MBone IVS MBone Video MC: Poi Dog Pondering (LIVE) MC: The Greatful Web NVESD NZ: ICONZ Test PIM weekly discussion PIM weekly meeting Radio Free Vat Rakino's Cafe SUNY DISTANCE LEARNING sva Swiss Telecom PTT R&D swiss telecom test Swiss Telecom Videoconferencing test 4 USC-CS dgroup VR conference room (private) WWW Channel 1 Audio WWW Channel 1 Feedback Whiteboard WWW Channel 1 Video WWW Channel 2 Audio WWW Channel 2 Feedback Whiteboard WWW Channel 2 Video From list-mgr@ISI.EDU Wed Dec 13 11:41:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19623>; Wed, 13 Dec 1995 13:42:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19411>; Wed, 13 Dec 1995 13:42:08 -0800 Received: from vax.darpa.mil (darpa.mil) by venera.isi.edu (5.65c/5.61+local-22) id <AA19400>; Wed, 13 Dec 1995 13:42:06 -0800 Received: from next148.darpa.mil (next148.darpa.mil) by vax.darpa.mil (5.65c/5.61+local-5) id <AA19268>; Wed, 13 Dec 1995 16:42:02 -0500 Received: by next148.darpa.mil (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA27599; Wed, 13 Dec 95 16:41:09 EST Message-Id: <9512132141.AA27599@ next148.darpa.mil > Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: multipart/alternative; boundary=NeXT-Mail-1264892504-1 Content-Transfer-Encoding: 7bit Received: by NeXT.Mailer (1.118.2) From: Howard Berg <berghg@ito.snap.org> Date: Wed, 13 Dec 95 16:41:06 -0500 To: mbone Subject: Monday Broadcast - 18 Dec 95 Cc: berghg@ARPA.MIL, jkier@ARPA.MIL, mgilliam@ARPA.MIL Reply-To: berghg@ito.snap.org --NeXT-Mail-1264892504-1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The ARPA/ITO Integration Testbed will be broadcasting the ARPA BAA = announcements by Dr Leiner and his group. Our broadcast will begin at = 12:00 noon to 3:00pm EST on Monday, December 18, 1995 and will include = video and audio. Please direct any queries to: Howard Berg or Mike Gilliam at = 703-812-4723 --NeXT-Mail-1264892504-1 Content-Type: text/enriched; charset=us-ascii Content-Transfer-Encoding: quoted-printable The ARPA/ITO Integration Testbed will be broadcasting the ARPA BAA = announcements by Dr Leiner and his group. Our broadcast will begin at = 12:00 noon to 3:00pm EST on Monday, December 18, 1995 and will include = video and audio. Please direct any queries to: Howard Berg or Mike Gilliam at 703-812 - 4723 --NeXT-Mail-1264892504-1-- From list-mgr@ISI.EDU Wed Dec 13 09:31:40 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04316>; Wed, 13 Dec 1995 17:31:32 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04293>; Wed, 13 Dec 1995 17:30:44 -0800 Received: from aimnet.com (mailhub1.aimnet.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA04285>; Wed, 13 Dec 1995 17:30:43 -0800 Received: from netcom.ix.netcom.com (ix-sr3-19.ix.netcom.com [199.182.131.115]) by aimnet.com (8.7.1/8.7.1) with SMTP id RAA18893 for <mbone@ISI.EDU>; Wed, 13 Dec 1995 17:31:40 -0800 (PST) Date: Wed, 13 Dec 1995 17:31:40 -0800 (PST) Message-Id: <199512140131.RAA18893@aimnet.com> X-Sender: twsales@mailhub.aimnet.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: twsales@aimnet.com (travelwest.com) Subject: subscribe subscribe From list-mgr@ISI.EDU Wed Dec 13 15:25:31 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04236>; Wed, 13 Dec 1995 17:29:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04133>; Wed, 13 Dec 1995 17:25:39 -0800 Received: from mozart.american.com by venera.isi.edu (5.65c/5.61+local-22) id <AA04124>; Wed, 13 Dec 1995 17:25:37 -0800 Received: from localhost (localhost [127.0.0.1]) by mozart.american.com (8.6.12/8.6.9) with SMTP id UAA01322 for <mbone@isi.edu>; Wed, 13 Dec 1995 20:25:32 -0500 Message-Id: <199512140125.UAA01322@mozart.american.com> X-Authentication-Warning: mozart.american.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.4 10/10/95 To: mbone Subject: vic 2.7x for freebsd binaries? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Dec 1995 20:25:31 -0500 From: Brad Parker <brad@American.COM> Sorry, if this is inappropriate - I was wondering if anyone was tracking vic 2.7 progress and building it for freebsd 2.1. I'd like to try running vic on freebsd and the only 2.7 binaries I can find are for Solaris, SunOS, etc... Is it that the performance is so bad that no one does it? (I understood that vic with the Meteor card was 'ok' - without this card is video hopeless?) -brad From list-mgr@ISI.EDU Thu Dec 14 20:07:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06753>; Wed, 13 Dec 1995 18:23:00 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06210>; Wed, 13 Dec 1995 18:12:15 -0800 Received: from sol.nuri.net by venera.isi.edu (5.65c/5.61+local-22) id <AA06202>; Wed, 13 Dec 1995 18:12:12 -0800 Received: from sosaria.inet.co.kr (sosaria.inet.co.kr [203.255.113.40]) by sol.nuri.net (8.6.12H1/8.6.9) with SMTP id LAA16652 for <mbone@ISI.EDU>; Thu, 14 Dec 1995 11:07:55 +0900 Date: Thu, 14 Dec 1995 11:07:55 +0900 Message-Id: <199512140207.LAA16652@sol.nuri.net> X-Sender: sosarian@sol.nuri.net X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone From: Kyungsoon Park <sosarian@nuri.net> Subject: mbone problem Hi, I'm trying to setup mbone in SunSparc20 with Solaris 2.4, I upgraded multicast tunnel 3.5, and configured mt mrouted.conf like tunnel 203.255.112.9 204.70.158.77 metric 1 treshold 128 rate_limit 500 tunnel 203.255.112.9 203.255.113.40 metric 1 treshold 32 rate_limit 500 112.9 is our Sparc machine, and 158.77 is MCI. ans 113.40 is my Linux machine. but when I try some tests, it seems doesn't work correctly. These are my test results. map-mbone : Multicast Router Connectivity: (that's all) mrinfo : 127.0.0.1 (localhost) [version 3.6] : 203.255.112.9 -> 0.0.0.0 (local) [1/1/querier/leaf] 203.255.112.9 -> 204.70.158.77 (dec3800-2-fddi-1.SanFrancisco.mci.net) [1/128/tunnel/down/leaf] 203.255.112.9 -> 203.255.113.40 (sosaria.inet.co.kr) [1/32/tunnel/down/leaf] (it seems right, I think..) mtrace 204.70.158.77 : Mtrace from 204.70.158.77 to 203.255.112.9 via group 224.2.0.1 Querying full reverse path... * switching ro hop-by-hop: 0 gam (203.255.112.9) -1 * * * Timed out receiving response Perhaps no local router has a route for source 204.70.158.77 Can someone help me? Thanks. ------------ I.NET Technologies, Inc. (http://www.iworld.net) Technical Staff Mr. Kyungsoon 'Sosarian' Park email : sosarian@nuri.net tel : +82-2-538-6941 fax : +82-2-508-5679 From list-mgr@ISI.EDU Wed Dec 13 18:52:45 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11889>; Wed, 13 Dec 1995 20:55:20 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11852>; Wed, 13 Dec 1995 20:53:24 -0800 Received: from clone4.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA11845>; Wed, 13 Dec 1995 20:53:22 -0800 Received: from localhost (localhost.mci.net [127.0.0.1]) by clone4.reston.mci.net (8.6.12/8.6.6) with ESMTP id XAA02345; Wed, 13 Dec 1995 23:52:46 -0500 Message-Id: <199512140452.XAA02345@clone4.reston.mci.net> To: Kyungsoon Park <sosarian@nuri.net> Cc: mbone Subject: Re: mbone problem In-Reply-To: Your message of "Thu, 14 Dec 1995 11:07:55 +0900." <199512140207.LAA16652@sol.nuri.net> Date: Wed, 13 Dec 1995 23:52:45 -0500 From: "Jeff Young" <young@mci.net> kyungsoon, i'd be happy to help, the tunnel appears up on my side: 204.70.158.77 -> 203.255.112.9 (gam.nuri.net) [1/128/tunnel/leaf] however there is no multicast route in the routing table for dec2.hay.mci.net --> gam.nuri.net: 11 fta1 204.70.158.77 tunnel: 203.255.112.9 1 128 500 one-way le af peers: 203.255.112.9 (3.6) (0xe) pkts in : 0 pkts out: 2658 1.) are you sure that mrouted is currently running? 2.) are you sure that you did the multicast patches for solaris 2.4? 3.) what patch level is your solaris (especially 101945-??)? 4.) would you like to go ahead and upgrade to mrouted 3.8? 5.) we could and should move this off-line. Jeff Young young@mci.net > Date: Thu, 14 Dec 1995 11:07:55 +0900 > To: mbone@ISI.EDU > From: Kyungsoon Park <sosarian@nuri.net> > Subject: mbone problem > > Hi, > I'm trying to setup mbone in SunSparc20 with Solaris 2.4, > I upgraded multicast tunnel 3.5, and configured mt mrouted.conf like > > tunnel 203.255.112.9 204.70.158.77 metric 1 treshold 128 rate_limit 500 > tunnel 203.255.112.9 203.255.113.40 metric 1 treshold 32 rate_limit 500 > > 112.9 is our Sparc machine, and 158.77 is MCI. > ans 113.40 is my Linux machine. > > but when I try some tests, it seems doesn't work correctly. > These are my test results. > > map-mbone : > > Multicast Router Connectivity: > (that's all) > > > > mrinfo : > > 127.0.0.1 (localhost) [version 3.6] : > 203.255.112.9 -> 0.0.0.0 (local) [1/1/querier/leaf] > 203.255.112.9 -> 204.70.158.77 (dec3800-2-fddi-1.SanFrancisco.mci.net) > [1/128/tunnel/down/leaf] > 203.255.112.9 -> 203.255.113.40 (sosaria.inet.co.kr) > [1/32/tunnel/down/leaf] > (it seems right, I think..) > > > mtrace 204.70.158.77 : > > Mtrace from 204.70.158.77 to 203.255.112.9 via group 224.2.0.1 > Querying full reverse path... * switching ro hop-by-hop: > 0 gam (203.255.112.9) > -1 * * * Timed out receiving response > Perhaps no local router has a route for source 204.70.158.77 > > Can someone help me? > Thanks. > > > > > > ------------ > I.NET Technologies, Inc. (http://www.iworld.net) > Technical Staff > > Mr. Kyungsoon 'Sosarian' Park > > email : sosarian@nuri.net > tel : +82-2-538-6941 > fax : +82-2-508-5679 > From list-mgr@ISI.EDU Fri Dec 15 00:04:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14241>; Wed, 13 Dec 1995 22:12:22 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14137>; Wed, 13 Dec 1995 22:09:44 -0800 Received: from sol.nuri.net by venera.isi.edu (5.65c/5.61+local-22) id <AA14130>; Wed, 13 Dec 1995 22:09:42 -0800 Received: from sosaria.inet.co.kr (sosaria.inet.co.kr [203.255.113.40]) by sol.nuri.net (8.6.12H1/8.6.9) with SMTP id PAA29871; Thu, 14 Dec 1995 15:04:39 +0900 Date: Thu, 14 Dec 1995 15:04:39 +0900 Message-Id: <199512140604.PAA29871@sol.nuri.net> X-Sender: sosarian@sol.nuri.net X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: "Jeff Young" <young@mci.net> From: Kyungsoon Park <sosarian@nuri.net> Subject: Re: mbone problem Cc: mbone Thanks. I check my mrouted again. But it is running. $)C At 11:52 ?@HD 95-12-13 -0500, Jeff Young wrote: >kyungsoon, > >i'd be happy to help, the tunnel appears up on my side: > > 204.70.158.77 -> 203.255.112.9 (gam.nuri.net) [1/128/tunnel/leaf] > >however there is no multicast route in the routing table >for dec2.hay.mci.net --> gam.nuri.net: > >11 fta1 204.70.158.77 tunnel: 203.255.112.9 1 128 500 one-way le >af > peers: 203.255.112.9 (3.6) (0xe) > pkts in : 0 > pkts out: 2658 > >1.) are you sure that mrouted is currently running? Sure. mrouted process running now. >2.) are you sure that you did the multicast patches for solaris 2.4? Yes. patch with Multicast Kernel 3.5 >3.) what patch level is your solaris (especially 101945-??)? >4.) would you like to go ahead and upgrade to mrouted 3.8? Isn't it running on mrouted 3.5? It is our Web Server. so it's difficult to shut down the system. But.... > >5.) we could and should move this off-line. > > >Jeff Young >young@mci.net > > >> Date: Thu, 14 Dec 1995 11:07:55 +0900 >> To: mbone@ISI.EDU >> From: Kyungsoon Park <sosarian@nuri.net> >> Subject: mbone problem >> >> Hi, >> I'm trying to setup mbone in SunSparc20 with Solaris 2.4, >> I upgraded multicast tunnel 3.5, and configured mt mrouted.conf like >> >> tunnel 203.255.112.9 204.70.158.77 metric 1 treshold 128 rate_limit 500 >> tunnel 203.255.112.9 203.255.113.40 metric 1 treshold 32 rate_limit 500 >> >> 112.9 is our Sparc machine, and 158.77 is MCI. >> ans 113.40 is my Linux machine. >> >> but when I try some tests, it seems doesn't work correctly. >> These are my test results. >> >> map-mbone : >> >> Multicast Router Connectivity: >> (that's all) >> >> >> >> mrinfo : >> >> 127.0.0.1 (localhost) [version 3.6] : >> 203.255.112.9 -> 0.0.0.0 (local) [1/1/querier/leaf] >> 203.255.112.9 -> 204.70.158.77 (dec3800-2-fddi-1.SanFrancisco.mci.net) >> [1/128/tunnel/down/leaf] >> 203.255.112.9 -> 203.255.113.40 (sosaria.inet.co.kr) >> [1/32/tunnel/down/leaf] >> (it seems right, I think..) >> >> >> mtrace 204.70.158.77 : >> >> Mtrace from 204.70.158.77 to 203.255.112.9 via group 224.2.0.1 >> Querying full reverse path... * switching ro hop-by-hop: >> 0 gam (203.255.112.9) >> -1 * * * Timed out receiving response >> Perhaps no local router has a route for source 204.70.158.77 >> >> Can someone help me? >> Thanks. >> >> >> >> >> >> ------------ >> I.NET Technologies, Inc. (http://www.iworld.net) >> Technical Staff >> >> Mr. Kyungsoon 'Sosarian' Park >> >> email : sosarian@nuri.net >> tel : +82-2-538-6941 >> fax : +82-2-508-5679 >> > > > ------------ I.NET Technologies, Inc. (http://www.iworld.net) Technical Staff Mr. Kyungsoon 'Sosarian' Park email : sosarian@nuri.net tel : +82-2-538-6941 fax : +82-2-508-5679 From list-mgr@ISI.EDU Wed Dec 13 20:23:04 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14971>; Wed, 13 Dec 1995 22:36:10 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14656>; Wed, 13 Dec 1995 22:23:10 -0800 Received: from clone4.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA14649>; Wed, 13 Dec 1995 22:23:07 -0800 Received: from localhost (localhost.mci.net [127.0.0.1]) by clone4.reston.mci.net (8.6.12/8.6.6) with ESMTP id BAA03644; Thu, 14 Dec 1995 01:23:05 -0500 Message-Id: <199512140623.BAA03644@clone4.reston.mci.net> To: mbone Cc: young@mci.net Subject: tunnels again... Date: Thu, 14 Dec 1995 01:23:04 -0500 From: "Jeff Young" <young@mci.net> I've run the comparison of the MCI Routing Registry and the known mbone tunnels (http://www.cl.cam.ac.uk:80/mbone/). The list has been reduced by hand (traceroute) to only those tunnels which cross the mci backbone based on unicast routing, and those sites which may or may not cross the mci backbone but do not allow source routed packets. I started with a list of 268, i'm down to a list of 145 or so. many of these are duplicates (both ends) so lets say that there are 70+ tunnels traversing the mci backbone which don't need to do so. this is non-negligible bandwidth so i'd like to try and alter this situation if i could. With talk of increasing the bandwidth limits on the mbone to 2mb/s - i'd like to first get the duplicate and unnecessary tunnels out of the way. I encourage other providers to do the same as i've seen a number of very interesting traceroutes in the last few hours :). i'll post the list here and will try to contact those on the list based on the web page contact list above. I don't want to be percieved as the newcomer who wants to shake things up, I think that these tunnels were in fact responsible for the successful growth of the mbone - they were the right thing to do at the time. given the scope of the current mbone, i hope that there is no longer a need for tunnels like the one from australia to germany. Some of these tunnels cross naps (where bandwidth is precious) and some cross oceans... The format of the file is: (ROUTE-MAINTAINER-1[tunnel machine]:ROUTE-MAINTAINER-2[tunnel machine]) for example the first entry is a tunnel from Minnesota State (attached to MRnet) to the Department of Computer Science and Communication, Fukuoka JAPAN (attached to WIDE). Jeff Young young@mci.net cut here ________________________________________________________________ (MRNET-MAINT-MCI[coms4.moorhead.msus.edu]:WIDE-MAINT-MCI[nic.karrn.ad.jp]) may be routed thru MCI (SURA[phantom.cam.nist.gov]:DOC-BOULDER[laotzu.bldrdoc.gov]) may be routed thru MCI (unknown[192.41.177.199]:SURA[trivia.CSS.GOV]) may be routed thru MCI (unknown[130.225.214.13]:MERIT-MAINT-MCI[sol.pa.msu.edu]) may be routed thru MCI (SURA[mbone.cise.nsf.gov]:DFN-MNT[mbone.rus.uni-stuttgart.de]) may be routed thru MCI (unknown[192.41.177.197]:SURA[houdini-fddi.gatech.edu]) may be routed thru MCI (SURA[192.231.8.130]:SESQUINET-MAINT-MCI[TEMPEH.SESQUI.NET]) may be routed thru MCI (unknown[132.216.30.10]:JVNCNET[liberty.jvnc.net]) may be routed thru MCI (unknown[128.183.251.129]:SURA[mbone.nsi.nasa.gov]) may be routed thru MCI (unknown[128.183.251.129]:OARNET-MAINT-MCI[mbone.lerc.nasa.gov]) may be routed thru MCI (SURA[mbone.nsi.nasa.gov]:PSC-MAINT-MCI[oday.psc.edu]) may be routed thru MCI (SURA[mbone.nsi.nasa.gov]:AARNET[savoy.aarnet.edu.au]) may be routed thru MCI *(SURA[mbone.nsi.nasa.gov]:BARRNET[numenor.barrnet.net]) may be routed thru MCI *(SURA[mbone.nsi.nasa.gov]:BARRNET[morgul.barrnet.net]) may be routed thru MCI (SURA[orifice.larc.nasa.gov]:unknown[128.183.251.129]) may be routed thru MCI (OARNET-MAINT-MCI[mbone.lerc.nasa.gov]:unknown[128.183.251.129]) may be routed thru MCI (OARNET-MAINT-MCI[mbone.lerc.nasa.gov]:SURA[elk.cerc.wvu.edu]) may be routed thru MCI (SURA[mbone.cmf.nrl.navy.mil]:PSC-MAINT-MCI[pioneer-72.psc.edu]) may be routed thru MCI (BARRNET[royal.stl.nps.navy.mil]:SURA[mbone.sura.net]) may be routed thru MCI (unknown[137.39.43.34]:SURA[navis-1.ie.org]) may be routed thru MCI (unknown[137.39.229.98]:JVNCNET[nb-gw.rutgers.edu]) may be routed thru MCI (SURA[mbone2.nsi.nasa.gov]:LN-MAINT-MCI[mbone.isi.edu]) may be routed thru MCI (SURA[mbone2.nsi.nasa.gov]:NERO-MAINT-MCI[uo-ns-gw.uo.ojgse.edu]) may be routed thru MCI (SURA[mbone2.nsi.nasa.gov]:unknown[198.32.136.24]) may be routed thru MCI (PSC-MAINT-MCI[oday.psc.edu]:SURA[mbone.nsi.nasa.gov]) may be routed thru MCI (PSC-MAINT-MCI[oday.psc.edu]:MERIT-MAINT-MCI[mbone.merit.edu]) may be routed thru MCI (PSC-MAINT-MCI[oday.psc.edu]:NEARNET[mbone1.ner.bbnplanet.net]) may be routed thru MCI (PSC-MAINT-MCI[oday.psc.edu]:NEARNET[noc.near.net]) may be routed thru MCI (PSC-MAINT-MCI[oday.psc.edu]:NEARNET[RASTRO.MIT.EDU]) may be routed thru MCI (PSC-MAINT-MCI[oday.psc.edu]:JVNCNET[AESCHYLUS.DCCS.UPENN.EDU]) may be routed thru MCI (PSC-MAINT-MCI[oday.psc.edu]:unknown[192.5.102.3]) may be routed thru MCI (PSC-MAINT-MCI[oday.psc.edu]:MRNET-MAINT-MCI[pandora-f234.cray.com]) may be routed thru MCI (PSC-MAINT-MCI[oday.psc.edu]:SCINET-MAINT-MCI[nsf-h8r52e.sd.supercomp.org]) may be routed thru MCI (AARNET[savoy.aarnet.edu.au]:SURA[mbone.nsi.nasa.gov]) may be routed thru MCI (unknown[198.17.47.39]:SESQUINET-MAINT-MCI[VINEGAR.SESQUI.NET]) may be routed thru MCI *(BARRNET[morgul.barrnet.net]:SURA[mbone.nsi.nasa.gov]) may be routed thru MCI (unknown[147.6.9.103]:BARRNET[165.213.158.142]) may be routed thru MCI (NWNET-MAINT-MCI[uo-s1/6.len.net]:DFN-MNT[mbone-atm.rus.uni-stuttgart.de]) may be routed thru MCI (AARNET[drugs.syd.dms.CSIRO.AU]:DFN-MNT[mbone.rus.uni-stuttgart.de]) may be routed thru MCI (SURA[cdrn-cpk9-c1.sura.net]:DFN-MNT[verdi.NT.FH-Koeln.DE]) may be routed thru MCI (NEARNET[mbone1.ner.bbnplanet.net]:PSC-MAINT-MCI[oday.psc.edu]) may be routed thru MCI (NEARNET[mbone1.ner.bbnplanet.net]:PSC-MAINT-MCI[oday.psc.edu]) may be routed thru MCI (MERIT-MAINT-MCI[mbone.merit.edu]:PSC-MAINT-MCI[oday.psc.edu]) may be routed thru MCI (MERIT-MAINT-MCI[mbone.merit.edu]:CICNET-NS[tibia.cic.net]) may be routed thru MCI (MERIT-MAINT-MCI[mbone.merit.edu]:JVNCNET[a-wing.jvnc.net]) may be routed thru MCI (JVNCNET[AESCHYLUS.DCCS.UPENN.EDU]:PSC-MAINT-MCI[oday.psc.edu]) may be routed thru MCI (JVNCNET[AESCHYLUS.DCCS.UPENN.EDU]:PREPNET-MAINT-MCI[monster0.telebase.com]) may be routed thru MCI (SCINET-MAINT-MCI[nsf-h8r52e.sd.supercomp.org]:MRNET-MAINT-MCI[pandora-f234.cray.com]) may be routed thru MCI (JVNCNET[a-wing.jvnc.net]:SURA[pop.cc.nih.gov]) may be routed thru MCI (JVNCNET[a-wing.jvnc.net]:MERIT-MAINT-MCI[mbone.merit.edu]) may be routed thru MCI (SESQUINET-MAINT-MCI[VINEGAR.SESQUI.NET]:JVNCNET[140.148.1.16]) may be routed thru MCI (SESQUINET-MAINT-MCI[VINEGAR.SESQUI.NET]:LN-MAINT-MCI[mbone.isi.edu]) may be routed thru MCI (SESQUINET-MAINT-MCI[VINEGAR.SESQUI.NET]:unknown[198.17.47.39]) may be routed thru MCI (SESQUINET-MAINT-MCI[VINEGAR.SESQUI.NET]:CICNET-NS[tibia.cic.net]) may be routed thru MCI (SESQUINET-MAINT-MCI[VINEGAR.SESQUI.NET]:MRNET-MAINT-MCI[noc.msc.net]) may be routed thru MCI (SESQUINET-MAINT-MCI[VINEGAR.SESQUI.NET]:MAINT-AS194[mbone.ucar.edu]) may be routed thru MCI (unknown[198.17.46.57]:CICNET-NS[192.5.200.125]) may be routed thru MCI (BARRNET[MightyDog.Stanford.EDU]:WIDE-MAINT-MCI[ccut.cc.u-tokyo.ac.jp]) may be routed thru MCI (SURA[dragon.iri2.tele.odu.edu]:WIDE-MAINT-MCI[nic.karrn.ad.jp]) may be routed thru MCI (SURA[lex-mp1.sura.net]:CICNET-NS[r-s-hub-1.fnal.gov]) may be routed thru MCI (AARNET[dorado.rp.CSIRO.AU]:DFN-MNT[algol.tm.informatik.uni-frankfurt.de]) may be routed thru MCI (SURA[mbone.sura.net]:BT-MAINT-MCI[pluto.cs.ucl.ac.uk]) may be routed thru MCI (SURA[mbone.sura.net]:unknown[137.39.43.34]) may be routed thru MCI (SURA[mbone.sura.net]:unknown[192.77.156.3]) may be routed thru MCI (SURA[mbone.sura.net]:unknown[198.116.62.5]) may be routed thru MCI (CICNET-NS[davros.acs.ohio-state.edu]:OARNET-MAINT-MCI[oeb4-e0/0.columbus.oar.net]) may be routed thru MCI (CICNET-NS[davros.acs.ohio-state.edu]:MERIT-MAINT-MCI[peggy.aads.net]) may be routed thru MCI (DFN-MNT[sisko.informatik.uni-freiburg.de]:NCREN-MAINT-MCI[mbone.ncren.net]) may be routed thru MCI (unknown[192.187.8.2]:JVNCNET[a-wing.jvnc.net]) may be routed thru MCI (MAINT-AS194[mbone.ucar.edu]:CICNET-NS[141.142.121.32]) may be routed thru MCI (MAINT-AS194[mbone.ucar.edu]:WESTNET-MAINT-MCI[cabal.Colorado.EDU]) may be routed thru MCI (MAINT-AS194[mbone.ucar.edu]:unknown[140.197.30.30]) may be routed thru MCI (CICNET-NS[192.5.200.125]:unknown[198.17.46.57]) may be routed thru MCI (CICNET-NS[192.5.200.125]:SCINET-MAINT-MCI[nwacse-h1r5e.sd.supercomp.org]) may be routed thru MCI (CICNET-NS[192.5.200.125]:SCINET-MAINT-MCI[kiosk3-h3p3e.sd.supercomp.org]) may be routed thru MCI (CICNET-NS[dino.ctd.anl.gov]:MID-MAINT-MCI[147.155.32.31]) may be routed thru MCI (unknown[134.55.20.198]:MID-MAINT-MCI[mbone.scl.ameslab.gov]) may be routed thru MCI (unknown[134.55.20.198]:MID-MAINT-MCI[al-rtr2.ameslab.gov]) may be routed thru MCI (unknown[192.109.251.253]:DFN-MNT[iranoc.ira.uka.de]) may be routed thru MCI (OARNET-MAINT-MCI[oeb3-e0.columbus.oar.net]:CICNET-NS[davros.acs.ohio-state.edu]) may be routed thru MCI (OARNET-MAINT-MCI[oeb3-e0.columbus.oar.net]:CICNET-NS[bedrock.osc.edu]) may be routed thru MCI (DFN-MNT[algol.tm.informatik.uni-frankfurt.de]:OARNET-MAINT-MCI[holstein.cowbox.com]) may be routed thru MCI (DFN-MNT[indi9.mathematik.uni-freiburg.de]:MAINT-AS194[mbone.ucar.edu]) may be routed thru MCI (CICNET-NS[tibia.cic.net]:MERIT-MAINT-MCI[mbone.merit.edu]) may be routed thru MCI (CICNET-NS[tibia.cic.net]:SESQUINET-MAINT-MCI[VINEGAR.SESQUI.NET]) may be routed thru MCI (SURA[mbone.Virginia.EDU]:WIDE-MAINT-MCI[saijo.csi.ad.jp]) may be routed thru MCI (JVNCNET[nb-gw.rutgers.edu]:BARRNET[128.18.62.198]) may be routed thru MCI (MID-MAINT-MCI[ace.mid.net]:BARRNET[utumno.barrnet.net]) may be routed thru MCI (MID-MAINT-MCI[ace.mid.net]:DRA-MAINT-MCI[indigo.dra.com]) may be routed thru MCI (LN-MAINT-MCI[mb160.isi.edu]:SESQUINET-MAINT-MCI[agave.staff.udg.mx]) may be routed thru MCI (unknown[131.178.38.6]:SESQUINET-MAINT-MCI[apollo.telecom.ipn.mx]) may be routed thru MCI (BARRNET[intruder.aa.nps.navy.mil]:WIDE-MAINT-MCI[192.47.180.1]) may be routed thru MCI (CICNET-NS[sgi10.hep.anl.gov]:NWNET-MAINT-MCI[mbone-seattle.nwnet.net]) may be routed thru MCI (SURA[navis-1.ie.org]:WIDE-MAINT-MCI[cconyx01.center.osaka-u.ac.jp]) may be routed thru MCI (WIDE-MAINT-MCI[isindy12.aist-nara.ac.jp]:SURA[iguana.nrl.navy.mil]) may be routed thru MCI (unknown[128.63.2.86]:NEARNET[129.190.22.134]) may be routed thru MCI (CICNET-NS[bedrock.osc.edu]:OARNET-MAINT-MCI[oeb3-e0.columbus.oar.net]) may be routed thru MCI (NEARNET[129.190.22.134]:unknown[128.63.2.86]) may be routed thru MCI (WESTNET-MAINT-MCI[cabal.Colorado.EDU]:MAINT-AS194[mbone.ucar.edu]) may be routed thru MCI (WESTNET-MAINT-MCI[cabal.Colorado.EDU]:MAINT-OMNES[DAFFY.AUSTIN.ASC.SLB.COM]) may be routed thru MCI (WESTNET-MAINT-MCI[cabal.Colorado.EDU]:unknown[138.67.8.72]) may be routed thru MCI (WESTNET-MAINT-MCI[cabal.Colorado.EDU]:unknown[192.225.33.1]) may be routed thru MCI (NWNET-MAINT-MCI[mbone-portland.nwnet.net]:NERO-MAINT-MCI[198.106.198.11]) may be routed thru MCI (SURA[zorro.nrl.navy.mil]:WIDE-MAINT-MCI[foresta.north.ad.jp]) may be routed thru MCI (SESQUINET-MAINT-MCI[agave.staff.udg.mx]:LN-MAINT-MCI[archetype.etext.caltech.edu]) may be routed thru MCI (SESQUINET-MAINT-MCI[harpo.rice.edu]:LN-MAINT-MCI[zzyzxc.aero.org]) may be routed thru MCI (LN-MAINT-MCI[mbone.isi.edu]:SURA[mbone2.nsi.nasa.gov]) may be routed thru MCI (LN-MAINT-MCI[mbone.isi.edu]:SESQUINET-MAINT-MCI[VINEGAR.SESQUI.NET]) may be routed thru MCI (LN-MAINT-MCI[mbone.isi.edu]:CSU[mcast.csu.net]) may be routed thru MCI (OARNET-MAINT-MCI[132.235.1.184]:MCI[tacacs-2.dialnet.ohiou.edu]) may be routed thru MCI (LN-MAINT-MCI[porsche.jpl.nasa.gov]:WESTNET-MAINT-MCI[waikiki.Colorado.EDU]) may be routed thru MCI (MERIT-MAINT-MCI[taipei.eecs.umich.edu]:WESTNET-MAINT-MCI[cabal.Colorado.EDU]) may be routed thru MCI (MCI[tacacs-2.dialnet.ohiou.edu]:OARNET-MAINT-MCI[132.235.1.184]) may be routed thru MCI (SESQUINET-MAINT-MCI[TEMPEH.SESQUI.NET]:SURA[192.231.8.130]) may be routed thru MCI (SESQUINET-MAINT-MCI[TEMPEH.SESQUI.NET]:unknown[129.120.1.39]) may be routed thru MCI (SCINET-MAINT-MCI[nwacse-h1r5e.sd.supercomp.org]:CICNET-NS[192.5.200.125]) may be routed thru MCI (SCINET-MAINT-MCI[kiosk3-h3p3e.sd.supercomp.org]:CICNET-NS[192.5.200.125]) may be routed thru MCI (WIDE-MAINT-MCI[handshake.gw.kyoto-u.ac.jp]:AARNET[mogul3.cc.monash.edu.au]) may be routed thru MCI (WIDE-MAINT-MCI[handshake.gw.kyoto-u.ac.jp]:unknown[133.19.32.60]) may be routed thru MCI (MRNET-MAINT-MCI[noc.msc.net]:LN-MAINT-MCI[malibu.caltech.edu]) may be routed thru MCI (MRNET-MAINT-MCI[noc.msc.net]:CICNET-NS[infectious.micro.umn.edu]) may be routed thru MCI (MRNET-MAINT-MCI[noc.msc.net]:CICNET-NS[ir5.msi.umn.edu]) may be routed thru MCI (MRNET-MAINT-MCI[noc.msc.net]:CICNET-NS[nonabel.geom.umn.edu]) may be routed thru MCI (CICNET-NS[nonabel.geom.umn.edu]:MRNET-MAINT-MCI[noc.msc.net]) may be routed thru MCI (CICNET-NS[alumni.cs.uwm.edu]:RGNET-MAINT-MCI[rah.star-gate.com]) may be routed thru MCI (BARRNET[stu-cisco-isdn.cisco.com]:DFN-MNT[sushi.gate.uni-erlangen.de]) may be routed thru MCI (SURA[ICM2.icp.net]:MAINT-CBM10-MCI[sandy.wustl.edu]) may be routed thru MCI (WIDE-MAINT-MCI[nocs3-fddi.noc.titech.ac.jp]:BARRNET[13.2.12.6]) may be routed thru MCI (SCINET-MAINT-MCI[nsf-h1r52e.sd.supercomp.org]:MRNET-MAINT-MCI[pandora-f234.cray.com]) may be routed thru MCI (AARNET[mqu.gw.CSIRO.AU]:WIDE-MAINT-MCI[nic.karrn.ad.jp]) may be routed thru MCI (DFN-MNT[mbone-atm.rus.uni-stuttgart.de]:unknown[193.58.172.2]) may be routed thru MCI (CICNET-NS[141.142.121.32]:MAINT-AS194[mbone.ucar.edu]) may be routed thru MCI (CICNET-NS[141.142.121.32]:PSC-MAINT-MCI[pioneer-72.psc.edu]) may be routed thru MCI total number of tunnels which may cross MCI = 268 total number of tunnels = 4695 From list-mgr@ISI.EDU Thu Dec 14 02:53:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23503>; Thu, 14 Dec 1995 04:54:50 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23496>; Thu, 14 Dec 1995 04:54:07 -0800 Received: from stone.ucs.indiana.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA23489>; Thu, 14 Dec 1995 04:54:04 -0800 Received: from localhost (localhost [127.0.0.1]) by stone.ucs.indiana.edu (8.6.10/8.7.Alpha.5) with SMTP id HAA19095; Thu, 14 Dec 1995 07:53:51 -0500 Message-Id: <199512141253.HAA19095@stone.ucs.indiana.edu> To: Kyungsoon Park <sosarian@nuri.net> Cc: mbone, robelr@stone.ucs.indiana.edu Subject: Re: mbone problem In-Reply-To: Your message of "Thu, 14 Dec 1995 11:07:55 +0900." <199512140207.LAA16652@sol.nuri.net> Date: Thu, 14 Dec 1995 07:53:50 -0500 From: Allen Robel <robelr@cell-relay.indiana.edu> > tunnel 203.255.112.9 204.70.158.77 metric 1 treshold 128 rate_limit 500 > tunnel 203.255.112.9 203.255.113.40 metric 1 treshold 32 rate_limit 500 Hi Kyungsoon, If you copied the above out of your mrouted.conf file directly, you've got two typos in that "treshold" should be "threshold" You might try starting mrouted in debug mode: % mrouted -d This'll allow you to view what happens as it starts up. regards, allen From list-mgr@ISI.EDU Thu Dec 14 05:04:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23849>; Thu, 14 Dec 1995 05:08:35 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23832>; Thu, 14 Dec 1995 05:08:07 -0800 Received: from cythera.unb.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA23825>; Thu, 14 Dec 1995 05:08:01 -0800 Received: from cythera.unb.ca (cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.6.12/8.6.5) with SMTP id JAA06876; Thu, 14 Dec 1995 09:04:14 -0400 Date: Thu, 14 Dec 1995 09:04:14 -0400 (AST) From: "Dwight E. Spencer" <spencer@unb.ca> To: Kyungsoon Park <sosarian@nuri.net> Cc: Jeff Young <young@mci.net>, mbone Subject: Re: mbone problem In-Reply-To: <199512140604.PAA29871@sol.nuri.net> Message-Id: <Pine.SOL.3.91.951214090242.895N-100000@cythera.unb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 14 Dec 1995, Kyungsoon Park wrote: > >4.) would you like to go ahead and upgrade to mrouted 3.8? > > Isn't it running on mrouted 3.5? > It is our Web Server. so it's difficult to shut down the system. The upgrade from 3.5 mrouted to 3.8 mrouted for solaris is very painless, and I don't believe requires a reboot. You simply kill the old mrouted, download the new mrouted binary (3.8) into /usr/multicast/, and start it back up. Those that know will correct me if I am mistaken. dwight s. ---------------------------------------------------------------------------- Dwight E. Spencer Canada's Community Access Network eMail: spencer@unb.ca, Server Administrator UNB, Fredericton, NB, Canada Phone: +1 506 447 3153 Url: http://cnet.unb.ca/cspace/staff/dspencer/ From list-mgr@ISI.EDU Thu Dec 14 03:11:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23921>; Thu, 14 Dec 1995 05:12:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23896>; Thu, 14 Dec 1995 05:12:03 -0800 Received: from aspen.uml.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA23887>; Thu, 14 Dec 1995 05:12:00 -0800 Received: by woods.uml.edu (MX V4.1 VAX) id 20; Thu, 14 Dec 1995 08:11:56 EST Date: Thu, 14 Dec 1995 08:11:55 EST From: THACH@woods.uml.edu To: MBONE X-Vmsmail-To: MBONE@ISI.EDU Message-Id: <0099AD84.4BC01C20.20@woods.uml.edu> Subject: Please unsubcribe Please unsubcribe, Thnks From list-mgr@ISI.EDU Thu Dec 14 03:28:08 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24206>; Thu, 14 Dec 1995 05:29:18 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24197>; Thu, 14 Dec 1995 05:28:27 -0800 Received: from dia.dia.mil by venera.isi.edu (5.65c/5.61+local-22) id <AA24188>; Thu, 14 Dec 1995 05:28:25 -0800 Received: from dia (localhost [127.0.0.1]) by dia.dia.mil (8.7/8.7) with SMTP id IAA00579; Thu, 14 Dec 1995 08:28:08 -0500 (EST) Sender: crobson@dia.dia.mil Message-Id: <30D02668.2FD5@dia.dia.mil> Date: Thu, 14 Dec 1995 08:28:08 -0500 From: Chris Robson <crobson@dia.dia.mil> Organization: DIA X-Mailer: Mozilla 2.0b2 (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: vat@ee.lbl.gov Cc: mbone Subject: Problem with VAT and Solaris2.4 X-Url: http://www-nrg.ee.lbl.gov/vat/#feedback Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm running VAT on a Sparc20 with openwin/MOTIF(Sun release) Xwindow server. The window manager I'm using is FVWM. When I execute VAT I get the following error and NO vat execution: vat: "vat_main": bad option "colormodel": must be appname Any ideas as to what is causing this and way vat doesnt run. tks...chris From list-mgr@ISI.EDU Wed Dec 14 00:26:16 1994 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29269>; Thu, 14 Dec 1995 08:26:35 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29247>; Thu, 14 Dec 1995 08:26:10 -0800 Received: from aimnet.com (mailhub1.aimnet.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA29237>; Thu, 14 Dec 1995 08:26:08 -0800 Received: from [204.118.160.13] (dial-bel1-13.iway.aimnet.com [204.118.160.13]) by aimnet.com (8.7.1/8.7.1) with SMTP id IAA17935 for <mbone@ISI.EDU>; Thu, 14 Dec 1995 08:27:04 -0800 (PST) Message-Id: <v02130502ab14cc456494@[204.118.160.28]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Dec 1994 08:26:16 -0800 To: mbone From: tim@aimnet.com (Tim Payne) Subject: mBone may be flooded Do we all know about CVP Connectix Video Phone? Connectix is about to flood the market with there own little mbone viewer <phone>. What does this mean? Is it somthing we want ? It is not somthing we can stop. Tim Payne May The Force Be With You From list-mgr@ISI.EDU Thu Dec 14 01:00:58 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01205>; Thu, 14 Dec 1995 09:01:39 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01176>; Thu, 14 Dec 1995 09:01:03 -0800 Received: from pohjola.nersc.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA01167>; Thu, 14 Dec 1995 09:01:00 -0800 Received: by pohjola.nersc.gov (8.6.12/esnet-1) id JAA04606; Thu, 14 Dec 1995 09:00:58 -0800 Date: Thu, 14 Dec 1995 09:00:58 -0800 From: ari@es.net (Ari Ollikainen) Message-Id: <199512141700.JAA04606@pohjola.nersc.gov> To: mbone, tim@aimnet.com Subject: Re: mBone may be flooded Content-Length: 1299 >From list-mgr@ISI.EDU Thu Dec 14 08:35 PST 1995 >Mime-Version: 1.0 >Date: Wed, 14 Dec 1994 08:26:16 -0800 >To: mbone@ISI.EDU >From: tim@aimnet.com (Tim Payne) >Subject: mBone may be flooded > >Do we all know about CVP Connectix Video Phone? See http://www.pcworld.com/connectix/vpchoice.html >Connectix is about to flood the market with there own little mbone viewer ><phone>. >What does this mean? It means that Connectix thinks they can set a standard at a low price point. It also means that the Mac version is based on Apple's QuickTime conferencing and is currently NOT interoperable with the Windows version. It means that ANYONE can play... ~$50 if you already have a video input device. >Is it somthing we want ? Depends largely on the perceived needs. Who are *you* or *we* to decide what *others* can have? >It is not somthing we can stop. > For sure. Ari@ES.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 ~~RECOM Technologies Inc.~~ From list-mgr@ISI.EDU Thu Dec 14 07:07:49 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01467>; Thu, 14 Dec 1995 09:08:06 -0800 Received: from MAYTAG.GRAPHICS.CORNELL.EDU by venera.isi.edu (5.65c/5.61+local-22) id <AA01456>; Thu, 14 Dec 1995 09:08:01 -0800 Received: from localhost by maytag.graphics.cornell.edu; (5.65/1.1.8.2/07Nov94-0649PM) id AA25728; Thu, 14 Dec 1995 12:07:53 -0500 Message-Id: <9512141707.AA25728@maytag.graphics.cornell.edu> X-Mailer: exmh version 1.6gamma 3/31/95 To: mbone-na Subject: Re: Unadvertised sessions In-Reply-To: Your message of "Wed, 13 Dec 95 15:48:19 EST." <199512132048.PAA04286@stone.ucs.indiana.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Dec 95 12:07:49 -0500 From: Mitch Collinsworth <mkc@graphics.cornell.edu> X-Mts: smtp >>I've noticed recently that the contents of sd have been looking rather >>sparse; this is in direct contrast to all of the traffic this list has shown >>in relation to sessions currently underway and planned for the immediate >>future. > >I've noticed the same thing. [...] I've actually been seeing a somewhat opposite problem here. I'm seeing all the sessions in sd ok, but not hearing the participants in those sessions. In particular I got nothing all last week from the IETF sessions and this week I'm getting nothing from the WWW sessions. I got the IETF whiteboards ok, but no audio or video. I *did* see the other IETF listeners and could hear them speak now and then when they had something to say. I just didn't get anything from the IETF site itself, except for whiteboards. -Mitch From list-mgr@ISI.EDU Fri Dec 15 11:10:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01828>; Thu, 14 Dec 1995 09:12:49 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01776>; Thu, 14 Dec 1995 09:12:08 -0800 Received: from shiva.race.u-tokyo.ac.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA01765>; Thu, 14 Dec 1995 09:12:02 -0800 Received: from cygnus.race.u-tokyo.ac.jp (cygnus.race.u-tokyo.ac.jp [157.82.76.30]) by shiva.race.u-tokyo.ac.jp (8.6.12+2.5W/3.4W-95110518) with ESMTP id CAA13699; Fri, 15 Dec 1995 02:10:42 +0900 Received: from localhost by cygnus.race.u-tokyo.ac.jp (8.6.8+2.4Wb/3.4W3-race) id CAA15869; Fri, 15 Dec 1995 02:10:14 +0900 Message-Id: <199512141710.CAA15869@cygnus.race.u-tokyo.ac.jp> To: mbone Cc: tim@aimnet.com (Tim Payne) Subject: Re: mBone may be flooded In-Reply-To: Your message of "Wed, 14 Dec 1994 08:26:16 PST." <v02130502ab14cc456494@[204.118.160.28]> Date: Fri, 15 Dec 1995 02:10:14 +0900 From: Koji ANDO <chutzpah@race.u-tokyo.ac.jp> Hello. Tim said: > Do we all know about CVP Connectix Video Phone? > Connectix is about to flood the market with there own little mbone viewer > <phone>. Do Microsoft TCP/IP-32 or MacTCP support IP multicast? FYI, see http://www.pcworld.com/connectix/vpchoice.html -------------------------------------------------------------------- Koji ANDO <chutzpah@race.u-tokyo.ac.jp> Stoppt die Atomtests! RACE, the Univ. of Tokyo Ich protestire gegen die Atomtests. URL: http://www.race.u-tokyo.ac.jp/~chutzpah/ Phone: +81-3-5453-5882 FAX: +81-3-3467-0648 From list-mgr@ISI.EDU Thu Dec 14 02:26:05 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05916>; Thu, 14 Dec 1995 10:26:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05897>; Thu, 14 Dec 1995 10:26:19 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA05890>; Thu, 14 Dec 1995 10:26:17 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id KAA00354; Thu, 14 Dec 1995 10:26:06 -0800 Message-Id: <199512141826.KAA00354@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Brad Parker <brad@american.com> Cc: mbone, Jim Lowe <james@miller.cs.uwm.edu> Subject: Re: vic 2.7x for freebsd binaries? In-Reply-To: Your message of "Wed, 13 Dec 1995 20:25:31 EST." <199512140125.UAA01322@mozart.american.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Dec 1995 10:26:05 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Howdy, On the FreeBSD side of things , Jim Lowe is tracking vic2.7x . Him and Mark Tinguely also wrote a driver for the Matrox Meteor PCI video capture board. Both vic and nv at least the FreeBSD version support the matrox video captuer board. And Yes, it works quite well 8) I have a multimedia mailing list for FreeBSD related stuff . If you like you can join: mail majordomo@star-gate.com subscribe multimedia >>> Brad Parker said: > > Sorry, if this is inappropriate - I was wondering if anyone was tracking > vic 2.7 progress and building it for freebsd 2.1. > > I'd like to try running vic on freebsd and the only 2.7 binaries I can > find are for Solaris, SunOS, etc... Is it that the performance is so > bad that no one does it? (I understood that vic with the Meteor card was > 'ok' - without this card is video hopeless?) > > -brad > From list-mgr@ISI.EDU Thu Dec 14 08:29:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06174>; Thu, 14 Dec 1995 10:32:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06159>; Thu, 14 Dec 1995 10:31:43 -0800 Received: from davinci.gmu.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA06146>; Thu, 14 Dec 1995 10:31:38 -0800 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id NAA15296; Thu, 14 Dec 1995 13:29:06 -0500 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199512141829.NAA15296@davinci.gmu.edu> Subject: Re: mBone may be flooded To: chutzpah@race.u-tokyo.ac.jp (Koji ANDO) Date: Thu, 14 Dec 1995 13:29:02 -0500 (EST) Cc: mbone, tim@aimnet.com In-Reply-To: <199512141710.CAA15869@cygnus.race.u-tokyo.ac.jp> from "Koji ANDO" at Dec 15, 95 02:10:14 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 871 Yes, MS TCP/IP Stacks support IP MUlticast. I believe Apple has a version as well. Michael > > Hello. > > Tim said: > > Do we all know about CVP Connectix Video Phone? > > Connectix is about to flood the market with there own little mbone viewer > > <phone>. > > Do Microsoft TCP/IP-32 or MacTCP support IP multicast? > > FYI, see http://www.pcworld.com/connectix/vpchoice.html > > -------------------------------------------------------------------- > Koji ANDO <chutzpah@race.u-tokyo.ac.jp> Stoppt die Atomtests! > RACE, the Univ. of Tokyo Ich protestire gegen die Atomtests. > URL: http://www.race.u-tokyo.ac.jp/~chutzpah/ > Phone: +81-3-5453-5882 FAX: +81-3-3467-0648 > -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From list-mgr@ISI.EDU Thu Dec 14 10:39:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16922>; Thu, 14 Dec 1995 12:40:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16899>; Thu, 14 Dec 1995 12:40:03 -0800 Received: from sifon.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA16892>; Thu, 14 Dec 1995 12:40:01 -0800 Received: from junkie.tanstafl.ca (dialup144.cyberus.ca [205.208.30.144]) by sifon.CC.McGill.CA (8.6.12/8.6.6) with SMTP id PAA28000; Thu, 14 Dec 1995 15:40:33 -0500 Date: Thu, 14 Dec 1995 15:39:36 -0500 (EST) From: Ian Duncan <id@cc.mcgill.ca> X-Sender: id@junkie.tanstafl.ca To: Michael Benson <mbenson@davinci.gmu.edu> Cc: Koji ANDO <chutzpah@race.u-tokyo.ac.jp>, mbone, tim@aimnet.com Subject: Re: mBone may be flooded In-Reply-To: <199512141829.NAA15296@davinci.gmu.edu> Message-Id: <Pine.BSF.3.91.951214153206.16687A-100000@junkie.tanstafl.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 14 Dec 1995, Michael Benson wrote: > Yes, MS TCP/IP Stacks support IP MUlticast. I believe Apple has a version > as well. The OpenTransport for Macintosh claims to support multicast. Until Apple resolves some basic bugs it isn't going to see wide use. Microsoft has multicast in the 32 (W95 & NT) stacks but reports are it there's no control for TTL (default is 1) which for use is a definite lose. For the MBONE I guess it's a short term win, they can watch but not source. Other winsock implementations may have better support. Then there's that small question of interoperable applications. -- Ian Duncan, Invited Researcher C.I.T.I., Industry Canada phone: (514)973-5834 email: id@CITI.DOC.CA From list-mgr@ISI.EDU Thu Dec 14 05:14:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19038>; Thu, 14 Dec 1995 13:15:21 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18995>; Thu, 14 Dec 1995 13:14:14 -0800 Received: from aimnet.com (mailhub1.aimnet.com) by venera.isi.edu (5.65c/5.61+local-22) id <AA18986>; Thu, 14 Dec 1995 13:14:11 -0800 Received: from [204.118.83.211] ([204.118.83.211]) by aimnet.com (8.7.1/8.7.1) with SMTP id NAA06606 for <mbone@ISI.EDU>; Thu, 14 Dec 1995 13:15:10 -0800 (PST) Message-Id: <v02130509acf64383590d@[204.118.83.211]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Dec 1995 13:14:11 -0800 To: mbone From: tim@aimnet.com (Tim Payne) Subject: Mbone may be flooded I hear that the CVP won't support nv or vic so maybe it won't be all that bad. 8) Tim Payne VAR Channel Manager 408-567-3800x154 tim@aimnet.com www.aimnet.com From list-mgr@ISI.EDU Thu Dec 14 05:43:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20456>; Thu, 14 Dec 1995 13:44:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20439>; Thu, 14 Dec 1995 13:44:07 -0800 Received: from camel.jpl.nasa.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA20431>; Thu, 14 Dec 1995 13:44:05 -0800 Received: from aeolus (aeolus.jpl.nasa.gov [137.79.7.22]) by camel.jpl.nasa.gov (8.6.10/8.6.6) with ESMTP id NAA19758 for <@camel:mbone@isi.edu>; Thu, 14 Dec 1995 13:43:57 -0800 Received: by aeolus (940816.SGI.8.6.9/920502.SGI.AUTO) for mbone@isi.edu id NAA08614; Thu, 14 Dec 1995 13:43:57 -0800 Date: Thu, 14 Dec 1995 13:43:57 -0800 From: elson@aeolus.jpl.nasa.gov (Lee Elson) Message-Id: <199512142143.NAA08614@aeolus> To: mbone Subject: vic question I'm running vic2.7a29 on an SGI IRIS Extreme and getting poor transmit performance (Galileo Video). The best frame rate I can muster is about 3 f.p.s. with 'quality' turned down low. This produces about 50 kb/s with the rate control pushed up as high as possible. Any ideas on how to improve this? Saw much higher frame rates at the IETF a week or so ago. From list-mgr@ISI.EDU Thu Dec 14 05:53:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20951>; Thu, 14 Dec 1995 13:56:37 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20906>; Thu, 14 Dec 1995 13:55:27 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA20897>; Thu, 14 Dec 1995 13:55:25 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15376(3)>; Thu, 14 Dec 1995 13:54:16 PST Received: by crevenia.parc.xerox.com id <177478>; Thu, 14 Dec 1995 13:54:06 -0800 From: Bill Fenner <fenner@parc.xerox.com> To: mbone Subject: Black holes caused by aggregation Message-Id: <95Dec14.135406pst.177478@crevenia.parc.xerox.com> Date: Thu, 14 Dec 1995 13:53:51 PST [This list is growing at an alarming rate!] As I described in a message to the MBONE mailing list in October, older versions of mrouted can't handle certain types of routes. Injecting both a general route (e.g. 128.118/16) and more-specific routes (e.g. 128.118.4/24) will cause black holes for traffic originating from hosts that are covered by the more specific routes. In addition, injecting a CIDR route will also cause black holes. What follows is a list of networks that are affected by this problem. Two scenarios that I know of that cause this situation are: a) A router is injecting summary routes but it is not in the right place in the topology to attempt to summarize. The solutions in this case are: 1) Configure whatever router is injecting the general route to only inject specific routes 2) Configure your topology in such a way that you can configure a single router to inject a single general route without requiring any more-specific routes. b) An mrouted is running on a machine which has a misconfigured interface netmask. This generally happens in places when a router is configured for proxy ARP (see RFC1027) so the interface netmask does not actually describe the netmask of the subnet the router is connected to. The solution is either to configure the interface's netmask properly, or to use the 'phyint netmask' command in your mrouted.conf (version 3.5 and up). In some cases, it is not easy to locate the router that is injecting the general route. The best way to find it is to use 'mtrace'; if you mtrace to a subnet that is covered by the general route but not one of the more specific routes (e.g. 10.255.255.254 if the general route is 10/8 and there is no 10.255/16 route) you should be able to find the router that is advertising the general route. It may not even be part of your own infrastructure; it may be your provider's router, or even a router that belongs to another customer of the same provider (I have seen both). Note that the 3.6 mtrace has a bug in hop-by-hop mode which may terminate the trace too early; try (potentially using -M -t 127) to get a full reverse path trace to locate the culprit. This situation will cease to cause black holes when the whole MBONE is running recent routing software, but until that time, it is best to avoid the possibility altogether. Bill University of California (NET-UCB-ETHER) EECS Division 573 Evans Hall Berkeley, CA 94720 128.32.226/24 is covered by 128.32/16 orwegian Telecommunications Administration (NET-NTANET) P.O. Box 83 N-2007 Kjeller NORWAY 128.39.88/23 is covered by 128.39/16 128.39.157/24 is covered by 128.39/16 128.39.197/24 is covered by 128.39/16 SURANET (NET-SURA-B) 128.167.1/24 is covered by 128.167/16 128.167.254/24 is covered by 128.167/16 University of Illinois, CCSO (NET-UIUC-CAMPUS-B) 1304 West Springfield Avenue Urbana, IL 61801-2910 US 128.174.212.0/25 is covered by 128.174/16 128.174.240/24 is covered by 128.174/16 University of Karlsruhe (NET-LINK) Computer Science Department Zirkel 2 D-7500 Karlsruhe GERMANY 129.13.3/24 is covered by 129.13/16 129.13.81/24 is covered by 129.13/16 129.13.170/24 is covered by 129.13/16 SWITCH Teleinformatics Services (NET-SWITCH) Limmatquai 138 CH-8001 Zurich SWITZERLAND 130.59.10/24 is covered by 130.59/16 RedIRIS (NET-IRIS) RedIRIS/CSIC Serrano 142 28006 Madrid SPAIN 130.206.0/23 is covered by 130.206/16 130.206.16/24 is covered by 130.206/16 130.206.34/24 is covered by 130.206/16 130.206.35/24 is covered by 130.206/16 130.206.36/24 is covered by 130.206/16 130.206.45/24 is covered by 130.206/16 130.206.46/24 is covered by 130.206/16 130.206.47/24 is covered by 130.206/16 130.206.48/24 is covered by 130.206/16 130.206.63/24 is covered by 130.206/16 130.206.121/24 is covered by 130.206/16 130.206.122/24 is covered by 130.206/16 130.206.123/24 is covered by 130.206/16 130.206.124/24 is covered by 130.206/16 130.206.125/24 is covered by 130.206/16 130.206.126/24 is covered by 130.206/16 130.206.193/24 is covered by 130.206/16 McGill University (NET-MCGILL-CA) Computing Centre 805 Sherbrooke Street West Montreal, Quebec H3A 2K6 CANADA 132.206.3/24 is covered by 132.206/16 132.206.141/24 is covered by 132.206/16 Hokkaido University (NET-HUNOS) 3-1-1, Minatomachi Hakodate 041 JAPAN 133.50.16/24 is covered by 133.50/16 133.50.80/24 is covered by 133.50/16 133.50.82/24 is covered by 133.50/16 UUNET (NET-UUNET-WAN) 3110 Fairview Park Drive, Suite 570 Falls Church, VA 22032 137.39.43.32/30 is covered by 137.39/16 137.39.170.36/30 is covered by 137.39/16 137.39.229.96/27 is covered by 137.39/16 137.39.246.96/30 is covered by 137.39/16 Telecom Paris (NET-FNET-ESNET) Centre de Calcul 46, rue Barrault 75634 Paris Cedex 13 FRANCE 137.194.2/23 is covered by 137.194/16 137.194.34/23 is covered by 137.194/16 137.194.42/23 is covered by 137.194/16 137.194.98/23 is covered by 137.194/16 137.194.160/23 is covered by 137.194/16 The Little Garden (NET-LITTLEGARDEN) Box 410923 San Francisco, CA 94141-0923 140.174.2/24 is covered by 140.174/16 140.174.97.0/25 is covered by 140.174/16 IANA (IANA-BBLK-RESERVED) Internet Assigned Numbers Authority Information Sciences Institute University of Southern California 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 172.31.1/24 is covered by 172.31/16 172.31.9/24 is covered by 172.31/16 Royal Institute of Technology (NET-NORDUNET-BACKBONE) NADA/KTH S-100 44 Stockholm SWEDEN 192.36.148.192/28 is covered by 192.36.148/24 Fraunhofer Institut fuer graphische Datenverarbeitung, Darmstadt (NETBLK-FHGIGDP) Fraunhofer-Strasse 1 D-76131 Karlsruhe Germany DE 192.67.203.128/27 is covered by 192.67.203/24 192.67.203.192/27 is covered by 192.67.203/24 Academic and Research Network of Slovenia (NET-ARNES-NET) 61 111 Ljubljana SLOVENIA 193.2.1.32/28 is covered by 193.2.1/24 inetnum: 193.124.156.0 - 193.124.159.0 netname: IBRAE descr: Nuclear Safety Institute descr: Moscow country: RU admin-c: Marina A. Ignatieva tech-c: Marina A. Ignatieva changed: olg@ussr.eu.net 930627 source: RIPE 193.124.156/22 is a CIDR route inetnum: 193.124.160.0 - 193.124.167.0 netname: BINP-NET descr: Budker Institute of Nuclear Physics descr: Siberian Branch of Russian Academy of Sciences descr: Novosibirsk, Russia country: RU admin-c: SDB1-RIPE tech-c: SPK1-RIPE rev-srv: inp.nsk.su rev-srv: nikhefh.nikhef.nl notify: belov@inp.nsk.su changed: belov@nsc.ru 951201 source: RIPE 193.124.160/21 is a CIDR route inetnum: 193.124.208.0 - 193.124.223.0 netname: NSUNET descr: Novosibirsk State University Network descr: Novosibirsk country: RU admin-c: Vadim V. Gorodilov admin-c: Valery V. Serebryansky tech-c: Evgeny N. Faddeenkov changed: olg@ussr.eu.net 930808 source: RIPE 193.124.208/20 is a CIDR route inetnum: 193.125.0.0 netname: SIBNET descr: Novosibirsk State Tecnical University descr: Russia country: RU admin-c: Vladislav V. Denisenko tech-c: Vladislav V. Denisenko changed: olg@ussr.eu.net 931022 source: RIPE 193.125.0/21 is a CIDR route inetnum: 193.125.232.0 - 193.125.239.0 netname: SIBNET descr: Novosibirsk State Tecnical University descr: Russia country: RU admin-c: Vladislav V Denisenko tech-c: Vladislav V Denisenko changed: vlad@nstu.nsk.su 940516 source: RIPE 193.125.232/21 is a CIDR route University of Stuttgart (NET-RUS-MBONE) Computer Center Allmandring 30 D-7000 Stuttgart 80 GERMANY 193.196.152.248/30 is covered by 193.196.152/24 Lebedev Physical Inst. (NET-FIAN) High Energy Physics Department Moscow B-333 SU 193.232.68/23 is a CIDR route Moscow State University (NETBLK-MSUNET) NETBLK-MSUNET 193.232.112.0 - 193.232.127.0 inetnum: 193.232.112.0 - 193.232.127.0 netname: MSUNET descr: Moscow State University descr: Lenin's Hills, Moscow, Russia country: RU admin-c: VAV1-RIPE tech-c: AES1-RIPE tech-c: KMS1-RIPE rev-srv: ns.phys.msu.su rev-srv: ns2.nic.fr rev-srv: ns.radio-msu.net notify: noc@ns.msu.ru mnt-by: AS2848-MNT changed: aes@phys.msu.su 941220 changed: kent@ns.msu.ru 950628 source: RIPE 193.232.112/20 is a CIDR route inetnum: 193.232.252.0 - 193.232.253.0 netname: KC-NET descr: Kazan Civil Network descr: Kazan, Russia country: RU admin-c: TY1-RIPE tech-c: PI2-RIPE rev-srv: ns2.ksu.ras.ru rev-srv: ns.ksu.ras.ru rev-srv: nss.ras.ru notify: noc@ksu.ras.ru mnt-by: AS3325-MNT changed: paul@ksu.ras.ru 951017 source: RIPE 193.232.252/23 is a CIDR route inetnum: 193.233.0.0 netname: FREENET-NOC-LAN descr: FREEnet Network Operations Center country: RU admin-c: EM217 tech-c: DIS2 notify: em@free.net mnt-by: AS2895-MNT changed: hostmaster@free.net 950328 source: RIPE 193.233/16 is a CIDR route inetnum: 194.67.64.0 - 194.67.65.0 netname: PHERLAN descr: Yerevan Physics Institute descr: Yerevan country: AM admin-c: Michael S Cordonsky tech-c: Emin R Gabrielian changed: mcordi@erphy.armenia.su 940712 source: RIPE 194.67.64/18 is a CIDR route inetnum: 194.85.32.0 - 194.85.34.0 netname: RUNNET descr: Federal Node RUNNet in IFMO descr: (Institute of Fine Mechanics and Optics) descr: St.Petersburg country: RU admin-c: VNV1-RIPE tech-c: YVG1-RIPE changed: aes@phys.msu.su 950226 source: RIPE 194.85.32/20 is a CIDR route inetnum: 194.85.104.0 - 194.85.111.0 netname: PRESIDIUM-RAS-LAN descr: Information and Publishing Department descr: Mathematical Branch descr: Russian Academy of Sciences country: RU admin-c: NR5 tech-c: AG20 tech-c: Eugene Mamchits tech-c: Mike Zizcenko rev-srv: ns.ras.ru rev-srv: nss.ras.ru rev-srv: nss.msu.ru notify: noc@ns.ras.ru mnt-by: AS3058-MNT changed: eugin@ips.ras.ru 951004 source: RIPE 194.85.104/21 is a CIDR route inetnum: 194.85.116.0 - 194.85.119.0 netname: GNET descr: Garant-Service descr: Phys. department, MSU descr: Lebedeva St., Leninskie Gory descr: Moscow 119899, Russia country: RU admin-c: AIG1-RIPE tech-c: AES1-RIPE changed: aes@phys.msu.su 951016 changed: lsy@kiae.su 951020 source: RIPE 194.85.116/22 is a CIDR route inetnum: 194.85.240.0 - 194.85.247.0 netname: KC-NET descr: Kazan Civil Network descr: Kazan, Russia country: RU admin-c: TY1-RIPE tech-c: PI2-RIPE rev-srv: ns2.ksu.ras.ru rev-srv: ns.ksu.ras.ru rev-srv: nss.ras.ru notify: noc@ksu.ras.ru mnt-by: AS3325-MNT changed: paul@ksu.ras.ru 951016 source: RIPE 194.85.240/21 is a CIDR route inetnum: 194.88.0.0 - 194.88.7.0 netname: EMNET-FSU descr: Information and Publishing Department descr: Mathematical Branch descr: Russian Academy of Sciences country: RU admin-c: NR5 tech-c: AG20 tech-c: Eugene Mamchits tech-c: Mike Zizcenko rev-srv: ns.ras.ru rev-srv: nss.ras.ru rev-srv: nss.msu.ru notify: noc@ns.ras.ru mnt-by: AS3058-MNT changed: eugin@ips.ras.ru 951004 source: RIPE 194.88.0/21 is a CIDR route inetnum: 194.190.136.0 netname: SSU-SAMARANET descr: Association of Samara Regional Information Space descr: Samara State University country: RU admin-c: LT17-RIPE tech-c: AS141-RIPE tech-c: AS142-RIPE changed: root@ssu.ras.ru 951108 changed: prost@newcom.kiae.su 951116 source: RIPE 194.190.136/21 is a CIDR route inetnum: 194.190.160.0 - 194.190.167.0 netname: SU-IHEP descr: Institute for High Energy Physics country: RU admin-c: LY22 tech-c: LY22 rev-srv: ns.ihep.su rev-srv: dxmon.cern.ch changed: egoshin@ihep.su 950706 changed: lsy@kiae.su 950821 changed: inaddr@ripe.net 950906 source: RIPE 194.190.160/21 is a CIDR route inetnum: 194.190.176.0 - 194.190.191.0 netname: SANDYNET descr: Scientific Information descr: Agency SANDY Network descr: N.Novgorod country: RU admin-c: ALS1-RIPE tech-c: IAM1-RIPE tech-c: DAE1-RIPE changed: im@sandy.sci-nnov.ru 950925 changed: lsy@kiae.su 951023 source: RIPE 194.190.176/20 is a CIDR route Hawaii OnLine (NETBLK-SPRINT-CC5E77) SPRINT-CC5E77 204.94.112.0 - 204.94.119.0 204.94.112/21 is a CIDR route Pacific Telecommunications Council (NET-ALOHANET-PTC) 2454 S. Beretania Street, Suite 302 Honolulu, HI 96826 US 204.94.248/23 is a CIDR route Hawaii OnLine (NETBLK-SPRINT-CC77FF) SPRINT-CC77FF 204.119.248.0 - 204.119.255.0 204.119.248/21 is a CIDR route Advanced Network & Services, Inc. (NETBLK-ANS-C-BLOCK3) 100 Clearbrook Road Elmsford, NY 10523 204.148.104/21 is a CIDR route Hawaii On-Line (NETBLK-HAWAIIOL-NET) HAWAIIOL-NET204.149.160.0 - 204.149.167.0 204.149.160/21 is a CIDR route Hawaii OnLine (NETBLK-SPRINT-CCB6EF) SPRINT-CCB6EF 204.182.232.0 - 204.182.239.0 204.182.232/21 is a CIDR route Pacific Information eXchange, Inc.ASN 5754 (NETBLK-PIXINET-BLK1) 1142 Auahi St. Honolulu, HI 96814 206.127.224/20 is a CIDR route From list-mgr@ISI.EDU Thu Dec 14 06:07:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21627>; Thu, 14 Dec 1995 14:08:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21603>; Thu, 14 Dec 1995 14:08:15 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA21590>; Thu, 14 Dec 1995 14:08:11 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15038(7)>; Thu, 14 Dec 1995 14:07:40 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 14 Dec 1995 14:07:27 -0800 To: "Jeff Young" <young@mci.net> Cc: mbone, deering@parc.xerox.com Subject: Re: tunnels again... In-Reply-To: young's message of Wed, 13 Dec 95 22:23:04 -0800. <199512140623.BAA03644@clone4.reston.mci.net> Date: Thu, 14 Dec 1995 14:07:16 PST Sender: Steve Deering <deering@parc.xerox.com> From: Steve Deering <deering@parc.xerox.com> Message-Id: <95Dec14.140727pst.75270@digit.parc.xerox.com> > I don't want to be percieved as the newcomer who wants to shake > things up,... In case there is any such perception, I'd like to clear that up. Jeff is doing a great job of rationalizing the MBone topology, and has the full support of us MBone "oldtimers". Steve From list-mgr@ISI.EDU Thu Dec 14 12:57:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24198>; Thu, 14 Dec 1995 14:59:36 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA24169>; Thu, 14 Dec 1995 14:59:00 -0800 Received: from cerc.wvu.edu (cathedral.cerc.wvu.edu) by venera.isi.edu (5.65c/5.61+local-22) id <AA24161>; Thu, 14 Dec 1995 14:58:57 -0800 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA14504; Thu, 14 Dec 95 17:58:02 EST Received: by elk (5.x//ident-1.0) id AA19937; Thu, 14 Dec 1995 17:57:59 -0500 Date: Thu, 14 Dec 1995 17:57:57 -0500 (EST) From: "Todd L. Montgomery" <tmont@cerc.wvu.edu> Subject: Re: mBone may be flooded To: Ian Duncan <id@cc.mcgill.ca> Cc: Michael Benson <mbenson@davinci.gmu.edu>, Koji ANDO <chutzpah@race.u-tokyo.ac.jp>, mbone, tim@aimnet.com In-Reply-To: <Pine.BSF.3.91.951214153206.16687A-100000@junkie.tanstafl.ca> Message-Id: <Pine.3.89.9512141737.A19105-0100000@elk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 14 Dec 1995, Ian Duncan wrote: > On Thu, 14 Dec 1995, Michael Benson wrote: > > > Yes, MS TCP/IP Stacks support IP MUlticast. I believe Apple has a version > > as well. > > The OpenTransport for Macintosh claims to support multicast. Until Apple > resolves some basic bugs it isn't going to see wide use. Microsoft has > multicast in the 32 (W95 & NT) stacks but reports are it there's no > control for TTL (default is 1) which for use is a definite lose. For the > MBONE I guess it's a short term win, they can watch but not source. Other > winsock implementations may have better support. One of the RMP users was kind enough to point out to me that the way to get TTLs to work under NT and 95 is to use a u_int instead of a u_char as the ttl value. This worked for the latest version of RMP that I put out in October. > Then there's that small question of interoperable applications. :) -- Todd Montgomery tmont@cerc.wvu.edu From list-mgr@ISI.EDU Thu Dec 14 16:49:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01634>; Thu, 14 Dec 1995 16:50:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01616>; Thu, 14 Dec 1995 16:49:41 -0800 Received: from smigw1.sumikin.co.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA01608>; Thu, 14 Dec 1995 16:49:33 -0800 Received: by smigw1.sumikin.co.jp (8.6.12+2.5Wb7/3.3W9-sumikin-950406) id JAA02326; Fri, 15 Dec 1995 09:49:11 +0900 Received: from mailgw1.sumikin.co.jp by smigw1.sumikin.co.jp via smap (V1.3) id sma002320; Fri, 15 Dec 95 09:48:48 +0900 Received: from earth.mit.sumikin.co.jp (earth.mit.sumikin.co.jp [133.150.96.100]) by mailgw1.sumikin.co.jp (8.6.12+2.5Wb7/3.3W9sumikin-in-950810) with SMTP id JAA09696 for <MBONE@ISI.EDU>; Fri, 15 Dec 1995 09:44:58 +0900 Received: from MIKI (dec30) by earth.mit.sumikin.co.jp (4.1/6.4J.6) id AA02194; Fri, 15 Dec 95 09:49:31 JST Date: Fri, 15 Dec 95 09:49:42 JST From: futoshi miki <futoshi@mit.sumikin.co.jp> Subject: unsubscribe To: MBONE X-Mailer: Chameleon V0.05, TCP/IP for Windows, NetManage Inc. Message-Id: <Chameleon.951215095111.futoshi@MIKI> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-2022-JP unsubcribe From list-mgr@ISI.EDU Thu Dec 14 08:52:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01740>; Thu, 14 Dec 1995 16:52:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01729>; Thu, 14 Dec 1995 16:52:22 -0800 Received: from kachina.jetcafe.org ([206.117.70.2]) by venera.isi.edu (5.65c/5.61+local-22) id <AA01722>; Thu, 14 Dec 1995 16:52:20 -0800 Received: from [127.0.0.1] ([127.0.0.1]) by kachina.jetcafe.org (8.6.10/8.6.6) with SMTP id QAA21159 for <mbone@isi.edu>; Thu, 14 Dec 1995 16:52:18 -0800 Message-Id: <199512150052.QAA21159@kachina.jetcafe.org> To: mbone Subject: Re: tunnels again... Date: Thu, 14 Dec 1995 16:52:18 -0800 From: Dave Hayes <dave@kachina.jetcafe.org> Steve Deering <deering@parc.xerox.com> writes: >In case there is any such perception, I'd like to clear that up. Jeff is >doing a great job of rationalizing the MBone topology, and has the full >support of us MBone "oldtimers". Ya know, labels are such bogus things. Is the social dynamic of the MBONE administrators going to decay to the current dynamic of Usenet? You know, the "oldtimers" vs "newbies" thing? I sure hope not. Really. ------ >>> Dave Hayes - Altadena CA, USA - dave@jetcafe.org <<< "If a man loves the labor of his trade apart from any question of success or fame, the gods have called him." -Robert Louis Stevenson From list-mgr@ISI.EDU Fri Dec 15 20:49:07 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06398>; Thu, 14 Dec 1995 18:54:30 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06332>; Thu, 14 Dec 1995 18:52:03 -0800 Received: from bisque.mse.kyutech.ac.jp ([131.206.67.3]) by venera.isi.edu (5.65c/5.61+local-22) id <AA06315>; Thu, 14 Dec 1995 18:51:27 -0800 Received: by bisque.mse.kyutech.ac.jp (5.65/6.4J.6-91May16) id AA08855; Fri, 15 Dec 95 11:49:07 +0900 Date: Fri, 15 Dec 95 11:49:07 +0900 From: Masanobu UMEDA <umerin@bisque.mse.kyutech.ac.jp> Return-Path: <umerin@bisque.mse.kyutech.ac.jp> Message-Id: <9512150249.AA08855@bisque.mse.kyutech.ac.jp> To: young@mci.net Cc: mbone, young@mci.net In-Reply-To: "Jeff Young"'s message of Thu, 14 Dec 1995 01:23:04 -0500 <199512140623.BAA03644@clone4.reston.mci.net> Subject: tunnels again... Reply-To: umerin@mse.kyutech.ac.jp Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Thu, 14 Dec 1995 01:23:04 -0500 From: "Jeff Young" <young@mci.net> I've run the comparison of the MCI Routing Registry and the known mbone tunnels (http://www.cl.cam.ac.uk:80/mbone/). The list has been reduced by hand (traceroute) to only those tunnels which cross the mci backbone based on unicast routing, and those sites which may or may not cross the mci backbone but do not allow source routed packets. (MRNET-MAINT-MCI[coms4.moorhead.msus.edu]:WIDE-MAINT-MCI[nic.karrn.ad.jp]) may be routed thru MCI (SURA[dragon.iri2.tele.odu.edu]:WIDE-MAINT-MCI[nic.karrn.ad.jp]) may be routed thru MCI (AARNET[mqu.gw.CSIRO.AU]:WIDE-MAINT-MCI[nic.karrn.ad.jp]) may be routed thru MCI There is no such direct tunnel from nic.karrn.ad.jp to outside of Japan. I suppose the known mbone tunnels you refer to is incomplete. Speaking of mbone, nic.karrn.ad.jp has a tunnel to totoro.sinet.ad.jp (SINET) instead of WIDE. I guess that is a point. nic.karrn.ad.jp# mrinfo 127.0.0.1 (localhost) [version 3.8]: 192.50.15.19 -> 0.0.0.0 (local) [1/16/querier/leaf] 192.50.15.19 -> 133.5.11.226 (korosuke.ec.kyushu-u.ac.jp) [1/16/tunnel] 192.50.15.19 -> 150.99.99.20 (totoro.sinet.ad.jp) [1/32/tunnel] 192.50.15.19 -> 131.206.1.5 (mutsuki.isci.kyutech.ac.jp) [1/160/tunnel/leaf] 192.50.15.19 -> 133.95.102.17 (133.95.102.17) [1/64/tunnel/leaf] 192.50.15.19 -> 133.45.64.2 (jupiter.cc.nagasaki-u.ac.jp) [1/64/tunnel] 192.50.15.19 -> 163.209.15.4 (info-cc.cc.kagoshima-u.ac.jp) [1/64/tunnel] 192.50.15.19 -> 133.37.57.81 (csis100.csis.oita-u.ac.jp) [1/64/tunnel] 192.50.15.19 -> 202.24.92.3 (ss2.kmt-iri.go.jp) [1/96/tunnel/leaf] 192.50.15.19 -> 133.54.240.31 (obi.cc.miyazaki-u.ac.jp) [1/64/tunnel/leaf] 192.50.15.19 -> 133.49.4.1 (sagagw.cc.saga-u.ac.jp) [1/64/tunnel] 192.50.15.19 -> 133.13.31.6 (spcom.ie.u-ryukyu.ac.jp) [1/64/tunnel/leaf] 192.50.15.19 -> 192.50.14.161 (yugw.Yamaguchi.karrn.ad.jp) [1/64/tunnel] 192.50.15.19 -> 133.17.100.101 (133.17.100.101) [1/128/tunnel/leaf] 192.50.15.19 -> 192.218.158.53 (192.218.158.53) [1/160/tunnel/down/leaf] nic.karrn.ad.jp# From list-mgr@ISI.EDU Thu Dec 14 17:22:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07429>; Thu, 14 Dec 1995 19:25:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07377>; Thu, 14 Dec 1995 19:23:13 -0800 Received: from stone.ucs.indiana.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA07370>; Thu, 14 Dec 1995 19:23:10 -0800 Received: from localhost (localhost [127.0.0.1]) by stone.ucs.indiana.edu (8.6.10/8.7.Alpha.5) with SMTP id WAA02085; Thu, 14 Dec 1995 22:22:49 -0500 Message-Id: <199512150322.WAA02085@stone.ucs.indiana.edu> To: Dave Hayes <dave@kachina.jetcafe.org> Cc: mbone, robelr@stone.ucs.indiana.edu Subject: Re: tunnels again... In-Reply-To: Your message of "Thu, 14 Dec 1995 16:52:18 PST." <199512150052.QAA21159@kachina.jetcafe.org> Date: Thu, 14 Dec 1995 22:22:48 -0500 From: Allen Robel <robelr@cell-relay.indiana.edu> >Is the social dynamic of the MBONE administrators going to decay to >the current dynamic of Usenet? You know, the "oldtimers" vs "newbies" >thing? I think that we can make a distinction between MBONE and Usenet. MBONE is experimental and Usenet is mainstream. In this regard, the opinions of the MBONE "oldtimers" (especially folks who have contributed significantly to its development) should be given due consideration and respect. When the MBONE reaches the technical maturity of Usenet, then we can talk about "social dynamics" (IMHO). allen From list-mgr@ISI.EDU Fri Dec 15 08:02:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08695>; Thu, 14 Dec 1995 20:03:28 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA08678>; Thu, 14 Dec 1995 20:02:32 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA08670>; Thu, 14 Dec 1995 20:02:29 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id GAA15648; Fri, 15 Dec 1995 06:02:10 +0200 Date: Fri, 15 Dec 1995 06:02:10 +0200 Message-Id: <199512150402.GAA15648@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: mbenson@davinci.gmu.edu (Michael Benson) Cc: chutzpah@race.u-tokyo.ac.jp (Koji ANDO), mbone, tim@aimnet.com Subject: Re: mBone may be flooded In-Reply-To: <199512141829.NAA15296@davinci.gmu.edu> References: <199512141710.CAA15869@cygnus.race.u-tokyo.ac.jp> <199512141829.NAA15296@davinci.gmu.edu> Michael Benson writes: > Yes, MS TCP/IP Stacks support IP MUlticast. I believe Apple has a version > as well. > Not the Windows 95 stack. Or at least not by default and I have been unable to find a way to make it do so. Or actually it can send IP multicast datagrams but you cannot bind a receive socket to multicast address nor do an IP_ADD_MEMBERSHIP. Pete From list-mgr@ISI.EDU Sat Dec 16 02:35:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09555>; Thu, 14 Dec 1995 20:39:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA09505>; Thu, 14 Dec 1995 20:35:54 -0800 Received: from dmssyd.syd.dms.CSIRO.AU by venera.isi.edu (5.65c/5.61+local-22) id <AA09496>; Thu, 14 Dec 1995 20:35:45 -0800 Received: from drugs.syd.dms.CSIRO.AU by dmssyd.syd.dms.CSIRO.AU (4.1/5.17) id AA10888; Fri, 15 Dec 95 15:35:17 EST (from Mark.Andrews@dms.csiro.au (Mark Andrews)) Message-Id: <9512150435.AA10888@dmssyd.syd.dms.CSIRO.AU> To: "Jeff Young" <young@mci.net> Cc: mbone Subject: Re: tunnels again... In-Reply-To: Your message of "Thu, 14 Dec 1995 01:23:04 CDT." <199512140623.BAA03644@clone4.reston.mci.net> Date: Fri, 15 Dec 1995 15:35:09 +1100 From: Mark Andrews <Mark.Andrews@dms.CSIRO.AU> > (AARNET[drugs.syd.dms.CSIRO.AU]:DFN-MNT[mbone.rus.uni-stuttgart.de]) may be r > (AARNET[dorado.rp.CSIRO.AU]:DFN-MNT[algol.tm.informatik.uni-frankfurt.de]) ma > (AARNET[mqu.gw.CSIRO.AU]:WIDE-MAINT-MCI[nic.karrn.ad.jp]) may be routed thru Given none of drugs.syd.dms.CSIRO.AU, dorado.rp.CSIRO.AU or mqu.gw.CSIRO.AU have ever run tunnels outside of CSIRO let alone Australia, I would question the validity of the tunnel list. They are (were) mrouters though. drugs.syd.dms.CSIRO.AU is turned off. dorado.rp.CSIRO.AU is ? mqu.gw.CSIRO.AU is on but has only one tunnel omega.mel.dms.CSIRO.AU and one neigbouring mrouter nml.gw.CSIRO.AU Mark -- Mark Andrews, CSIRO Div Maths & Stats Locked Bag 17, North Ryde, NSW 2113, Australia. PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au UUCP: ....!uunet!syd.dms.csiro.au!marka From list-mgr@ISI.EDU Thu Dec 14 13:02:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10278>; Thu, 14 Dec 1995 21:04:32 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA10126>; Thu, 14 Dec 1995 21:02:10 -0800 Received: from kachina.jetcafe.org ([206.117.70.2]) by venera.isi.edu (5.65c/5.61+local-22) id <AA10117>; Thu, 14 Dec 1995 21:02:07 -0800 Received: from [127.0.0.1] ([127.0.0.1]) by kachina.jetcafe.org (8.6.10/8.6.6) with SMTP id VAA24296; Thu, 14 Dec 1995 21:02:02 -0800 Message-Id: <199512150502.VAA24296@kachina.jetcafe.org> To: Allen Robel <robelr@stone.ucs.indiana.edu> Cc: mbone Subject: Re: tunnels again... Date: Thu, 14 Dec 1995 21:02:02 -0800 From: Dave Hayes <dave@kachina.jetcafe.org> Allen Robel <robelr@stone.ucs.indiana.edu> writes: >I wrote: >>Is the social dynamic of the MBONE administrators going to decay to >>the current dynamic of Usenet? You know, the "oldtimers" vs "newbies" >>thing? >I think that we can make a distinction between MBONE and Usenet. >MBONE is experimental and Usenet is mainstream. Perhaps technically we can, but I think that the progression dynamics are quite similar. In this region of viewpoint, I think that they only differ by age. >In this regard, the opinions of >the MBONE "oldtimers" (especially folks who have contributed significantly >to its development) should be given due consideration and respect. Due respect was never in question. I was merely referring to the virtual baseball bat of separationism that seems to appear whenever labels are used to categorize people into two mutually exclusive groups. That's all. 8-) Respect is given where it is due, and yes, there is much due to those who have created something wonderful. I feel no respect is more important than preventing unwarranted antagonism and rampant misunderstanding. Am I making sense? >When the MBONE reaches the technical maturity of Usenet, then we can >talk about "social dynamics" (IMHO). Isn't that a bit too late? ------ >>> Dave Hayes - Altadena CA, USA - dave@jetcafe.org <<< Do what you can, with what you have, where you are. From list-mgr@ISI.EDU Fri Dec 15 09:33:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11201>; Thu, 14 Dec 1995 21:36:45 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA11028>; Thu, 14 Dec 1995 21:34:18 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA11021>; Thu, 14 Dec 1995 21:34:14 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id HAA15762; Fri, 15 Dec 1995 07:33:44 +0200 Date: Fri, 15 Dec 1995 07:33:44 +0200 Message-Id: <199512150533.HAA15762@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Bill Fenner <fenner@parc.xerox.com> Cc: mbone Subject: Black holes caused by aggregation In-Reply-To: <95Dec14.135406pst.177478@crevenia.parc.xerox.com> References: <95Dec14.135406pst.177478@crevenia.parc.xerox.com> Bill Fenner writes: > [This list is growing at an alarming rate!] > > As I described in a message to the MBONE mailing list in October, > older versions of mrouted can't handle certain types of routes. Would it be possible (for you?) to do a list of the *backbone* mrouteds that are below version 3.5 and post that regularly here also? The list of about all mrouteds (with the exception of those of limited unicast reachability) is available on the JIPS-web in UK. The problem is that the information should be processed so that all the leafs (that I don't care about :-) would be left out and also mrouteds serving only one downstream leaf, which could be called an "old and rusty chain" :-) It would be interesting to know how many "key points" in mbone actually run oldish mrouteds. Pete From list-mgr@ISI.EDU Thu Dec 14 16:03:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14972>; Fri, 15 Dec 1995 00:06:26 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14923>; Fri, 15 Dec 1995 00:04:04 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA14916>; Fri, 15 Dec 1995 00:04:02 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id AAA05736; Fri, 15 Dec 1995 00:03:50 -0800 Message-Id: <199512150803.AAA05736@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Dave Hayes <dave@kachina.jetcafe.org> Cc: mbone Subject: Re: tunnels again... In-Reply-To: Your message of "Thu, 14 Dec 1995 16:52:18 PST." <199512150052.QAA21159@kachina.jetcafe.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Dec 1995 00:03:50 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Hmmm.... I think that the reference to the old timers is just to re-assure us that Jeff is doing a good job and I think that he is from my own personal experience 8) Amancio >>> Dave Hayes said: > Steve Deering <deering@parc.xerox.com> writes: > >In case there is any such perception, I'd like to clear that up. Jeff is > >doing a great job of rationalizing the MBone topology, and has the full > >support of us MBone "oldtimers". > > Ya know, labels are such bogus things. > > Is the social dynamic of the MBONE administrators going to decay to > the current dynamic of Usenet? You know, the "oldtimers" vs "newbies" > thing? > > I sure hope not. Really. > ------ > >>> Dave Hayes - Altadena CA, USA - dave@jetcafe.org <<< > > "If a man loves the labor of his trade apart from any question of success > or fame, the gods have called him." -Robert Louis Stevenson > From list-mgr@ISI.EDU Fri Dec 15 02:35:32 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19079>; Fri, 15 Dec 1995 02:36:48 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA19068>; Fri, 15 Dec 1995 02:35:38 -0800 Received: from access.cc.univie.ac.at by venera.isi.edu (5.65c/5.61+local-22) id <AA19061>; Fri, 15 Dec 1995 02:35:32 -0800 Received: by cc.univie.ac.at (MX V4.1 VAX) id 3; Fri, 15 Dec 1995 11:35:26 MET Date: Fri, 15 Dec 1995 11:35:24 MET From: "Wilfried Woeber, UniVie/ACOnet" <woeber@cc.univie.ac.at> To: mbone Cc: woeber@cc.univie.ac.at Message-Id: <0099AE69.E371DA5A.3@cc.univie.ac.at> Subject: Re: Black holes caused by aggregation Bill! >[This list is growing at an alarming rate!] Not to a CIDR-aware unicast person's surprise :-) >As I described in a message to the MBONE mailing list in October, >older versions of mrouted can't handle certain types of routes. >Injecting both a general route (e.g. 128.118/16) and more-specific >routes (e.g. 128.118.4/24) will cause black holes for traffic >originating from hosts that are covered by the more specific routes. I don't think that any attempt to prevent this situation is potentially successful - nor desireable, but that is my very personal point of view. Of course, if the additional more specific routes are not useful from the unicast's point of view, this should be cleaned up asap. I'm probably repeating an very well-know thing just once again... Given the growing (and essential) deployment of aggregate routes, IMHO this is going to be the way of life. Thus I think the only useful approach is to replace old mrouteds. The current behavior might even be perceived as an incentive to do so! Best regards, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 -------------------------------------------------------------------------- From list-mgr@ISI.EDU Fri Dec 15 12:29:06 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20957>; Fri, 15 Dec 1995 04:38:05 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20926>; Fri, 15 Dec 1995 04:36:04 -0800 Received: from mserv1.dl.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA20919>; Fri, 15 Dec 1995 04:35:55 -0800 Received: from dlsm.dl.ac.uk by mserv1.dl.ac.uk with SMTP id MAA05344 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from rbr@dlsm.dl.ac.uk); Fri, 15 Dec 1995 12:29:14 GMT Precedence: first-class Received: by dlsm.dl.ac.uk (4.1/SMI-4.1) id AA26438; Fri, 15 Dec 95 12:29:06 GMT From: rbr@dlsm.dl.ac.uk (Rob Bradshaw) Message-Id: <9512151229.AA26438@dlsm.dl.ac.uk> Subject: Re: tunnels again... To: umerin@mse.kyutech.ac.jp Date: Fri, 15 Dec 1995 12:29:06 +0000 (GMT) Cc: young@mci.net, mbone, pb@cl.cam.ac.uk In-Reply-To: <9512150249.AA08855@bisque.mse.kyutech.ac.jp> from "Masanobu UMEDA" at Dec 15, 95 11:49:07 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1599 Hi > > Date: Thu, 14 Dec 1995 01:23:04 -0500 > From: "Jeff Young" <young@mci.net> > > I've run the comparison of the MCI Routing Registry and the known > mbone tunnels (http://www.cl.cam.ac.uk:80/mbone/). The list has > been reduced by hand (traceroute) to only those tunnels which > cross the mci backbone based on unicast routing, and those sites > which may or may not cross the mci backbone but do not allow source > routed packets. > > (MRNET-MAINT-MCI[coms4.moorhead.msus.edu]:WIDE-MAINT-MCI[nic.karrn.ad.jp]) may be routed thru MCI > (SURA[dragon.iri2.tele.odu.edu]:WIDE-MAINT-MCI[nic.karrn.ad.jp]) may be routed thru MCI > (AARNET[mqu.gw.CSIRO.AU]:WIDE-MAINT-MCI[nic.karrn.ad.jp]) may be routed thru MCI > > There is no such direct tunnel from nic.karrn.ad.jp to outside of > Japan. I suppose the known mbone tunnels you refer to is incomplete. > Speaking of mbone, nic.karrn.ad.jp has a tunnel to totoro.sinet.ad.jp > (SINET) instead of WIDE. I guess that is a point. I seem to remember that the mwatch database (which is presumably the source of the http://www.cl.cam.ac.uk:80/mbone/ information) only had an aggregate capability, in that it included all tunnels it had ever seen. Of course, I could be wrong... Perhaps Piete or Atanu could elaborate :-) And of course Jeff could have accounted for this in some way... (Just trying to be helpful). Cheers -- Rob Bradshaw Email: R.G.Bradshaw@dl.ac.uk [rb685] Tel: +44 1925 603226 | Fax: +44 1925 603230 Networks Group, Daresbury Lab, Warrington, WA4 4AD, England From list-mgr@ISI.EDU Fri Dec 15 04:45:43 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25221>; Fri, 15 Dec 1995 06:48:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25206>; Fri, 15 Dec 1995 06:47:58 -0800 Received: from clone4.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA25199>; Fri, 15 Dec 1995 06:47:54 -0800 Received: from localhost (localhost.mci.net [127.0.0.1]) by clone4.reston.mci.net (8.6.12/8.6.6) with ESMTP id JAA03488; Fri, 15 Dec 1995 09:45:47 -0500 Message-Id: <199512151445.JAA03488@clone4.reston.mci.net> To: rbr@dlsm.dl.ac.uk (Rob Bradshaw) Cc: umerin@mse.kyutech.ac.jp, mbone, pb@cl.cam.ac.uk Subject: Re: tunnels again... In-Reply-To: Your message of "Fri, 15 Dec 1995 12:29:06 GMT." <9512151229.AA26438@dlsm.dl.ac.uk> Date: Fri, 15 Dec 1995 09:45:43 -0500 From: "Jeff Young" <young@mci.net> there seems to be an odd case where the logic i wrote reports tunnels that don't exist. it often involves tunnels to foreign countries, i haven't had a report of any problems with the data from tunnels in this country. the starting point i used was http://www.cl.cam.ac.uk:80/cgi-bin/mrinfo?map_symbolic which does an mrinfo on the hosts it can find (at least that's the way i understood it). it takes 30+ minutes to run so i figured it wasn't just reporting from a database. the data is in html so it's about as easy to read as raw postscript without a viewer. the script i wrote takes hours to run (on a sparc 5 with 32mb) so catching this wierd case has been difficult. Booker Bense of Stanford reported it yesterday and i've been looking for it since. at this point i'll probably find it today and if i've reported tunnels on your machine which don't exist, you have my apologies. as to the matter of newbies vs. old-timers :-): having at one point been the administrative contact for an mbone site i thought it might be a little difficult to contact some of these sites out of the blue and ask them to relinquish their tunnel(s) in favor of something new. it may have been even more harsh as an administrator to wake up one morning and be on some dork's list (especially if that list reported tunnels that didn't exist to my mrouter). Jeff Young young@mci.net > From: rbr@dlsm.dl.ac.uk (Rob Bradshaw) > Subject: Re: tunnels again... > To: umerin@mse.kyutech.ac.jp > Date: Fri, 15 Dec 1995 12:29:06 +0000 (GMT) > Cc: young@mci.net, mbone@ISI.EDU, pb@cl.cam.ac.uk > > Hi > > > > Date: Thu, 14 Dec 1995 01:23:04 -0500 > > From: "Jeff Young" <young@mci.net> > > > > I've run the comparison of the MCI Routing Registry and the known > > mbone tunnels (http://www.cl.cam.ac.uk:80/mbone/). The list has > > been reduced by hand (traceroute) to only those tunnels which > > cross the mci backbone based on unicast routing, and those sites > > which may or may not cross the mci backbone but do not allow source > > routed packets. > > > > (MRNET-MAINT-MCI[coms4.moorhead.msus.edu]:WIDE-MAINT-MCI[nic.karrn.ad.jp]) may be routed thru MCI > > (SURA[dragon.iri2.tele.odu.edu]:WIDE-MAINT-MCI[nic.karrn.ad.jp]) may be routed thru MCI > > (AARNET[mqu.gw.CSIRO.AU]:WIDE-MAINT-MCI[nic.karrn.ad.jp]) may be routed thru MCI > > > > There is no such direct tunnel from nic.karrn.ad.jp to outside of > > Japan. I suppose the known mbone tunnels you refer to is incomplete. > > Speaking of mbone, nic.karrn.ad.jp has a tunnel to totoro.sinet.ad.jp > > (SINET) instead of WIDE. I guess that is a point. > > I seem to remember that the mwatch database (which is presumably the > source of the http://www.cl.cam.ac.uk:80/mbone/ information) only had > an aggregate capability, in that it included all tunnels it had ever > seen. Of course, I could be wrong... > > Perhaps Piete or Atanu could elaborate :-) > > And of course Jeff could have accounted for this in some way... > > (Just trying to be helpful). Cheers > > -- > Rob Bradshaw Email: R.G.Bradshaw@dl.ac.uk [rb685] > Tel: +44 1925 603226 | Fax: +44 1925 603230 > Networks Group, Daresbury Lab, Warrington, WA4 4AD, England From list-mgr@ISI.EDU Fri Dec 15 14:45:53 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25385>; Fri, 15 Dec 1995 06:55:16 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA25366>; Fri, 15 Dec 1995 06:54:48 -0800 Received: from bescot.cl.cam.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA25300>; Fri, 15 Dec 1995 06:51:29 -0800 Received: from bescot.cl.cam.ac.uk [128.232.0.10] (pb) by bescot.cl.cam.ac.uk with esmtp (Exim 0.25 #2) id E0tQbOT-0000j6-00; Fri, 15 Dec 1995 14:45:53 +0000 X-Mailer: exmh version 1.6.5+cl 95/12/8 X-Uri: <URL:http://www.cl.cam.ac.uk/users/pb> X-Face: &@N3QE9h|>f`igFCkZ'a1`z=nNLXb}k>H(79G"V?@!&*yn)uhPBctF1vc}LD'{OA%$bs X+l[wN,I^G8kKj2NFxQrr@1C4QBC]hq5-%ZkV,^Zl/qE<0`zCQ1nM+]-N<^WG[H)]?d) A:L9AFgOU[BjbaY)uBAMz}h!fm^O0# To: rbr@dlsm.dl.ac.uk (Rob Bradshaw) Cc: umerin@mse.kyutech.ac.jp, young@mci.net, mbone Subject: Re: tunnels again... In-Reply-To: Your message of Fri, 15 Dec 1995 12:29:06 +0000. <9512151229.AA26438@dlsm.dl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Dec 1995 14:45:53 +0000 From: Piete Brooks <Piete.Brooks@cl.cam.ac.uk> Message-Id: <E0tQbOT-0000j6-00@bescot.cl.cam.ac.uk> I'd been stacking up this thread to read when I had a moment away from MTA HACKing and FO cable management, but I have not yet had any time .... >> I've run the comparison of the MCI Routing Registry and the known >> mbone tunnels (http://www.cl.cam.ac.uk:80/mbone/). Call that "partial list of some Mbone Routers and an approximation to their tunnels" .... >> The list has been reduced by hand (traceroute) to only those tunnels which >> cross the mci backbone based on unicast routing Boggle !! A herculean task indeed ! I suggest that as well as just looking at the "last probed" info, you actually mrinfo the routers concerned yourself (a trivial task compared to what you have done so far) and use that data .... > I seem to remember that the mwatch database (which is presumably the > source of the http://www.cl.cam.ac.uk:80/mbone/ information) It is indeed. > only had an aggregate capability, Eh ?? What's that ? > in that it included all tunnels it had ever seen. No -- it reports the tunnels that it saw last time it got an answer. It *DOES* retain info about routers which it has not managed to contact for some time, but a number of the CGI scripts ignore old info. > Of course, I could be wrong... Let me not be the one to say :-)) SO: sure, use my info to generate a set of hints, but then get definative info from the horse's mouth by asking the routers themselves. From list-mgr@ISI.EDU Fri Dec 15 05:13:10 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26090>; Fri, 15 Dec 1995 07:15:58 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26075>; Fri, 15 Dec 1995 07:15:27 -0800 Received: from mercury.thepoint.net by venera.isi.edu (5.65c/5.61+local-22) id <AA26068>; Fri, 15 Dec 1995 07:15:26 -0800 Received: by mercury.thepoint.net (8.6.12/) id KAA02849; Fri, 15 Dec 1995 10:13:10 -0500 Date: Fri, 15 Dec 1995 10:13:10 -0500 (EST) From: Arlie Davis <arlie@thepoint.net> To: Koji ANDO <chutzpah@race.u-tokyo.ac.jp> Cc: mbone, Tim Payne <tim@aimnet.com> Subject: Re: mBone may be flooded In-Reply-To: <199512141710.CAA15869@cygnus.race.u-tokyo.ac.jp> Message-Id: <Pine.BSF.3.91.951215101012.2505A-100000@mercury.thepoint.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Hello. > > Tim said: > > Do we all know about CVP Connectix Video Phone? > > Connectix is about to flood the market with there own little mbone viewer > > <phone>. Except for the lack of multicast support, this is a Good Thing. > Do Microsoft TCP/IP-32 or MacTCP support IP multicast? Microsoft's stack does. NT v3.50 has a bug in its IGMP code, though. It does correctly join multicast groups, but it does not respond to later IGMP membership queries. NT v3.51 and Win95, though, handle multicast very well. I've been doing some development of multicast code under NT 3.51 and am very pleased. > FYI, see http://www.pcworld.com/connectix/vpchoice.html By the way, I saw no mention of multicast support in the Connectix Video Phone. I'm going to call their tech support and ask if/when they plan to support multicast and/or RTP. If I find out anything interesting, I'll mail the list. -- arlie From list-mgr@ISI.EDU Fri Dec 15 15:11:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26474>; Fri, 15 Dec 1995 07:26:51 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26455>; Fri, 15 Dec 1995 07:26:25 -0800 Received: from bescot.cl.cam.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA26377>; Fri, 15 Dec 1995 07:23:10 -0800 Received: from bescot.cl.cam.ac.uk [128.232.0.10] (pb) by bescot.cl.cam.ac.uk with esmtp (Exim 0.25 #2) id E0tQbnQ-0006uL-00; Fri, 15 Dec 1995 15:11:40 +0000 X-Mailer: exmh version 1.6.5+cl 95/12/8 X-Uri: <URL:http://www.cl.cam.ac.uk/users/pb> X-Face: &@N3QE9h|>f`igFCkZ'a1`z=nNLXb}k>H(79G"V?@!&*yn)uhPBctF1vc}LD'{OA%$bs X+l[wN,I^G8kKj2NFxQrr@1C4QBC]hq5-%ZkV,^Zl/qE<0`zCQ1nM+]-N<^WG[H)]?d) A:L9AFgOU[BjbaY)uBAMz}h!fm^O0# To: Jeff Young <young@mci.net> Cc: rbr@dlsm.dl.ac.uk (Rob Bradshaw), umerin@mse.kyutech.ac.jp, mbone Subject: Re: tunnels again... In-Reply-To: Your message of Fri, 15 Dec 1995 09:45:43 -0500. <199512151445.JAA03488@clone4.reston.mci.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Dec 1995 15:11:39 +0000 From: Piete Brooks <Piete.Brooks@cl.cam.ac.uk> Message-Id: <E0tQbnQ-0006uL-00@bescot.cl.cam.ac.uk> > there seems to be an odd case where the logic i wrote reports tunnels that > don't exist. Hmm -- the "mrinfo" info shouldn't make up tunnels .... The old junk to try to fine paths is hosed -- don't use it ! > the starting point i used was > http://www.cl.cam.ac.uk:80/cgi-bin/mrinfo?map_symbolic > which does an mrinfo on the hosts it can find Not so. > (at least that's the way i understood it). Good guess, but the whole point is to avoid real-time probes. It uses the data it has collected. > it takes 30+ minutes to run so i figured it wasn't just reporting from a > database. % time lynx -source http://www.cl.cam.ac.uk:80/cgi-bin/mrinfo?map_symbolic > /tmp/map 11.8 real 0.3 user 1.9 sys Methinks you have a slow link to my server ! > the data is in html so it's about as easy to read as raw postscript without > a viewer. lynx does a reasonable jib (that's what I use on it most of the time). Note that it's in HTML as it's being accessed over the web .... It actually takes the raw text format and HTML's it ! From list-mgr@ISI.EDU Fri Dec 15 05:28:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26720>; Fri, 15 Dec 1995 07:31:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26696>; Fri, 15 Dec 1995 07:30:27 -0800 Received: from mercury.thepoint.net by venera.isi.edu (5.65c/5.61+local-22) id <AA26689>; Fri, 15 Dec 1995 07:30:26 -0800 Received: by mercury.thepoint.net (8.6.12/) id KAA03051; Fri, 15 Dec 1995 10:28:36 -0500 Date: Fri, 15 Dec 1995 10:28:36 -0500 (EST) From: Arlie Davis <arlie@thepoint.net> To: Ian Duncan <id@cc.mcgill.ca> Cc: Michael Benson <mbenson@davinci.gmu.edu>, Koji ANDO <chutzpah@race.u-tokyo.ac.jp>, mbone, tim@aimnet.com Subject: Re: mBone may be flooded In-Reply-To: <Pine.BSF.3.91.951214153206.16687A-100000@junkie.tanstafl.ca> Message-Id: <Pine.BSF.3.91.951215101451.2505C-100000@mercury.thepoint.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The OpenTransport for Macintosh claims to support multicast. Until Apple > resolves some basic bugs it isn't going to see wide use. Microsoft has > multicast in the 32 (W95 & NT) stacks but reports are it there's no > control for TTL (default is 1) which for use is a definite lose. For the > MBONE I guess it's a short term win, they can watch but not source. Other > winsock implementations may have better support. > > Then there's that small question of interoperable applications. Microsoft's TCP/IP stack definitely _does_ support multicast TTL's greater than one. I have used several products and written several programs of my own that use multicast, and none of them have had a problem with setting the multicast TTL. My current favorite is Speak Freely, available at http://www.fourmilab.ch/ and at "ftp://ftp.thepoint.net/Internet/Interactive Media/Speak Freely/". (Yes, there are spaces in the URL.) -- arlie From list-mgr@ISI.EDU Fri Dec 15 05:29:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26834>; Fri, 15 Dec 1995 07:35:58 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26817>; Fri, 15 Dec 1995 07:35:32 -0800 Received: from clone4.Reston.mci.net by venera.isi.edu (5.65c/5.61+local-22) id <AA26810>; Fri, 15 Dec 1995 07:35:31 -0800 Received: from localhost (localhost.mci.net [127.0.0.1]) by clone4.reston.mci.net (8.6.12/8.6.6) with ESMTP id KAA06424; Fri, 15 Dec 1995 10:30:21 -0500 Message-Id: <199512151530.KAA06424@clone4.reston.mci.net> To: Piete Brooks <Piete.Brooks@cl.cam.ac.uk> Cc: rbr@dlsm.dl.ac.uk (Rob Bradshaw), umerin@mse.kyutech.ac.jp, mbone Subject: Re: tunnels again... In-Reply-To: Your message of "Fri, 15 Dec 1995 15:11:39 GMT." <E0tQbnQ-0006uL-00@bescot.cl.cam.ac.uk> Date: Fri, 15 Dec 1995 10:29:55 -0500 From: "Jeff Young" <young@mci.net> your tools were not making up tunnels, just to be clear. mine were. the html wasn't a problem for the script, it just made it harder for me to see any problems with logic with the naked eye. i had to run the script over and over to find the error. i think i've caught this problem. as for the speed: about the slowest link i see is a frac e1? traceroute to bescot.cl.cam.ac.uk (128.232.0.10), 30 hops max, 40 byte packets 1 cpe1-ethernet1-0 (204.70.128.2) 69 ms 202 ms 10 ms 10 sl-ukerna-1-S0-1984k.sprintlink.net (198.67.129.10) 180 ms 233 ms * 16 * bescot.cl.cam.ac.uk (128.232.0.10) 202 ms 190 ms but links across the ocean are notoriously full. thanks for the explanation of this tool. i definitely planned to query routers directly before i contact site administrators. Jeff Young young@mci.net > To: Jeff Young <young@mci.net> > cc: rbr@dlsm.dl.ac.uk (Rob Bradshaw), umerin@mse.kyutech.ac.jp, mbone@ISI.EDU > Subject: Re: tunnels again... > > > there seems to be an odd case where the logic i wrote reports tunnels that > > don't exist. > > Hmm -- the "mrinfo" info shouldn't make up tunnels .... > The old junk to try to fine paths is hosed -- don't use it ! > > > the starting point i used was > > http://www.cl.cam.ac.uk:80/cgi-bin/mrinfo?map_symbolic > > which does an mrinfo on the hosts it can find > > Not so. > > > (at least that's the way i understood it). > > Good guess, but the whole point is to avoid real-time probes. > It uses the data it has collected. > > > it takes 30+ minutes to run so i figured it wasn't just reporting from a > > database. > > % time lynx -source http://www.cl.cam.ac.uk:80/cgi-bin/mrinfo?map_symbolic > > /tmp/map > 11.8 real 0.3 user 1.9 sys > > Methinks you have a slow link to my server ! > > > the data is in html so it's about as easy to read as raw postscript without > > a viewer. > > lynx does a reasonable jib (that's what I use on it most of the time). > > Note that it's in HTML as it's being accessed over the web .... > It actually takes the raw text format and HTML's it ! From list-mgr@ISI.EDU Fri Dec 15 05:34:36 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27012>; Fri, 15 Dec 1995 07:37:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26865>; Fri, 15 Dec 1995 07:36:40 -0800 Received: from mercury.thepoint.net by venera.isi.edu (5.65c/5.61+local-22) id <AA26856>; Fri, 15 Dec 1995 07:36:37 -0800 Received: by mercury.thepoint.net (8.6.12/) id KAA03131; Fri, 15 Dec 1995 10:34:37 -0500 Date: Fri, 15 Dec 1995 10:34:36 -0500 (EST) From: Arlie Davis <arlie@thepoint.net> To: Petri Helenius <pete@sms.fi> Cc: Michael Benson <mbenson@davinci.gmu.edu>, Koji ANDO <chutzpah@race.u-tokyo.ac.jp>, mbone, tim@aimnet.com Subject: Re: mBone may be flooded In-Reply-To: <199512150402.GAA15648@silver.sms.fi> Message-Id: <Pine.BSF.3.91.951215103300.2505D-100000@mercury.thepoint.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Michael Benson writes: > > Yes, MS TCP/IP Stacks support IP MUlticast. I believe Apple has a version > > as well. > > > Not the Windows 95 stack. Or at least not by default and I have been unable > to find a way to make it do so. Or actually it can send IP multicast > datagrams but you cannot bind a receive socket to multicast address nor > do an IP_ADD_MEMBERSHIP. I had to experiment quite a lot to discover this, but you have to bind to a port before you can join a group. Some would argue that this behavior is counterintuitive or wrong, or whatever. Maybe so, I don't care -- my apps work under NT, 95, and UNIX, so I'm happy. -- arlie From list-mgr@ISI.EDU Fri Dec 15 20:17:11 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28576>; Fri, 15 Dec 1995 08:18:24 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28548>; Fri, 15 Dec 1995 08:17:45 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA28538>; Fri, 15 Dec 1995 08:17:37 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id SAA16901; Fri, 15 Dec 1995 18:17:11 +0200 Date: Fri, 15 Dec 1995 18:17:11 +0200 Message-Id: <199512151617.SAA16901@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Arlie Davis <arlie@thepoint.net> Cc: mbone, tim@aimnet.com Subject: Re: mBone may be flooded In-Reply-To: <Pine.BSF.3.91.951215103300.2505D-100000@mercury.thepoint.net> References: <199512150402.GAA15648@silver.sms.fi> <Pine.BSF.3.91.951215103300.2505D-100000@mercury.thepoint.net> Arlie Davis writes: > > I had to experiment quite a lot to discover this, but you have to bind to > a port before you can join a group. Some would argue that this behavior > is counterintuitive or wrong, or whatever. Maybe so, I don't care -- my > apps work under NT, 95, and UNIX, so I'm happy. > Could you spare a sample piece of code to open and ready a socket for multicast reception on Win95? Pete From list-mgr@ISI.EDU Fri Dec 15 16:09:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28765>; Fri, 15 Dec 1995 08:19:46 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28741>; Fri, 15 Dec 1995 08:19:25 -0800 Received: from gizmo.lut.ac.uk by venera.isi.edu (5.65c/5.61+local-22) id <AA28507>; Fri, 15 Dec 1995 08:16:41 -0800 Received: from localhost (martin@localhost) by gizmo.lut.ac.uk (8.7.3/8.6.9) with SMTP id QAA04340; Fri, 15 Dec 1995 16:09:35 GMT Message-Id: <199512151609.QAA04340@gizmo.lut.ac.uk> X-Mailer: exmh version 1.6.5 12/11/95 To: tim@aimnet.com (Tim Payne) Cc: mbone Subject: Re: mBone may be flooded X-Uri: <URL:http://www.roads.lut.ac.uk/~martin> In-Reply-To: Your message of "Wed, 14 Dec 1994 08:26:16 -0800." <v02130502ab14cc456494@[204.118.160.28]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Dec 1995 16:09:35 +0000 From: Martin Hamilton <martin@mrrl.lut.ac.uk> Tim Payne writes: | It is not somthing we can stop. Won't rate limiting (by the ISP, or their ISP!) help a bit here ? Cheerio, Martin From list-mgr@ISI.EDU Fri Dec 15 20:26:21 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28992>; Fri, 15 Dec 1995 08:27:13 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28967>; Fri, 15 Dec 1995 08:26:41 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA28959>; Fri, 15 Dec 1995 08:26:32 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id SAA16939; Fri, 15 Dec 1995 18:26:21 +0200 Date: Fri, 15 Dec 1995 18:26:21 +0200 Message-Id: <199512151626.SAA16939@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: Martin Hamilton <martin@mrrl.lut.ac.uk> Cc: mbone Subject: Re: mBone may be flooded In-Reply-To: <199512151609.QAA04340@gizmo.lut.ac.uk> References: <v02130502ab14cc456494@[204.118.160.28]> <199512151609.QAA04340@gizmo.lut.ac.uk> Martin Hamilton writes: > > Tim Payne writes: > > | It is not somthing we can stop. > > Won't rate limiting (by the ISP, or their ISP!) help a bit here ? > You can't turn the limit low enough for it to be useful and at the same time high enough for the connection to be useful for anything else than receive-only. Pete From list-mgr@ISI.EDU Fri Dec 15 00:58:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00988>; Fri, 15 Dec 1995 09:00:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00926>; Fri, 15 Dec 1995 08:59:30 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA00906>; Fri, 15 Dec 1995 08:59:26 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14992(8)>; Fri, 15 Dec 1995 08:59:03 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Fri, 15 Dec 1995 08:58:49 -0800 To: "Wilfried Woeber, UniVie/ACOnet" <woeber@cc.univie.ac.at> Cc: mbone Subject: Re: Black holes caused by aggregation In-Reply-To: Your message of "Fri, 15 Dec 95 02:35:24 PST." <0099AE69.E371DA5A.3@cc.univie.ac.at> Date: Fri, 15 Dec 1995 08:58:38 PST Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Dec15.085849pst.177478@crevenia.parc.xerox.com> In message <0099AE69.E371DA5A.3@cc.univie.ac.at> you write: > Of course, if the additional more specific routes are not useful > from the unicast's point of view, this should be cleaned up asap. This is generally the case; I haven't seen any cases where the specific routes was actually any different from the general route, and in fact, in most of these cases, the general route is bogusly advertised from some router that can only reach one subnet. Bill From list-mgr@ISI.EDU Fri Dec 15 12:57:50 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21919>; Fri, 15 Dec 1995 15:29:26 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA20859>; Fri, 15 Dec 1995 15:10:08 -0800 Received: from sifon.CC.McGill.CA by venera.isi.edu (5.65c/5.61+local-22) id <AA20851>; Fri, 15 Dec 1995 15:10:06 -0800 Received: from junkie.tanstafl.ca (dialup130.cyberus.ca [205.208.30.130]) by sifon.CC.McGill.CA (8.6.12/8.6.6) with SMTP id RAA07233; Fri, 15 Dec 1995 17:58:43 -0500 Date: Fri, 15 Dec 1995 17:57:50 -0500 (EST) From: Ian Duncan <id@cc.mcgill.ca> X-Sender: id@junkie.tanstafl.ca To: "Todd L. Montgomery" <tmont@cerc.wvu.edu> Cc: Michael Benson <mbenson@davinci.gmu.edu>, Koji ANDO <chutzpah@race.u-tokyo.ac.jp>, mbone, tim@aimnet.com Subject: Re: mBone may be flooded In-Reply-To: <Pine.3.89.9512141737.A19105-0100000@elk> Message-Id: <Pine.BSF.3.91.951215175154.1353B-100000@junkie.tanstafl.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 14 Dec 1995, Todd L. Montgomery wrote: > > On Thu, 14 Dec 1995, Ian Duncan wrote: [ ... ] > One of the RMP users was kind enough to point out to me that the > way to get TTLs to work under NT and 95 is to use a u_int > instead ... I stand corrected. Todd was my original source for this misconception so who better to correct me. > > Then there's that small question of interoperable applications. > > :) Yeah. -- Ian Duncan, Invited Researcher C.I.T.I., Industry Canada phone: (514)973-5834 email: id@CITI.DOC.CA From list-mgr@ISI.EDU Sun Dec 17 15:56:33 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18052>; Sun, 17 Dec 1995 19:59:38 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18040>; Sun, 17 Dec 1995 19:56:37 -0800 Received: from ACADEM.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA18033>; Sun, 17 Dec 1995 19:56:35 -0800 Received: (from sob@localhost) by academ.com (8.7.1/8.7.1) id VAA02495; Sun, 17 Dec 1995 21:56:33 -0600 (CST) Date: Sun, 17 Dec 1995 21:56:33 -0600 (CST) From: sob@academ.com (Stan Barber) Message-Id: <199512180356.VAA02495@academ.com> To: mbone Subject: Re: Tunnels which transit the MCI Backbone Cc: mbone@mci.net, mbone@sesqui.net MCI recently mailed a document to the mbone list that contained some speculation related to mbone topology and the ASes involved. Here are some clarifications to some of that information. 18.24.0.1 to 149.141.38.192 may be routed thru MCI NEARNET:SESQUINET-MAINT-MCI According to Rockwell, the host 149.141.38.192 does not exist. The folks at MIT who run radole.lcs.mit.edu may wish to confirm this and delete this tunnel. 18.24.0.1 to 157.36.44.192 may be routed thru MCI NEARNET:SESQUINET-MAINT-MCI The network 157.36.0.0 is serviced by Sprint (according to traceroute and the RADB). It is not serviced by SESQUINET. 128.241.0.91 to 192.17.2.3 may be routed thru MCI SESQUINET-MAINT-MCI:CICNET-NS This information is incorrect. SESQUINET has no tunnel in place to this host from 128.241.0.91. 204.140.133.2 to 0.6.130.94 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 1.0.6.133 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 1.9.129.95 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 10.80.16.9 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 100.44.133.49 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 11.147.32.237 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 11.192.168.137 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 112.40.140.173 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 112.44.131.243 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI 204.140.133.2 to 122.254.136.10 may be routed thru MCI LN-MAINT-MCI:SESQUINET-MAINT-MCI The preceeding lines don't make any sense to me. 131.178.38.6 to 148.202.3.222 may be routed thru MCI SURA:SESQUINET-MAINT-MCI 131.178.38.6 to 148.204.103.2 may be routed thru MCI SURA:SESQUINET-MAINT-MCI Neither of these two networks are serviced by SESQUINET. 146.88.1.103 to 192.52.106.7 may be routed thru MCI SESQUINET-MAINT-MCI:MAINT-AS194 Neither of these two networks are serviced by SESQUINET. From list-mgr@ISI.EDU Sun Dec 17 16:09:24 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18377>; Sun, 17 Dec 1995 20:11:19 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18356>; Sun, 17 Dec 1995 20:10:11 -0800 Received: from ACADEM.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA18349>; Sun, 17 Dec 1995 20:10:09 -0800 Received: (from sob@localhost) by academ.com (8.7.1/8.7.1) id WAA02569; Sun, 17 Dec 1995 22:09:24 -0600 (CST) Date: Sun, 17 Dec 1995 22:09:24 -0600 (CST) From: sob@academ.com (Stan Barber) Message-Id: <199512180409.WAA02569@academ.com> To: mbone, young@mci.net Subject: Re: tunnels again... This was recently posted by MCI resulting from a postulation that these mbone tunnels may be routed through the MCI backbone. I have investigated the SESQUINET ones and here are some clarfiations. (SESQUINET-MAINT-MCI[VINEGAR.SESQUI.NET]:MAINT-AS194[mbone.ucar.edu]) may be routed thru MCI This tunnel does not exist. (unknown[131.178.38.6]:SESQUINET-MAINT-MCI[apollo.telecom.ipn.mx]) may be routed thru MCI apollo.telecom.ipn.mx is not serviced by routes via SESQUINET. It is routed via Sprint. (LN-MAINT-MCI[mb160.isi.edu]:SESQUINET-MAINT-MCI[agave.staff.udg.mx]) may be routed thru MCI (SESQUINET-MAINT-MCI[agave.staff.udg.mx]:LN-MAINT-MCI[archetype.etext.caltech.edu]) may be routed thru MCI The host agave.staff.udg.mx does not exist. (SESQUINET-MAINT-MCI[harpo.rice.edu]:LN-MAINT-MCI[zzyzxc.aero.org]) may be routed thru MCI This tunnel does not exist. (SESQUINET-MAINT-MCI[TEMPEH.SESQUI.NET]:unknown[129.120.1.39]) may be routed thru MCI This tunnel does is NOT routed via MCI. From list-mgr@ISI.EDU Sun Dec 17 16:11:44 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18412>; Sun, 17 Dec 1995 20:12:55 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA18395>; Sun, 17 Dec 1995 20:11:49 -0800 Received: from ACADEM.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA18388>; Sun, 17 Dec 1995 20:11:45 -0800 Received: (from sob@localhost) by academ.com (8.7.1/8.7.1) id WAA02603; Sun, 17 Dec 1995 22:11:44 -0600 (CST) Message-Id: <199512180411.WAA02603@academ.com> From: sob@academ.com (Stan Barber) Date: Sun, 17 Dec 1995 22:11:44 CST X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: mbone, mbone@mci.net Subject: MBONE tunnel from 128.241.0.91 <-> 192.217.65.100 This tunnel has been shut down. Connectivity between CIC.NET and SESQUI.NET for the MBONE is now via MCI's MBONE infrastructure. Thanks to Dorian Kim for his initial suggestion to do this and his able assistance in carrying it through. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From list-mgr@ISI.EDU Sun Dec 17 15:22:51 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27399>; Sun, 17 Dec 1995 23:25:44 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA27380>; Sun, 17 Dec 1995 23:24:39 -0800 Received: from quadrophenia.ucdavis.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA27373>; Sun, 17 Dec 1995 23:24:37 -0800 Received: (from ccjason@localhost) by quadrophenia.ucdavis.edu (8.6.12/8.6.12) id XAA16370; Sun, 17 Dec 1995 23:22:51 -0800 From: Jason Gabler <ccjason@quadrophenia.ucdavis.edu> Message-Id: <199512180722.XAA16370@quadrophenia.ucdavis.edu> Subject: Re: MBone split/crash? To: mbone Date: Sun, 17 Dec 1995 23:22:51 -0800 (PST) Cc: hasty@rah.star-gate.com (Amancio Hasty Jr.) In-Reply-To: <199512180408.UAA11030@rah.star-gate.com> from "Amancio Hasty Jr." at Dec 17, 95 08:08:15 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1254 Hello all! Amancio was nice enough to direct me to this mailing list. My mbone tunnel'er seems to be a bit flakey. I was wondering if someone oculd tunnel to me as soon as possible, hopefully someone more stable :) My ip address is 128.218.114.68, which is ASN-UCSF and it goes to the world via BARRNet. Hopefully someone in the S.F., Califronia, USA or on the S.F. peninsula could tunnel to me... or even East Bay. Please e-mail me if you can give me a tunnel. The person I mail back to will be the one who has the fastest route to myself. So, if you send an offer, just put it out of your mind unless you get a reply :) thanx a ton! -- Vale, jason .,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,., ` Jason Gabler jygabler@ucdavis.edu ` ' campus office: 916-752-9215 home office: 415-752-1969 ' ' Distributed Computing Analysis & Support, Information Technology, UCD' '----------------------------------------------------------------------` ` <http://quadrophnia.ucdavis.edu> Kerberos/Security Telecommuting ' ' X Windows BSD Dist.-Environments ISDN E-mail Integrity ` `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' From list-mgr@ISI.EDU Sun Dec 17 16:02:46 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28303>; Mon, 18 Dec 1995 00:04:45 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA28275>; Mon, 18 Dec 1995 00:03:02 -0800 Received: from asbestos.mfsdatanet.com (yellowrose.MFSDatanet.COM) by venera.isi.edu (5.65c/5.61+local-22) id <AA28268>; Mon, 18 Dec 1995 00:02:56 -0800 Received: from MFST.COM (tweek.MFSDatanet.COM) by MFSDatanet.COM (4.1/SMI-4.1 - MFS Datanet Jun93 - wcm) id AA22906; Mon, 18 Dec 95 02:02:48 CST Received: (from loco@localhost) by MFST.COM (8.7.3/8.7.3) id AAA02025; Mon, 18 Dec 1995 00:02:47 -0800 (PST) Date: Mon, 18 Dec 1995 00:02:46 -0800 (PST) From: Jonathan Heiliger <loco@mfst.com> X-Sender: loco@tweek.mfsdatanet.com To: mbone Subject: RINT/TINT messages with ipmulti-3.5? Message-Id: <Pine.SUN.3.91.951217235604.2021A-100000@tweek.mfsdatanet.com> X-Secure: None Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm sure there's some easy answer for this, however, I have yet to stumble across it. While upgrading our main external MBONE machine from an old mrouted and ipmulti-3.3 (I believe) to a kernel with the 3.5 kernel patches; the following dumped itself in the syslog. The machine works fine with the older kernel/multicast patches; as do other "identical" machines in the same configuration. The workstation is running SunOS 4.1.3_U1 and is of sun4m architecture. The ethernet interfaces are actual le(N) cards in an IPX chassis. The error message below seems to occur when traffic is passed through the le1 interface and does not occur on other interfaces; where both normal unicast and multicast traffic is going through. Dec 15 18:57:20 wdcmon vmunix: le1: RINT but buffer owned by LANCE Dec 15 18:57:20 wdcmon vmunix: le1: TINT but buffer owned by LANCE Dec 15 18:57:20 wdcmon vmunix: le1: RINT but buffer owned by LANCE Dec 15 18:57:22 wdcmon vmunix: le1: RINT but buffer owned by LANCE Dec 15 18:57:23 wdcmon vmunix: le1: TINT but buffer owned by LANCE Dec 15 18:57:23 wdcmon vmunix: le1: RINT but buffer owned by LANCE Thoughts/comments/solutions/pointers to docs would be appreciated. thanks! \|/ _____ \|/ Jonathan Heiliger @~/ . . \~@ MFS Global Network Services, Inc. ________________________/_( \___/ )_\______________________________________ \__U__/ E-Mail: loco@mfst.com Data Services Network Engineering From list-mgr@ISI.EDU Sun Dec 17 23:36:18 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00953>; Mon, 18 Dec 1995 01:41:26 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00882>; Mon, 18 Dec 1995 01:36:28 -0800 Received: from nic.hq.cic.net by venera.isi.edu (5.65c/5.61+local-22) id <AA00874>; Mon, 18 Dec 1995 01:36:25 -0800 Received: (from dorian@localhost) by nic.hq.cic.net (8.7.3/8.6.12) id EAA20976; Mon, 18 Dec 1995 04:36:18 -0500 (EST) Date: Mon, 18 Dec 1995 04:36:18 -0500 (EST) From: Dorian Kim <dorian@CIC.Net> X-Sender: dorian@nic.hq.cic.net To: mbone Subject: Tunnels that cross MCI Message-Id: <Pine.OSF.3.91.951218041503.15672S-100000@nic.hq.cic.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII (CICNET-NS[davros.acs.ohio-state.edu]:OARNET-MAINT-MCI[oeb4-e0/0.columbus.oar.ne t]) may be routed thru MCI (OARNET-MAINT-MCI[oeb3-e0.columbus.oar.net]:CICNET-NS[davros.acs.ohio-state.edu] ) may be routed thru MCI (OARNET-MAINT-MCI[oeb3-e0.columbus.oar.net]:CICNET-NS[bedrock.osc.edu]) may be routed thru MCI (CICNET-NS[bedrock.osc.edu]:OARNET-MAINT-MCI[oeb3-e0.columbus.oar.net]) may be routed thru MCI These tunnels may/may not exist, but they do not cross MCI, as CICNet peers directly with OARNet. (MERIT-MAINT-MCI[mbone.merit.edu]:CICNET-NS[tibia.cic.net]) may be routed thru MCI For various reasons, this one will be kept. (SESQUINET-MAINT-MCI[VINEGAR.SESQUI.NET]:CICNET-NS[tibia.cic.net]) may be routed thru MCI This is gone, as per Stan's message. (unknown[198.17.46.57]:CICNET-NS[192.5.200.125]) may be routed thru MCI (SCINET-MAINT-MCI[nwacse-h1r5e.sd.supercomp.org]:CICNET-NS[192.5.200.125]) may be routed thru MCI (SCINET-MAINT-MCI[kiosk3-h3p3e.sd.supercomp.org]:CICNET-NS[192.5.200.125]) may be routed thru MCI (SURA[lex-mp1.sura.net]:CICNET-NS[r-s-hub-1.fnal.gov]) may be routed thru MCI (CICNET-NS[dino.ctd.anl.gov]:MID-MAINT-MCI[147.155.32.31]) may be routed thru MCI (CICNET-NS[sgi10.hep.anl.gov]:NWNET-MAINT-MCI[mbone-seattle.nwnet.net]) may be routed thru MCI Above are ESNet sites. We peer with them directly. However, these tunnels originate within ESNet, so they are not within our administrative scope. In any case, the first three tunnels do not exist anymore. (MRNET-MAINT-MCI[noc.msc.net]:CICNET-NS[ir5.msi.umn.edu]) may be routed thru MCI (MRNET-MAINT-MCI[noc.msc.net]:CICNET-NS[nonabel.geom.umn.edu]) may be routed thru MCI (CICNET-NS[nonabel.geom.umn.edu]:MRNET-MAINT-MCI[noc.msc.net]) may be routed thru MCI The above should be local tunnels, and should not cross MCI. (CICNET-NS[alumni.cs.uwm.edu]:RGNET-MAINT-MCI[rah.star-gate.com]) may be routed thru MCI This tunnels does not exist. (CICNET-NS[141.142.121.32]:MAINT-AS194[mbone.ucar.edu]) may be routed thru MCI This tunnel could be turned off. I will contact site admin to see if this can be done. (CICNET-NS[141.142.121.32]:PSC-MAINT-MCI[pioneer-72.psc.edu]) may be routed thru MCI Ditto, although this tunnel is currently down, and might be a historical entry. Jeff, with exception of the two above, you can remove all CICNet tunnels from your list. I'll let you know about the two above when I have a status on them. -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From list-mgr@ISI.EDU Mon Dec 18 01:25:52 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04047>; Mon, 18 Dec 1995 05:29:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA03997>; Mon, 18 Dec 1995 05:25:56 -0800 Received: from achilles.ctd.anl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA03990>; Mon, 18 Dec 1995 05:25:53 -0800 Received: (from curtis@localhost) by achilles.ctd.anl.gov (8.6.11/8.6.11) id HAA14857 for mbone@isi.edu; Mon, 18 Dec 1995 07:25:52 -0600 Date: Mon, 18 Dec 1995 07:25:52 -0600 Message-Id: <199512181325.HAA14857@achilles.ctd.anl.gov> To: mbone Subject: Re: Tunnels that cross MCI From: "Jeffrey S. Curtis" <curtis@anl.gov> Dorian Kim writes: } [...] }(SCINET-MAINT-MCI[nwacse-h1r5e.sd.supercomp.org]:CICNET-NS[192.5.200.125]) }may be routed thru MCI }(SCINET-MAINT-MCI[kiosk3-h3p3e.sd.supercomp.org]:CICNET-NS[192.5.200.125]) }may be routed thru MCI }(SURA[lex-mp1.sura.net]:CICNET-NS[r-s-hub-1.fnal.gov]) may be routed thru MCI }(CICNET-NS[dino.ctd.anl.gov]:MID-MAINT-MCI[147.155.32.31]) may be routed }thru MCI }(CICNET-NS[sgi10.hep.anl.gov]:NWNET-MAINT-MCI[mbone-seattle.nwnet.net]) }may be routed thru MCI }Above are ESNet sites. We peer with them directly. However, these tunnels }originate within ESNet, so they are not within our administrative scope. }In any case, the first three tunnels do not exist anymore. [...] And the last two (involving anl.gov nodes) never have existed. dino has never and will never do DVMRP, although it does do PIM. sgi10 used to do DVMRP (up until 11 months ago) but is just an end-user machine these days. It would appear that whatever process generated these reports used severely flawed logic. Jeff -- Jeffrey S. Curtis | Internetwork Manager Argonne National Laboratory | Email: curtis@anl.gov 9700 South Cass Avenue, ECT-221 | Voice: 708/252-1789 Argonne, IL 60439 | Fax: 708/252-9689 From list-mgr@ISI.EDU Mon Dec 18 19:57:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13935>; Mon, 18 Dec 1995 10:00:31 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA13908>; Mon, 18 Dec 1995 10:00:02 -0800 Received: from rumms.uni-mannheim.de by venera.isi.edu (5.65c/5.61+local-22) id <AA13892>; Mon, 18 Dec 1995 09:59:51 -0800 Received: from pi4.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA15170 (5.65c/IDA-1.4.4 for <mbone@ISI.EDU>); Mon, 18 Dec 1995 19:00:07 +0100 Received: from pythagoras.informatik.uni-mannheim.de (pythagoras.informatik.uni-mannheim.de [134.155.48.119]) by pi4.informatik.uni-mannheim.de (8.7.3/8.7.3) with ESMTP id SAA05293 for <mbone@ISI.EDU>; Mon, 18 Dec 1995 18:59:31 +0100 Received: (from geyer@localhost) by pythagoras.informatik.uni-mannheim.de (8.7.3/8.7.3) id SAA28263; Mon, 18 Dec 1995 18:57:02 +0100 (MET) Date: Mon, 18 Dec 1995 18:57:02 +0100 (MET) Message-Id: <199512181757.SAA28263@pythagoras.informatik.uni-mannheim.de> From: Werner Geyer <geyer@pi4.informatik.uni-mannheim.de> To: mbone Subject: wbimport Hi! Does anybody know if there is a way to import bitmaps (gif, etc.) into wb? Thanks, Werner From list-mgr@ISI.EDU Mon Dec 18 07:20:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17777>; Mon, 18 Dec 1995 11:17:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17747>; Mon, 18 Dec 1995 11:17:26 -0800 Received: from freenet.mb.ca (winnie.freenet.mb.ca) by venera.isi.edu (5.65c/5.61+local-22) id <AA17739>; Mon, 18 Dec 1995 11:17:23 -0800 Received: by freenet.mb.ca (5.x/SMI-SVR4) id AA20062; Mon, 18 Dec 1995 13:20:11 -0600 Date: Mon, 18 Dec 1995 13:20:09 -0600 (CST) From: Michael Lau <ryp631@freenet.mb.ca> To: mbone Subject: mbone for NT Message-Id: <Pine.SOL.3.91.951218131914.18049C-100000@winnie.freenet.mb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi: Where are the MBONE apps for NT? I've read several MBONE FAQs but still no luck. TIA. Mike From list-mgr@ISI.EDU Mon Dec 18 20:55:41 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22832>; Mon, 18 Dec 1995 12:56:51 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22795>; Mon, 18 Dec 1995 12:56:12 -0800 Received: from v2.ph.gla.ac.uk ([194.36.1.69]) by venera.isi.edu (5.65c/5.61+local-22) id <AA22788>; Mon, 18 Dec 1995 12:56:08 -0800 Received: from v2.ph.gla.ac.uk by v2.ph.gla.ac.uk with SMTP; Mon, 18 Dec 1995 20:55:53 GMT Date: Mon, 18 Dec 1995 20:55:41 +0000 From: "Alan J. Flavell" <FLAVELL@v2.ph.gla.ac.uk> Reply-To: A.Flavell@physics.gla.ac.uk To: Werner Geyer <geyer@pi4.informatik.uni-mannheim.de> Cc: mbone Subject: Re: wbimport In-Reply-To: <199512181757.SAA28263@pythagoras.informatik.uni-mannheim.de> Message-Id: <Pine.VMS.3.91-vms-b4.951218205313.1213A-100000@v2.ph.gla.ac.uk> Organization: Glasgow University Particle Physics Group Phone: +44 141 330 5454 - fax 334 9029 Organization: Legio Carborundum Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 18 Dec 1995, Werner Geyer wrote: > Does anybody know if there is a way > to import bitmaps (gif, etc.) into wb? as far as I know, wb only wants to import postscript. There are many ways to convert images into postscript, but the resulting files can get large and this is very bad for wb. Check the notes that come with wb distribution about compressing postscript. good luck. From list-mgr@ISI.EDU Mon Dec 18 23:29:39 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26348>; Mon, 18 Dec 1995 14:04:32 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26319>; Mon, 18 Dec 1995 14:04:05 -0800 Received: from Nomina.lu.se by venera.isi.edu (5.65c/5.61+local-22) id <AA26310>; Mon, 18 Dec 1995 14:04:02 -0800 Received: from Gemini.ldc.lu.se by nomina.lu.se with SMTP (5.65/IDA-1.2.8) id AA13727; Mon, 18 Dec 95 23:08:20 +0100 Received: from gemini.ldc.lu.se by gemini.ldc.lu.se (PMDF V4.2-14 #10923) id <01HYYW03EFRK004ZKZ@gemini.ldc.lu.se>; Mon, 18 Dec 1995 23:02:58 +0100 Date: Mon, 18 Dec 1995 22:29:39 +0100 From: Jan Engvald LDC <Jan.Engvald@LDC.lu.se> Subject: RE: wbimport In-Reply-To: Your message dated "Mon, 18 Dec 1995 20:55:41 +0000" <Pine.VMS.3.91-vms-b4.951218205313.1213A-100000@v2.ph.gla.ac.uk> To: A.Flavell@physics.gla.ac.uk Cc: mbone, Jan Engvald LDC <XJELDC@gemini.ldc.lu.se> Message-Id: <01HYYXC9JPH0004ZKZ@gemini.ldc.lu.se> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT >> Does anybody know if there is a way >> to import bitmaps (gif, etc.) into wb? > >as far as I know, wb only wants to import postscript. >There are many ways to convert images into postscript, but the resulting >files can get large and this is very bad for wb. Check the notes that >come with wb distribution about compressing postscript. I would like to propose a new protocol for wb-like functions, in case someone wants to write something new. How about using differential HTML (a NEW protocol that I have now proposed and I've not seen mentioned before). That is, at any time the wb screen is defined by a local HTML file. These HTML files are synchronized among the participants. If someone makes a change in his local wb window, a new local HTML file is generated and the difference between this and the previous HTML file is sent to the other participants. Graphic information should use differential JPEG, which should allow one to extend a picture along all edges as well as exchange squares within the current picture. I don't have a precise description of these protocols, anyone that wants to do so, please do. The HTML diff protocol could perhaps just use the Unix diff utility. And the differential JPEG could consist of a number of 8*8 pixels squares JPEG coded and a vector of coordinates telling where these squares should be placed relative to the current picture. This whiteboard protocol should be easy to interface to other utilities on any platform (Unix, PC, Mac) because at any time the local wb file is a valid HTML file, a very popular format these days. It should thus be easy to import and export to/from the wb window. Does it sound feasible? Jan Engvald, Lund University Computing Center ________________________________________________________________________ Address: Box 783 E-mail: Jan.Engvald@ldc.lu.se S-220 07 LUND Earn/Bitnet: XJELDC@SELUND SWEDEN VAXPSI: psi%2403732202020::xjeldc Office: Soelvegatan 18 X.400: S=Engvald/G=Jan/O=ldc/ Telephone: +46 46 2227458 PRMD=lu/ADMD=sunet/C=se Telefax: +46 46 138225 WWW: http://www.lu.se/ From list-mgr@ISI.EDU Mon Dec 18 06:11:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26608>; Mon, 18 Dec 1995 14:10:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26597>; Mon, 18 Dec 1995 14:10:21 -0800 Received: from mailhost.Ipsilon.COM (foo-5-10.Ipsilon.COM) by venera.isi.edu (5.65c/5.61+local-22) id <AA26585>; Mon, 18 Dec 1995 14:10:19 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id OAA24992 for <mbone@ISI.EDU>; Mon, 18 Dec 1995 14:10:07 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: <v02130502acfb96705def@[205.226.1.20]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Dec 1995 14:11:03 -0800 To: mbone From: hinden@Ipsilon.COM (Bob Hinden) Subject: Re: mBone may be flooded I sent some email to Connectix regarding their support for IP multicast in their VideoPhone product and received the following reply: >> It is refreshing to talk to an informed user! Yes Connectix >>VideoPhone for Windows supports IP Multicast through IGMP as defined in RFC >>1112. Connectix VideoPhone requires that the TCP/IP stack you are using also >>supports IGMP. Today we have support for IGMP through Microsoft's MS/TCP-32 >>(WFW and Win95), TGV's MultiNet and FTP's OnNet. It would seem that they do support IP multicast. In a subsequent message they said they are not compatible with nv, vat, etc. Bob From list-mgr@ISI.EDU Tue Dec 19 18:54:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29125>; Tue, 19 Dec 1995 22:55:59 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA29106>; Tue, 19 Dec 1995 22:54:06 -0800 Received: from achilles.ctd.anl.gov by venera.isi.edu (5.65c/5.61+local-22) id <AA29099>; Tue, 19 Dec 1995 22:54:04 -0800 Received: (from curtis@localhost) by achilles.ctd.anl.gov (8.6.11/8.6.11) id AAA23519 for mbone@isi.edu; Wed, 20 Dec 1995 00:54:03 -0600 Date: Wed, 20 Dec 1995 00:54:03 -0600 Message-Id: <199512200654.AAA23519@achilles.ctd.anl.gov> To: mbone Subject: SPARC 5s and quad ethernets From: "Jeffrey S. Curtis" <curtis@anl.gov> We know that the ipmulti patches do not work with SPARC 5s and the 10base2+AUI style sbus NIC. Does anyone know for sure whether the quad ethernet (qe) sbus NICs work with the SPARC 5 and the ipmulti patches? Thanks, Jeff -- Jeffrey S. Curtis | Internetwork Manager Argonne National Laboratory | Email: curtis@anl.gov 9700 South Cass Avenue, ECT-221 | Voice: 708/252-1789 Argonne, IL 60439 | Fax: 708/252-9689 From list-mgr@ISI.EDU Wed Dec 20 09:29:35 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00817>; Tue, 19 Dec 1995 23:55:35 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00799>; Tue, 19 Dec 1995 23:54:09 -0800 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA00771>; Tue, 19 Dec 1995 23:53:03 -0800 Received: from lumiere.idris.fr by quark.isi.edu (5.65c/5.61+local-20) id <AA02106>; Tue, 19 Dec 1995 23:52:43 -0800 Received: from sailor.idris.fr (rugeri@sailor.idris.fr [130.84.12.91]) by lumiere.idris.fr (8.7.3/8.7.3) with ESMTP id IAA10504 for <mbone@ISI.EDU>; Wed, 20 Dec 1995 08:29:36 +0100 Received: (from rugeri@localhost) by sailor.idris.fr (8.7.3/8.7.3) id IAA51048; Wed, 20 Dec 1995 08:29:35 +0100 From: Marc Rugeri <rugeri@idris.fr> Message-Id: <199512200729.IAA51048@sailor.idris.fr> To: mbone Date: Wed, 20 Dec 95 08:29:35 +0100 LISt SIGnoff mbone@ISI.EDU From list-mgr@ISI.EDU Wed Dec 20 08:58:16 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01023>; Wed, 20 Dec 1995 00:01:04 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00840>; Tue, 19 Dec 1995 23:57:50 -0800 Received: from rc4.vub.ac.be (mailhost.vub.ac.be) by venera.isi.edu (5.65c/5.61+local-22) id <AA00833>; Tue, 19 Dec 1995 23:57:46 -0800 Received: from rc1.vub.ac.be (rc1 [134.184.15.1]) by rc4.vub.ac.be (8.6.10/3.4.2.ap (rc4)) id JAA14217; Wed, 20 Dec 1995 09:01:09 +0100 Received: from ipb0.ulb.ac.be by rc1.vub.ac.be (5.x/VUB-SOLARIS.920228) id AA20549; Wed, 20 Dec 1995 08:57:37 +0100 Received: from ipbu1.ulb.ac.be by ipb0.ulb.ac.be (5.x/ULB.940202) id AA02033; Wed, 20 Dec 1995 09:02:19 GMT Received: by ipbu1.ulb.ac.be (5.x/SMI-SVR4) id AA07792; Wed, 20 Dec 1995 08:58:16 GMT From: sciocea@ipb0.ulb.ac.be (Sorin Ciocea) Message-Id: <9512200858.AA07792@ipbu1.ulb.ac.be> Subject: To: mbone Date: Wed, 20 Dec 1995 08:58:16 +0000 (WET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text help From list-mgr@ISI.EDU Thu Dec 21 09:44:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16527>; Thu, 21 Dec 1995 11:45:11 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16405>; Thu, 21 Dec 1995 11:44:00 -0800 Received: from gaboon.nai.net by venera.isi.edu (5.65c/5.61+local-22) id <AA16392>; Thu, 21 Dec 1995 11:43:57 -0800 Received: (from asv@localhost) by gaboon.nai.net (8.6.12/8.6.12) id OAA06583 for mbone@ISI.EDU; Thu, 21 Dec 1995 14:44:17 -0500 From: Stan Voket <asv@gaboon.nai.net> Message-Id: <199512211944.OAA06583@gaboon.nai.net> Subject: tunnel wanted To: mbone Date: Thu, 21 Dec 1995 14:44:17 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 380 Hi, I'm just getting some mbone apps up here, along with mrouted 3.8 and need a tunnel for testing. The endpoint our mrouted) will be 204.71.31.225 gaboon.nai.net. I am here in Western CT newar Danbury. Thanks, Stan -- - Stan Voket, asv@gaboon.nai.net - http://gaboon.nai.net - - Voice: 203.746-4489 - FAX 203.746.9761 - TELEX 969.642/CARIN DURY - From list-mgr@ISI.EDU Thu Dec 21 12:03:12 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01656>; Thu, 21 Dec 1995 16:05:52 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA01256>; Thu, 21 Dec 1995 16:00:30 -0800 Received: from freenet.mb.ca (winnie.freenet.mb.ca) by venera.isi.edu (5.65c/5.61+local-22) id <AA01245>; Thu, 21 Dec 1995 16:00:28 -0800 Received: by freenet.mb.ca (5.x/SMI-SVR4) id AA20115; Thu, 21 Dec 1995 18:03:18 -0600 Date: Thu, 21 Dec 1995 18:03:12 -0600 (CST) From: Michael Lau <ryp631@freenet.mb.ca> To: mbone Subject: mbone for NT, 2nd try Message-Id: <Pine.SOL.3.91.951221175354.18860B-100000@winnie.freenet.mb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi All: Where are the MBONE apps for NT? Some of you gurus have said you have developed some apps. We don't want to reinvent the wheel! Can we talk, in private or on this list? Happy Holidays. Mike From list-mgr@ISI.EDU Thu Dec 21 17:36:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16207>; Thu, 21 Dec 1995 19:44:15 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16116>; Thu, 21 Dec 1995 19:38:54 -0800 Received: from mercury.thepoint.net by venera.isi.edu (5.65c/5.61+local-22) id <AA16109>; Thu, 21 Dec 1995 19:38:52 -0800 Received: by mercury.thepoint.net (8.6.12/) id WAA08429; Thu, 21 Dec 1995 22:36:28 -0500 Date: Thu, 21 Dec 1995 22:36:28 -0500 (EST) From: Arlie Davis <arlie@thepoint.net> To: Michael Lau <ryp631@freenet.mb.ca> Cc: mbone Subject: Re: mbone for NT, 2nd try In-Reply-To: <Pine.SOL.3.91.951221175354.18860B-100000@winnie.freenet.mb.ca> Message-Id: <Pine.BSF.3.91.951221222715.8293A-100000@mercury.thepoint.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm working on developing multicast tools for NT and 95. Nothing that I have is anywhere near useable, except for my NT port of the CU See Me reflector. (I only mention it here because of the multicast support.) NV and VAT are on the top of my list. NV (receive only) is going to be easier than VAT, at least until I learn more about the strange media API. Support for Video for Windows for image transmission is very high on my list of stuff to do... Oh -- one tool seems so trivial I didn't think of it. I wrote a simple version of SD for NT. If anyone wants it, I'll post it. Feel free to send me encouraging words, pointers to interesting information about protocol specs, API specs, working source code, etc. I certainly do _not_ want to reinvent the wheel. I'd love to build the perfect spoke for another wheel, or convert a wheel from another car to this one, etc. If you have already developed an MBONE app for NT, please let me know so that effort is not duplicated. -- arlie On Thu, 21 Dec 1995, Michael Lau wrote: > Hi All: > > Where are the MBONE apps for NT? Some of you gurus have said you have > developed some apps. We don't want to reinvent the wheel! Can we talk, in > private or on this list? > > Happy Holidays. > Mike > > > > > > > > From list-mgr@ISI.EDU Thu Dec 21 11:37:48 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22259>; Thu, 21 Dec 1995 23:41:24 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA22224>; Thu, 21 Dec 1995 23:37:53 -0800 Received: from mpg.phys.Hawaii.Edu by venera.isi.edu (5.65c/5.61+local-22) id <AA22217>; Thu, 21 Dec 1995 23:37:51 -0800 Received: by mpg.phys.hawaii.edu (4.1/SMI-4.1) id AA00280; Thu, 21 Dec 95 21:37:49 HST Date: Thu, 21 Dec 1995 21:37:48 -1000 (HST) From: Antonio Querubin <tony@mpg.phys.hawaii.edu> To: mbone Subject: Milnet MBone admin? Message-Id: <Pine.SUN.3.90.951221213413.273A-100000@mpg.phys.hawaii.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is there anyone coordinating MBone tunnels within Milnet/NIPRNet? I'd like to setup a tunnel to 192.133.71.7. I've just gotten mrouted 3.8 installed and running on it. Antonio Querubin tony@mpg.phys.hawaii.edu / ah6bw@hawaii.ampr.org From list-mgr@ISI.EDU Fri Dec 22 03:39:14 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02977>; Fri, 22 Dec 1995 07:38:25 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02925>; Fri, 22 Dec 1995 07:36:32 -0800 Received: from freenet.mb.ca (winnie.freenet.mb.ca) by venera.isi.edu (5.65c/5.61+local-22) id <AA02917>; Fri, 22 Dec 1995 07:36:29 -0800 Received: by freenet.mb.ca (5.x/SMI-SVR4) id AA11581; Fri, 22 Dec 1995 09:39:19 -0600 Date: Fri, 22 Dec 1995 09:39:14 -0600 (CST) From: Michael Lau <ryp631@freenet.mb.ca> To: iwntug@iwntug.org, mbone Subject: Season's Greetings (fwd) Message-Id: <Pine.SOL.3.91.951222093337.10058B-100000@winnie.freenet.mb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Captain James has such a way with words. Happy Holidays, Mike ---------- Forwarded message ---------- Date: Thu, 21 Dec 1995 22:53:25 -0500 From: CaptJHEM@aol.com To: TALLSHIP%vccscent.BITNET@pucc.princeton.edu, cbay-l@listproc.hcf.jhu.edu, YACHT-L@hearn.nic.surfnet.nl, live-aboard@centaur.astro.utoronto.ca Subject: Season's Greetings Friends, $$ $$ $$ $$ $$b d$$ $$$b d$$$ ,$$$$$$$$$ __ d$$ $$$ $$ d$$b $$' `Y' $$ d$$$b $$$$$$'`$$$$$$' $$ $$ d$'dP d$P Y$b t$__$$ $$ $$ $$ $$ $$ $$ $$ d$P `Y$b d$""' $$ $$ $$ $$ $$ $$ Y$$$$$P `$$bd$$b..,d$$ 4$.,$$ $$.,d$$bd$$ d$) `4$P' `Y$P'"Y$$$$P' `$$$P' `$$$P'`""$$$$P d$$P d$$$ $$ $$ $$ $$ d$$b `$W$' d$P""Y$b d$$b ~ $$' $P ,d$""$$. d$' $b dY' d$' $$b $$ ,d$$$b $$ Y$P' $$ ,d$P $$ ,$$'~`$$ $$ $$ d$Y' $$ H$$$$H $$' $$ $$$$b. . $$ $$b $$ d$$' $$ $$$$$ $$ d$b $$ d$b d$b,$b ,d$$b $$b Y$b ,$P$$ $$ $$ $$ $$ d$^Yb ,$$ ,$$$$$"$$$$$ d$'`$b `$$b Y$b ,d$P'$$ Y$bd$P $$bd$$b_$$' $)$$$.$Y $$' $$ $$. $$.,$$b `$$. `$$$$$P' $$ "$$' "$$P'`Y$P d$P `$$$$' $$ $$ `$$$$"$$$'"$$$) $$) d$P' _.d$P' d$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$P' $$P _____ _,---' `-,_ * `-,_ `-, `-,@@@@@@@@@@ _ @@@@@@@@@@@ (( )) (\_ ;;### ###;; {} \\ // {} _*__ (\_c\ ;; O ( O ;; \\---\/,-{=\ /= /\ \\ \ \ ( ) ;;, (_) ;; Ho Ho Ho .... ~~\\//~~ \\ // \ \ \\ \ @@@@@ ;;//~\\;;; (\_(\ {{=\\//=} ___\_\_\__| \ \ __ ;;;;;;;;_ / (o \\// [==='`____`__ \ / /\ ;;;;; \ \_ ) ) \ <`--'> |_ :~|~~~~~~|__/ /\ \ `, `-,_ ; (`~; ) ('\ |##-,_|@@@@@@| \ \\/\ |_ @-,. __ .&' \ ; ; (/~ |######-,_,__|_,-,\ *\ \=====@) `-,_@,-c).(_(,-'' \&....| ; :; |#########`-----,_`-,\\/_______\::::::-,_ ; ) |_ \ |_&-. ..( |####{}#######|!!!`-,__________):::::::::`-,; @) .{ },-...\\& `) |##{ __}}#####|!!!!!!!!!-,_ `-,::::::::::_//| /(_)( || ; |#{ }##{ }####|!!!!!!!!!!!!`-,_ \::::--,:/!!!/ / \ //,--|: |#{ }###{}####|!!!!!!!!!!!!!!!!`---'!!!!!!!!!!| : ^ ) ;~/ // |##{ }#{ }####|!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!} \ / \ \; / _// |###{_~_}#####|!!!!!!!!!!!!!!!!!!!!!!!!!!!!,-:: /_/ \ \ C_/ |#############|!!!!!!!!!!!!!!!!!!!!!!!!,-`X (( // __// |#############|!!!!!!!!!!!!!!!!!!!!,-`X / \_,-'~ c__/ |#############|!!!!!!!!!!!!!!!!,-`X / \/,-` `;############|!!!!!!!!!!!!,-X / \/,-`~ X`-;########|!!!!!!!!,-'X / \ /,-'~ /_\,-``-;####|!!!!!-'X / \_,-'~ `-' `-;|,-'X / \',-' /,-/,-'~ ooooo ooooo `888' `888' 888 888 .oooo. oo.ooooo. oo.ooooo. oooo ooo 888ooooo888 `P )88b 888' `88b 888' `88b `88. .8' 888 888 .oP"888 888 888 888 888 `88..8' 888 888 d8( 888 888 888 888 888 `888' o888o o888o `Y888""8o 888bod8P' 888bod8P' .8' 888 888 .o..P' o888o o888o `Y8P' ooooo ooo oooooo oooo `888b. `8' `888. .8' 8 `88b. 8 .ooooo.oooo oooo ooo `888. .8'.ooooo. .oooo. oooo d8b 8 `88b. 8 d88' `88b`88. `88. .8' `888.8'd88' `88b`P )88b `888""8P 8 `88b.8 888ooo888 `88..]88..8' `888' 888ooo888 .oP"888 888 8 `888 888 .o `888'`888' 888 888 .od8( 888 888 o8o `8 `Y8bod8P' `8' `8' o888o `Y8bod8P'`Y888""8od888b James From list-mgr@ISI.EDU Fri Dec 22 04:23:54 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04367>; Fri, 22 Dec 1995 08:22:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA04352>; Fri, 22 Dec 1995 08:21:28 -0800 Received: from freenet.mb.ca (winnie.freenet.mb.ca) by venera.isi.edu (5.65c/5.61+local-22) id <AA04345>; Fri, 22 Dec 1995 08:21:26 -0800 Received: by freenet.mb.ca (5.x/SMI-SVR4) id AA15265; Fri, 22 Dec 1995 10:24:00 -0600 Date: Fri, 22 Dec 1995 10:23:54 -0600 (CST) From: Michael Lau <ryp631@freenet.mb.ca> To: Arlie Davis <arlie@thepoint.net> Cc: mbone Subject: Re: mbone for NT, 2nd try In-Reply-To: <Pine.BSF.3.91.951221222715.8293A-100000@mercury.thepoint.net> Message-Id: <Pine.SOL.3.91.951222094442.10058C-100000@winnie.freenet.mb.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Arlie: On Thu, 21 Dec 1995, Arlie Davis wrote: > I'm working on developing multicast tools for NT and 95. Nothing that I > have is anywhere near useable, except for my NT port of the CU See Me > reflector. (I only mention it here because of the multicast support.) This could be very useful due to the inherent advantages/features NT has over Win 3.x/95. > NV and VAT are on the top of my list. NV (receive only) is going to be > easier than VAT, at least until I learn more about the strange media API. > Support for Video for Windows for image transmission is very high on my > list of stuff to do... We are also learning and developing along the Video for Windows concept, but still have not seen light at the end of the tunnel. > Oh -- one tool seems so trivial I didn't think of it. I wrote a simple > version of SD for NT. If anyone wants it, I'll post it. Please. > Feel free to send me encouraging words, pointers to interesting > information about protocol specs, API specs, working source code, etc. > > I certainly do _not_ want to reinvent the wheel. I'd love to build the > perfect spoke for another wheel, or convert a wheel from another car to > this one, etc. If you have already developed an MBONE app for NT, please > let me know so that effort is not duplicated. If the non-NT fans will excuse me for a moment. Before Bill Gates singlehandedly scrooged the other "net" companies 2 weeks ago, one summary I've read mentioned an existing base of 1,000 NT web servers. Even if the actual number is much higher, the installed NT base is still much smaller compared to the other platforms. If Bill managed to get his talented staff to deliver on time, we may see an explosion of NT apps announcements. Bean counters at several Fortune 500 companies have already been convinced by Bill. This couples with University Profs thinking and planning NT purchases will only accelerate the demand for mbone NT apps. Just my 2-bits worth. Happy Holidays. Mike From list-mgr@ISI.EDU Fri Dec 22 06:41:28 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05177>; Fri, 22 Dec 1995 08:42:06 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA05155>; Fri, 22 Dec 1995 08:41:33 -0800 Received: from hnssysa.hns.com by venera.isi.edu (5.65c/5.61+local-22) id <AA05148>; Fri, 22 Dec 1995 08:41:32 -0800 Received: from dpcsys1.hns.com (dpcsys1.hns.com [139.85.33.51]) by hnssysa.hns.com (8.7.1/) with ESMTP id LAA09583 for <mbone@isi.edu>; Fri, 22 Dec 1995 11:41:31 -0500 (EST) Received: from localhost (dillon@localhost) by dpcsys1.hns.com (8.7.1/8.6.12) with SMTP id LAA06922 for <mbone@isi.edu>; Fri, 22 Dec 1995 11:41:32 -0500 (EST) Message-Id: <199512221641.LAA06922@dpcsys1.hns.com> To: mbone Subject: Latest DVMRP protocol specification... Date: Fri, 22 Dec 95 11:41:28 EST From: Doug Dillon <dillon@hns.com> I'm trying to plan some modifications/enhancements to mrouted and would like to find a reasonably complete specification for the version of DVMRP it supports. The old RFC 1075 doesn't seem to cover critical features like pruning. Is there any spec other than the source code for mrouted? Doug Dillon From list-mgr@ISI.EDU Sat Dec 23 05:27:19 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23297>; Sat, 23 Dec 1995 13:29:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23263>; Sat, 23 Dec 1995 13:27:31 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA23256>; Sat, 23 Dec 1995 13:27:29 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id NAA01143; Sat, 23 Dec 1995 13:27:23 -0800 Message-Id: <199512232127.NAA01143@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: mbone Cc: Jason Gabler <ccjason@quadrophenia.ucdavis.edu> Subject: host-1.sedona.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Dec 1995 13:27:19 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Say anyone out there knows if host-1.sedona.com is running mrouted3.8? A friend of mine keeps complaining that his tunnel is flaking out His mrouted.conf has: mrouted.conf tunnel 128.218.114.68 128.120.226.8 And this is an mtrace for his host from my system: mtrace magicbus.ucsf.edu Mtrace from 128.218.114.68 to 204.188.121.18 via group 224.2.0.1 Querying full reverse path... 0 rah.star-gate.com (204.188.121.18) -1 rah.star-gate.com (204.188.121.18) DVMRP thresh^ 1 -2 toad.com (140.174.2.1) DVMRP thresh^ 1 -3 dec3800-2-fddi-1.SanFrancisco.mci.net (204.70.158.77) DVMRP thresh^ 64 -4 MBONE2.UU.NET (137.39.246.98) DVMRP thresh^ 64 -5 ns2.noc.netcom.net (204.31.1.2) DVMRP thresh^ 64 -6 host-1.sedona.com (206.214.47.1) Unknown protocol code 0 thresh^ 0 No route Round trip time 138 ms Waiting to accumulate statistics... Results after 9 seconds: Source Response Dest Packet Statistics For Only For Traffic * * * 204.188.121.18 All Multicast Traffic From 128.218.114.68 v __/ rtt 136 ms Lost/Sent = Pct Rate To 224.2.0.1 0.0.0.0 206.214.47.1 host-1.sedona.com No route v ^ ttl 0 0 0 pps 0 0 pps 204.31.1.2 ns2.noc.netcom.net v ^ ttl 64 0/0 = --% 0 pps 0/0 = --% 0 pps 137.39.246.98 MBONE2.UU.NET v ^ ttl 65 119/166 = 72% 18 pps 0/0 = --% 0 pps 204.70.158.61 204.70.158.77 dec3800-2-fddi-1.SanFrancisco.mci.net v ^ ttl 66 1/21 = 5% 0 pps 0/0 = --% 0 pps 140.174.2.1 toad.com v ^ ttl 67 0/10 = --% 1 pps 0/0 = --% 0 pps 204.188.121.18 rah.star-gate.com v \__ ttl 68 15 0 pps 0 0 pps 204.188.121.18 204.188.121.18 Receiver Query Source Tnks, Amancio From list-mgr@ISI.EDU Sun Dec 24 13:23:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07426>; Sun, 24 Dec 1995 01:23:45 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07413>; Sun, 24 Dec 1995 01:23:16 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA07406>; Sun, 24 Dec 1995 01:23:13 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id LAA23611; Sun, 24 Dec 1995 11:23:01 +0200 Date: Sun, 24 Dec 1995 11:23:01 +0200 Message-Id: <199512240923.LAA23611@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: mbone, Jason Gabler <ccjason@quadrophenia.ucdavis.edu> Subject: host-1.sedona.com In-Reply-To: <199512232127.NAA01143@rah.star-gate.com> References: <199512232127.NAA01143@rah.star-gate.com> Amancio Hasty, Jr. writes: > > Say anyone out there knows if host-1.sedona.com is running mrouted3.8? > A friend of mine keeps complaining that his tunnel is flaking out > The host-1.sedona.com (just run mrinfo on it) run's little oldish version (looking at the DVMRP side) version of Cisco IOS: silver:/home/pete(81)% mrinfo host-1.sedona.com 206.214.47.1 (host-1.sedona.com) [version 11.0,mtrace]: 206.214.47.1 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] 206.214.47.1 -> 204.31.1.2 (ns2.noc.netcom.net) [1/0/tunnel/querier] Where the mtrace support is not at it's best. Upgrading to 11.0(3.6) will bring you DVMRP pruning and most likely working mtrace for your case. Pete From list-mgr@ISI.EDU Wed Dec 23 17:29:01 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07585>; Sun, 24 Dec 1995 01:29:43 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07574>; Sun, 24 Dec 1995 01:29:18 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA07567>; Sun, 24 Dec 1995 01:29:17 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id BAA00583; Sun, 24 Dec 1995 01:29:01 -0800 Message-Id: <199512240929.BAA00583@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Petri Helenius <pete@sms.fi> Cc: mbone, Jason Gabler <ccjason@quadrophenia.ucdavis.edu> Subject: Re: host-1.sedona.com In-Reply-To: Your message of "Sun, 24 Dec 1995 11:23:01 +0200." <199512240923.LAA23611@silver.sms.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Dec 1995 01:29:01 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Tnks for the info. Is just that the router (host-1) is acting up around here and a couple of FreeBSD folks who are running mrouted3.8 are having problems connecting to the mbone due to host-1.sedona.com . I hope someone can find the time to upgrade host-1.sedona.com Tnks, Amancio >>> Petri Helenius said: > Amancio Hasty, Jr. writes: > > > > Say anyone out there knows if host-1.sedona.com is running mrouted3.8? > > A friend of mine keeps complaining that his tunnel is flaking out > > > The host-1.sedona.com (just run mrinfo on it) run's little oldish version > (looking at the DVMRP side) version of Cisco IOS: > > silver:/home/pete(81)% mrinfo host-1.sedona.com > 206.214.47.1 (host-1.sedona.com) [version 11.0,mtrace]: > 206.214.47.1 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] > 206.214.47.1 -> 204.31.1.2 (ns2.noc.netcom.net) [1/0/tunnel/querier] > > Where the mtrace support is not at it's best. Upgrading to 11.0(3.6) will > bring you DVMRP pruning and most likely working mtrace for your case. > > Pete From list-mgr@ISI.EDU Sun Dec 24 13:34:27 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07775>; Sun, 24 Dec 1995 01:35:03 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA07644>; Sun, 24 Dec 1995 01:34:35 -0800 Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA07637>; Sun, 24 Dec 1995 01:34:33 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id LAA23640; Sun, 24 Dec 1995 11:34:27 +0200 Date: Sun, 24 Dec 1995 11:34:27 +0200 Message-Id: <199512240934.LAA23640@silver.sms.fi> From: Petri Helenius <pete@sms.fi> To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: mbone Subject: Re: host-1.sedona.com In-Reply-To: <199512240929.BAA00583@rah.star-gate.com> References: <199512240923.LAA23611@silver.sms.fi> <199512240929.BAA00583@rah.star-gate.com> Amancio Hasty, Jr. writes: > Tnks for the info. Is just that the router (host-1) is acting up around here > and a couple of FreeBSD folks who are running mrouted3.8 are having > problems connecting to the mbone due to host-1.sedona.com . > > I hope someone can find the time to upgrade host-1.sedona.com > I wonder why? That's a obviously a leaf node? It must be because it's peer (ns2.noc.netcom.net) is running 3.6 mrouted and the bogus routes might be still around. If the problem is mrouted-related at all. Pete From list-mgr@ISI.EDU Mon Dec 25 23:31:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA06052>; Tue, 26 Dec 1995 07:31:46 -0800 Received: from blob.best.net by venera.isi.edu (5.65c/5.61+local-22) id <AA06045>; Tue, 26 Dec 1995 07:31:44 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by blob.best.net (8.6.12/8.6.5) with SMTP id HAA04297; Tue, 26 Dec 1995 07:31:42 -0800 Date: Tue, 26 Dec 1995 07:31:42 -0800 Message-Id: <199512261531.HAA04297@blob.best.net> X-Sender: rsf@pop.best.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone-na From: Ross Finlayson <finlayson@live.com> Subject: Looking for a tunnel from alter.net Cc: karl@best.com My network's ISP - Best Internet Communications - would like to set up a MBone tunnel to alter.net, to which it is directly attached. (We're also planning on getting a tunnel from MCI.) If anyone on alter.net (preferably ca.alter.net) or one of its directly-attached customers would be willing to set up a tunnel to us, please contact me (finlayson@live.com) and Karl Mueller (karl@best.com). Ross. From list-mgr@ISI.EDU Tue Dec 26 06:18:57 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16794>; Tue, 26 Dec 1995 14:19:50 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16786>; Tue, 26 Dec 1995 14:19:07 -0800 Received: from nic.cerf.net by venera.isi.edu (5.65c/5.61+local-22) id <AA16779>; Tue, 26 Dec 1995 14:19:06 -0800 Received: (from deiss@localhost) by nic.cerf.net (8.6.10/8.6.9) id OAA10822; Tue, 26 Dec 1995 14:18:57 -0800 Date: Tue, 26 Dec 1995 14:18:57 -0800 (PST) From: "Stephen R. Deiss" <deiss@CERF.NET> To: mbone Cc: deiss@cerfnet.com Subject: MOSPF (fwd) Message-Id: <Pine.SUN.3.91.951226141824.10654A-100000@nic.cerf.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Can you direct me to a paper or TR describing the details of the MOSPF protocol and the DVMRP scheme? I am interested in the details as it pertains to routing, bridging etc. Steve D, deiss@cerfnet.com, (619) 944-8859 (FAX 619-944-8880), (Applied Neurodynamics, 345 Via Montanosa, Encinitas, CA 92024-5354) ____ /\ / / / \ / / .-----/--------\--------/----- / / \ / /____ / \/ From list-mgr@ISI.EDU Tue Dec 26 12:47:13 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26391>; Tue, 26 Dec 1995 20:48:49 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26376>; Tue, 26 Dec 1995 20:47:29 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA26369>; Tue, 26 Dec 1995 20:47:27 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id UAA07336 for <mbone@ISI.EDU>; Tue, 26 Dec 1995 20:47:13 -0800 Message-Id: <199512270447.UAA07336@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: mbone Subject: ns2.noc.netcom.net & isengard.barrnet.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Dec 1995 20:47:13 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> 204.31.1.2 (ns2.noc.netcom.net) [version 3.6,prune,genid,mtrace]: 192.216.178.67 (isengard.barrnet.net) [version 3.3]: Does anyone have contacts for the above systems . I will be nice if they can upgrade to mrouted3.8... In the case of netcom, I already sent a few messages to them and they still are running mrouted3.6... Tnks, Amancio From list-mgr@ISI.EDU Wed Dec 27 22:50:38 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26557>; Tue, 26 Dec 1995 20:52:57 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA26545>; Tue, 26 Dec 1995 20:52:19 -0800 Received: from sol.nuri.net by venera.isi.edu (5.65c/5.61+local-22) id <AA26538>; Tue, 26 Dec 1995 20:52:17 -0800 Received: from sosaria.inet.co.kr (sosaria.inet.co.kr [203.255.113.40]) by sol.nuri.net (8.6.12H1/8.6.9) with SMTP id NAA08629; Wed, 27 Dec 1995 13:47:05 +0900 Message-Id: <2.2.32.19951227045038.006fa98c@sol.nuri.net> X-Sender: sosarian@sol.nuri.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Dec 1995 13:50:38 +0900 To: young@mci.net From: Kyungsoon Park <sosarian@nuri.net> Subject: firewall again Cc: mbone Hi, Merry Christmas! (it's too late... :-)) I asked you about firewall problem. But, did you forget my email? Please tell me how can I configure our router which is installed firewall. Thanks. Sosarian From list-mgr@ISI.EDU Wed Dec 27 09:39:29 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17734>; Wed, 27 Dec 1995 11:40:35 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA17713>; Wed, 27 Dec 1995 11:40:09 -0800 Received: from andy.dia.atd.net by venera.isi.edu (5.65c/5.61+local-22) id <AA17703>; Wed, 27 Dec 1995 11:40:06 -0800 Received: (from crobson@localhost) by andy.dia.atd.net (8.6.9/8.6.9) id OAA01590; Wed, 27 Dec 1995 14:39:29 -0500 Date: Wed, 27 Dec 1995 14:39:29 -0500 (EST) From: Chris Robson ATDNet Admin <crobson@andy.dia.atd.net> To: mbone Subject: NV or VIC for Video Blaster RT300? Message-Id: <Pine.SUN.3.91.951227143656.1585A-100000@andy.dia.atd.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Anyone ported these apps to the Creative Labs Video Blaster frame capture board "RT300"? tks.....Chris From list-mgr@ISI.EDU Thu Dec 28 22:20:02 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12574>; Wed, 27 Dec 1995 20:21:46 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA12562>; Wed, 27 Dec 1995 20:20:55 -0800 Received: from TYO2.gate.nec.co.jp by venera.isi.edu (5.65c/5.61+local-22) id <AA12555>; Wed, 27 Dec 1995 20:20:49 -0800 Received: from mailsv.nec.co.jp ([133.200.254.203]) by TYO2.gate.nec.co.jp (8.6.11+2.5Wb2/3.3Wb-NEC-TYO2) with ESMTP id NAA06277 for <mbone@isi.edu>; Thu, 28 Dec 1995 13:20:44 +0900 Received: from gw.ccs.mt.nec.co.jp (gw.ccs.mt.nec.co.jp [133.201.2.2]) by mailsv.nec.co.jp (8.6.11+2.5Wb2/3.4W-95121813) with ESMTP id NAA24792 for <mbone@isi.edu>; Thu, 28 Dec 1995 13:20:10 +0900 Received: from mail.ccs.mt.nec.co.jp (mail.ccs.mt.nec.co.jp [133.201.3.22]) by gw.ccs.mt.nec.co.jp (8.6.12+2.4W/3.3W9-GW_CCS) with ESMTP id NAA07281 for <mbone@isi.edu>; Thu, 28 Dec 1995 13:20:42 +0900 Received: from splpe229.ccs.mt.nec.co.jp by mail.ccs.mt.nec.co.jp (8.6.12+2.4W/6.4J.6-ccs_mx) id NAA21703; Thu, 28 Dec 1995 13:20:38 +0900 Received: from splpe229.ccs.mt.nec.co.jp (aga@localhost.ccs.mt.nec.co.jp [127.0.0.1]) by splpe229.ccs.mt.nec.co.jp (8.6.9/3.4Wbeta3) with ESMTP id NAA13344; Thu, 28 Dec 1995 13:20:33 +0900 Message-Id: <199512280420.NAA13344@splpe229.ccs.mt.nec.co.jp> To: mbone Cc: aga@ccs.mt.nec.co.jp Subject: Re: mbone for NT, 2nd try Reply-To: aga@ccs.mt.nec.co.jp In-Reply-To: Your message of "Thu, 21 Dec 1995 22:36:28 -0500 (EST)" References: <Pine.BSF.3.91.951221222715.8293A-100000@mercury.thepoint.net> X-Mailer: Mew version 1.00 on Emacs 19.28.2, Mule 2.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 28 Dec 1995 13:20:02 +0900 From: Hiroyuki AGA <aga@ccs.mt.nec.co.jp> > I'm working on developing multicast tools for NT and 95. Nothing that I > have is anywhere near useable, except for my NT port of the CU See Me > reflector. (I only mention it here because of the multicast support.) > > NV and VAT are on the top of my list. NV (receive only) is going to be > easier than VAT, at least until I learn more about the strange media API. > Support for Video for Windows for image transmission is very high on my > list of stuff to do... We are also working on developing a multicast tool for NT which is compatible with NV and VAT protocol. Here is a brief description on our software. ------------------------------------------------------------------------ We are developing an Internet teleconf tool tentatively called 'NVAT'. NVAT is an IP-multicast capable application on Windows NT, and compatible with MBone standard applications, namely nv and vat. Features: - Protocol NVAT speaks RTPv1 protocol in accordance with nv-3.3beta and vat-3.4. (We are planning to support RTPv2 protocol that is used in vic-2.7 and vat-4.0 in the future. - CODEC NVAT's support for codec is currently limited to SUN CellB and GSM. (We are going to implement other codecs used in nv, vat, and vic.) Requirement: - OS WindowsNT(3.5 or later) or Windows95(soon) - Video Capture & Audio Input/Output We use V4W API for video caputuring and ACM for audio, and you will not find any difficulty to use cards which come with appropriate drivers. Status: Right now, prototypical version is running on Windows NT3.5x, and this version is confirmed to compatible with nv-3.3beta and vat-3.4 on unixen. Porting to 95 is underway. Availability: We are making coordinations to make a binary distribution free of charge. We expect that will happen as early as Feb. 1996. (Our office is in the process of reallocation, so please be patient!) ------------------------------------------------------------------------ > Oh -- one tool seems so trivial I didn't think of it. I wrote a simple > version of SD for NT. If anyone wants it, I'll post it. Please. > Feel free to send me encouraging words, pointers to interesting > information about protocol specs, API specs, working source code, etc. > > I certainly do _not_ want to reinvent the wheel. I'd love to build the > perfect spoke for another wheel, or convert a wheel from another car to > this one, etc. If you have already developed an MBONE app for NT, please > let me know so that effort is not duplicated. So far we have set our goal solely to develop an AV tool on a par with exisiting counterparts on UNIX platforms, but we will need more effort to make it an practical tool. We would like to exchange information especially on what we should add functionalities to it. ------------------------------------------------------------------------------ Hiroyuki AGA NEC Corporation Multimedia Service Development Dept. [E-mail] aga@ccs.mt.nec.co.jp From list-mgr@ISI.EDU Wed Dec 27 14:10:55 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15315>; Wed, 27 Dec 1995 22:12:02 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15302>; Wed, 27 Dec 1995 22:11:11 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA15295>; Wed, 27 Dec 1995 22:11:08 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15065(2)>; Wed, 27 Dec 1995 22:11:02 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 27 Dec 1995 22:10:58 -0800 To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: mbone, Jason Gabler <ccjason@quadrophenia.ucdavis.edu> Subject: Re: host-1.sedona.com In-Reply-To: Your message of "Sat, 23 Dec 95 13:27:19 PST." <199512232127.NAA01143@rah.star-gate.com> Date: Wed, 27 Dec 1995 22:10:55 PST Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Dec27.221058pst.177478@crevenia.parc.xerox.com> In message <199512232127.NAA01143@rah.star-gate.com> you write: >Say anyone out there knows if host-1.sedona.com is running mrouted3.8? No, it is running a buggy version of Cisco's IOS that is propogating a default route. The only reason your mtrace pointed to host-1.sedona.com is because there was no route for 128.218.114 when you did your mtrace, so it matched the default route, and then host-1.sedona.com said "no route" because it is misconfigured. The real path looks more like this: % mtrace magicbus.ucsf.edu Mtrace from 128.218.114.68 to 13.2.116.11 via group 224.2.0.1 Querying full reverse path... * switching to hop-by-hop: 0 crevenia (13.2.116.11) -1 tibia-235 (13.2.116.239) DVMRP thresh^ 1 -2 snaildarter (204.162.228.1) DVMRP thresh^ 16 -3 ames.dart.net (140.173.144.1) DVMRP thresh^ 1 -4 mbone2.nsi.nasa.gov (192.203.230.242) DVMRP thresh^ 64 -5 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 1 -6 dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61) DVMRP thresh^ 64 -7 morgul.bbnplanet.net (192.42.110.249) DVMRP thresh^ 32 -8 utumno.barrnet.net (131.119.244.11) DVMRP thresh^ 32 -9 elbow.ucdavis.edu (128.120.226.8) DVMRP thresh^ 32 -10 magicbus.ucsf.EDU (128.218.114.68) DVMRP thresh^ 32 -11 magicbus.ucsf.EDU (128.218.114.68) Round trip time 214 ms Neither ns2.noc.netcom.net nor isengard.barrnet.net has anything to do with whatever problem you may be having. Bill From list-mgr@ISI.EDU Wed Dec 27 14:38:59 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA16022>; Wed, 27 Dec 1995 22:41:42 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA15993>; Wed, 27 Dec 1995 22:39:25 -0800 Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-22) id <AA15984>; Wed, 27 Dec 1995 22:39:17 -0800 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id WAA09041; Wed, 27 Dec 1995 22:38:59 -0800 Message-Id: <199512280638.WAA09041@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Bill Fenner <fenner@parc.xerox.com> Cc: mbone, Jason Gabler <ccjason@quadrophenia.ucdavis.edu>, jkh@time.cdrom.com Subject: Re: host-1.sedona.com In-Reply-To: Your message of "Wed, 27 Dec 1995 22:10:55 PST." <95Dec27.221058pst.177478@crevenia.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Dec 1995 22:38:59 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> >>> Bill Fenner said: > In message <199512232127.NAA01143@rah.star-gate.com> you write: > >Say anyone out there knows if host-1.sedona.com is running mrouted3.8? > > No, it is running a buggy version of Cisco's IOS that is propogating a defau lt > route. The only reason your mtrace pointed to host-1.sedona.com is because > there was no route for 128.218.114 when you did your mtrace, so it matched t he > default route, and then host-1.sedona.com said "no route" because it is > misconfigured. > Well, it is working well now which is the reason that you can do an mtrace to magicbus.ucsf.EDU. However during the weekend mtrace somewhow ended up at netcom even though magicbus.ucsf.EDU and the other end of the magicbus' tunnel , 128.120.226.8 were up. I was in contact with Jason when this happen . Not that it matters much just for the hell of it I extended a tunnel from my machine to his machine magicbus, Jason disconnected his original tunnel, and presto he had mbone connectivity so at least his mrouted is working. isengard.barrnet.net is causing problems to Jordan Hubbard. He reported the problem to barrnet and I think that they tried to fix whatever they have over there since then the machine is down so we will see when it comes back up again and hopefully as an mrouted3.8 if Jordan is still having mbone blackouts. This is Jordan's (jkh@time.cdrom.com) tunnel and he is running mrouted3.8: tunnel 192.216.222.226 192.216.222.3 metric 1 threshold 32 rate_limit 100 Tnks, Amancio From list-mgr@ISI.EDU Thu Dec 28 01:33:42 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02216>; Thu, 28 Dec 1995 09:35:18 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA02194>; Thu, 28 Dec 1995 09:34:27 -0800 Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA02182>; Thu, 28 Dec 1995 09:34:09 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14543(2)>; Thu, 28 Dec 1995 09:34:02 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Thu, 28 Dec 1995 09:33:51 -0800 To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: Bill Fenner <fenner@parc.xerox.com>, mbone, Jason Gabler <ccjason@quadrophenia.ucdavis.edu> Subject: Re: host-1.sedona.com In-Reply-To: Your message of "Wed, 27 Dec 95 22:38:59 PST." <199512280638.WAA09041@rah.star-gate.com> Date: Thu, 28 Dec 1995 09:33:42 PST Sender: Bill Fenner <fenner@parc.xerox.com> From: Bill Fenner <fenner@parc.xerox.com> Message-Id: <95Dec28.093351pst.177478@crevenia.parc.xerox.com> In message <199512280638.WAA09041@rah.star-gate.com> you write: >However during the weekend mtrace somewhow >ended up at netcom even though magicbus.ucsf.EDU and the other end >of the magicbus' tunnel , 128.120.226.8 were up. Well, the problem is at magicbus.ucsf.edu and/or elbow.ucdavis.edu; host-1.sedona.com and netcom have nothing to do with whatever is happening here. Try doing an mtrace to 0.0.0.1, it ends up at host-1.sedona.com, too, that just means that there is no real route for that subnet in the MBONE. Bill From list-mgr@ISI.EDU Thu Dec 28 16:58:37 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21506>; Thu, 28 Dec 1995 17:00:40 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21496>; Thu, 28 Dec 1995 17:00:10 -0800 Received: from hub.ubc.ca by venera.isi.edu (5.65c/5.61+local-22) id <AA21488>; Thu, 28 Dec 1995 17:00:09 -0800 Received: (from ean@localhost) by hub.ubc.ca (8.6.12/1.14) id RAA22638 for mbone@isi.edu; Thu, 28 Dec 1995 17:00:03 -0800 X400-Received: by /PRMD=ca/ADMD=/C=/; Relayed; Thu, 28 Dec 1995 17:00:02 UTC-0800 X400-Received: by /PRMD=ca/ADMD=/C=/; Relayed; Thu, 28 Dec 1995 16:58:37 UTC-0800 Date: Thu, 28 Dec 1995 16:58:37 UTC-0800 X400-Originator: hay@ucs.ubc.ca X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=ca/ADMD=/C=/;951228165837] Content-Identifier: 41121 From: Marilyn Hay <hay@ucs.ubc.ca> To: mbone Message-Id: <"41121*hay@ucs.ubc.ca"@MHS> Subject: ipmulti for SunOS4.1.1 Mime-Version: 1.0 (Generated by Ean X.400 to MIME gateway) Greetings, I am installing the IP multicasting on a SunOS 4.1.1 sun4c system and I cannot find the correct pieces to use out of the ipmulti.3.5-sunos41x.tar.Z distribution. There is a sys.sunos411 directory, but no sun4c directory within it, only sun3x. What should I be using to do this install? Thanks and take care, Marilyn Hay voice mail: 604-822-5438 Network Management Centre fax mail: 604-822-5116 University of British Columbia e-mail: Marilyn.Hay@ubc.ca Vancouver, B.C. Canada V6T 1Z2 From list-mgr@ISI.EDU Fri Dec 29 06:15:09 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23845>; Thu, 28 Dec 1995 18:15:53 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23836>; Thu, 28 Dec 1995 18:15:28 -0800 Received: from castor.cc.utu.fi by venera.isi.edu (5.65c/5.61+local-22) id <AA23829>; Thu, 28 Dec 1995 18:15:26 -0800 Received: by utu.fi id <169603-1>; Fri, 29 Dec 1995 04:15:21 +0200 From: Matti Aarnio <mea@utu.fi> To: mbone Subject: vic-2.7(alpha32) available for Linux Cc: vic@ee.lbl.gov Message-Id: <95Dec29.041521eet.169603-1+2@utu.fi> Date: Fri, 29 Dec 1995 04:15:09 +0200 at ftp.funet.fi:/pub/networking/services/multicast/LINUX/ It is compiled on a system running kernel version 1.3.49, and with libc-5.3.0 -- that is, rather "bleeding edge" stuff.. Even vic.dyn SHOULD be runnable on any ELFed Linux with XFree86-3.1.2+, though the static vic is only some 300 kB smaller... I don't have any kind of frame-grabbers, nor much can be tested over a 28k PPP link... (vic starts, buttons can be pressed, menus appear ok, but video ? ) /Matti Aarnio <mea@utu.fi> From list-mgr@ISI.EDU Fri Dec 29 03:55:03 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21788>; Fri, 29 Dec 1995 11:56:09 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA21753>; Fri, 29 Dec 1995 11:55:12 -0800 Received: from mercury.Sun.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA21746>; Fri, 29 Dec 1995 11:55:11 -0800 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id LAA04036; Fri, 29 Dec 1995 11:55:09 -0800 Received: from caribe.eng.sun.com (caribe-86.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02895; Fri, 29 Dec 1995 11:55:05 -0800 Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA13476; Fri, 29 Dec 1995 11:54:41 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA12829; Fri, 29 Dec 1995 11:55:03 -0800 Date: Fri, 29 Dec 1995 11:55:03 -0800 From: nordmark@caribe-86.Eng.Sun.COM (Erik Nordmark) Message-Id: <199512291955.LAA12829@bobo.eng.sun.com> To: fenner@parc.xerox.com Subject: Re: host-1.sedona.com Cc: mbone Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" > From: Bill Fenner <fenner@parc.xerox.com> > > No, it is running a buggy version of Cisco's IOS that is propogating a default > route. The only reason your mtrace pointed to host-1.sedona.com is because > there was no route for 128.218.114 when you did your mtrace, so it matched the > default route, and then host-1.sedona.com said "no route" because it is > misconfigured. It seems like this could be a perennial source of confusion when using mtrace. How hard would it be to modify mtrace to report back the route (address and mask/prefix) that was used to forward the mtrace packet? Would this require modifying or extending the mtrace protocol? Seems like it would be useful. Erik From list-mgr@ISI.EDU Fri Dec 29 13:48:56 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00666>; Fri, 29 Dec 1995 15:49:10 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA00655>; Fri, 29 Dec 1995 15:48:37 -0800 Received: from dip.eecs.umich.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA00647>; Fri, 29 Dec 1995 15:48:35 -0800 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.7.2/8.7.2) id SAA20629; Fri, 29 Dec 1995 18:48:57 -0500 (EST) From: Dave Thaler <thalerd@eecs.umich.edu> Message-Id: <199512292348.SAA20629@dip.eecs.umich.edu> Subject: Re: host-1.sedona.com To: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Date: Fri, 29 Dec 1995 18:48:56 -0500 (EST) Cc: fenner@parc.xerox.com, mbone In-Reply-To: <199512291955.LAA12829@bobo.eng.sun.com> from "Erik Nordmark" at Dec 29, 95 11:55:03 am X-Mailer: ELM [version 2.4 PL24 PGP1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > How hard would it be to modify mtrace to report back the route > (address and mask/prefix) that was used to forward the mtrace packet? > Would this require modifying or extending the mtrace protocol? > > Seems like it would be useful. > > Erik Not hard at all, here's the diffs... -Dave *** mtrace.c.orig Fri Dec 29 18:46:11 1995 --- mtrace.c Fri Dec 29 18:47:25 1995 *************** *** 787,793 **** ms = scale(&hop); printf(" %d%s", hop, ms); } ! printf(" %s\n", flag_type(r->tr_rflags)); memcpy(names[i-1], name, sizeof(names[0]) - 1); names[i-1][sizeof(names[0])-1] = '\0'; } --- 787,798 ---- ms = scale(&hop); printf(" %d%s", hop, ms); } ! if (r->tr_smask > 1) { /* default reports 1 */ ! u_int32 smask; ! VAL_TO_MASK(smask, r->tr_smask); ! printf(" %s [%s]\n", flag_type(r->tr_rflags), inet_fmts(qsrc,smask,s1)); ! } else ! printf(" %s [default]\n", flag_type(r->tr_rflags)); memcpy(names[i-1], name, sizeof(names[0]) - 1); names[i-1][sizeof(names[0])-1] = '\0'; } From list-mgr@ISI.EDU Sat Dec 30 01:51:17 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14158>; Sat, 30 Dec 1995 01:51:55 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA14150>; Sat, 30 Dec 1995 01:51:21 -0800 Received: from garfield.irdu.nus.sg by venera.isi.edu (5.65c/5.61+local-22) id <AA14143>; Sat, 30 Dec 1995 01:51:17 -0800 Received: (from lky@localhost) by garfield.irdu.nus.sg (8.6.11/8.6.9) id RAA16941; Sat, 30 Dec 1995 17:52:22 +0800 Date: Sat, 30 Dec 1995 17:52:21 +0800 (SGT) From: Leong Kok Yong <lky@garfield.irdu.nus.sg> To: mbone Subject: unsubscribe Message-Id: <Pine.LNX.3.91.951230175142.16535A-100000@garfield.irdu.nus.sg> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From list-mgr@ISI.EDU Sat Dec 30 19:42:15 1995 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23138>; Sat, 30 Dec 1995 09:43:49 -0800 Received: by venera.isi.edu (5.65c/5.61+local-22) id <AA23129>; Sat, 30 Dec 1995 09:43:25 -0800 Received: from artemis.rus.uni-stuttgart.de by venera.isi.edu (5.65c/5.61+local-22) id <AA23120>; Sat, 30 Dec 1995 09:43:21 -0800 Received: from kssun9.rus.uni-stuttgart.de (kssun9.rus.uni-stuttgart.de [129.69.30.19]) by artemis.rus.uni-stuttgart.de with SMTP id SAA05238 (8.6.12/IDA-1.6 for <mbone@ISI.EDU>); Sat, 30 Dec 1995 18:43:14 +0100 Received: by kssun9.rus.uni-stuttgart.de (5.0/SVR4/BelWue-1.0) id AA28238; Sat, 30 Dec 1995 18:42:16 --100 From: "Peter Feil" <Peter.Feil@RUS.Uni-Stuttgart.DE> Message-Id: <9512301842.ZM28235@kssun9.rus.uni-stuttgart.de> Date: Sat, 30 Dec 1995 18:42:15 +0100 X-Mailer: Z-Mail (3.2.1 10apr95) To: mbone Subject: Solaris 2.5 multicast Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 720 Hi, Solaris 2.5 is out there now. But what about its multicast capabilities? What do I have to do to run the latest mrouted Version 3.8 with Solaris 2.5? Which kernel modifications are needed? (I didn't find anything about this in the Solaris 2.5 Beta distribution) Thanks for any comments --------------------------------------------------------------- Peter Feil MBone National Support Center Germany University of Stuttgart Computing Center phone : ++49-711-685 5735 Allmandring 30 fax : ++49-711-678 7626 70550 Stuttgart e-mail: feil@rus.uni-stuttgart.de Germany http://www-ks.rus.uni-stuttgart.de/mice-nsc/index.html ---------------------------------------------------------------