Subject: READ THIS: How to unsubscribe from the MBONE mailing list

From: Mark Boolootian <[email-masked]>
Date: Wed, 19 Feb 1997 09:54:59 -0800 (PST)

The mbone mailing list is an exploder consisting of several subsidiary lists.
Those lists are:

   [email-masked],
   [email-masked],
   [email-masked],
   [email-masked],
   [email-masked],
   [email-masked],
   [email-masked],
   [email-masked]

You are NOT subscribed directly to the mbone list; you are subscribed through
one of the subsidiary lists above.  In theory, you should be able to figure
out which list you are subscribed to based on the region in which you live.
For example, if you are in Germany, you are probably subscribed via the
list [email-masked], and that is where you would send your unsubscribe 
request.

Following are instructions (un)subscribing for each of the above lists
(except for the Singaport list for which I could not obtain info):

  EUROPE:  [email-masked]
    Send email to [email-masked] with a request to (un)subscribe
    in the subject and/or body

  JAPAN:  [email-masked]
    Send email to [email-masked] with a request to (un)subscribe
	in the subject and/or body

  KOREA:  [email-masked]
    Send email to [email-masked] with a request to
    (un)subscribe in the subject and/or body

  NORTH AMERICA:  [email-masked]
    Send email to [email-masked] with one of the following commands in the
	BODY of the message:

      subscribe mbone-na [<address>]
    or
      unsubscribe mbone-na [<address>]

    which will (un)subscribe yourself (or <address> if specified) (from)to 
    the mbone-na mailing list.  You can also send the command 'who mbone-na'
    to obtain the members of the mbone-na list.

  NEW ZEALAND:  [email-masked]
    Send email to [email-masked] with a request to
    (un)subscribe in the subject and/or body

  AUSTRAILIA:  [email-masked]
    Send email to [email-masked] with a request to
    (un)subscribe in the subject and/or body

  SINGAPORE:  [email-masked]
    Unfortunately I was unable to obtain info for this list.  My best guess
    is to give [email-masked] a try and see what happens.  Does
    the list actually exist?

  TAIWAN:  [email-masked]
    Send email to [email-masked] with a request to
    (un)subscribe in the subject and/or body

The members of the mbone mailing can NOT unsubscribe you from these lists.
Don't bother them with requests to be removed.  Even if you've spent the
better part of your alleged adult life trying to get off the list, complaining
to the list won't stem the flow of email from the list.  Likely it will
have the opposite effect.

mb
---
Mark Boolootian
UC Santa Cruz

---

From: Matt Mathis <[email-masked]>
Date: Mon, 24 Feb 1997 09:36:11 -0500 (EST)

I suspect the problems lies elsewhere: In a quick scan of mbone-na I
count more than 70 downstream mail exploders.  I bet many of the
people who can't get unsubscribed are actually subscribed to one
of the downstream lists.

Hint: look at the whole mail header (normally hidden) and scan the
Received-from: lines for the next host after leaving ISI.  (Normally
immediately above the ISI lines, check the timestamps).  Depending on
the mailer/version the Received-from: line may show the mail box at
that hop.  If it does not, you have to scan the [email-masked] lists
for an entry that matches the next hop host.  For example the
message that I am replying to was delivered: 

>Received: from mailer.psc.edu (mailer.psc.edu [128.182.58.100]) by zippy.psc.edu
> (8.8.5/8.8.2) with ESMTP id OAA03130 for <[email-masked]>; Wed, 19 Feb 19
>97 14:12:39 -0500 (EST)
>Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailer.psc.edu
> (8.8.5/8.8.2/mailer) with SMTP id OAA09478 for <[email-masked]>; Wed, 19 Fe
>b 1997 14:12:33 -0500 (EST)
>Received: by zephyr.isi.edu (5.65c/5.61+local-23)
>        id <AA10125>; Wed, 19 Feb 1997 09:56:05 -0800
>Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
>        id <AA10112>; Wed, 19 Feb 1997 09:56:03 -0800
>Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-26)
>        id <AA26223>; Wed, 19 Feb 1997 09:56:01 -0800
>Received: by zephyr.isi.edu (5.65c/5.61+local-23)
>        id <AA09995>; Wed, 19 Feb 1997 09:55:32 -0800
>Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
>        id <AA09967>; Wed, 19 Feb 1997 09:55:07 -0800
>Received: from cats.ucsc.edu (rumpleteazer.UCSC.EDU) by venera.isi.edu (5.65c/5.
>61+local-26)
>        id <AA26149>; Wed, 19 Feb 1997 09:55:05 -0800
>Received: from krazy.ucsc.edu (krazy.UCSC.EDU [128.114.129.44])
>          by cats.ucsc.edu (8.8.5/8.8.4.cats-athena) with SMTP
>          id JAA04182; Wed, 19 Feb 1997 09:55:03 -0800 (PST)

The hop of interest is mailer.psc.edu, and the message was delivered
to the mailbox <[email-masked]>

I would have two choices to get off the list: Remove the down stream
list (e.g. <[email-masked]>) from [email-masked] or have myself
removed from the downstream list.   Think before you do anything
rash...

Good Luck,
--MM--

P.S. To ISI:  this would be much if you where using the new
Received-from format.
--MM--

---

From: k claffy <[email-masked]>
Date: Mon, 24 Feb 1997 16:32:21 -0800 (PST)

[hoping my painful experience saves
other people time if they're in same
boat-dist@]

from matt's example

if you want to do the former 
[removing a -dist from [email-masked]]
you're going to have to forge smtp headers
so your from line is the -dist address.

this is because 'they' are just not managing
the mbone-na one, so you'll have stoop
down to their layer.

[btw, seems like this list should be using 
multicast by now, so we could at least remain
in the proper spirit when prunes don't work]

k

---

From: k claffy <[email-masked]>
Date: Mon, 24 Feb 1997 16:32:21 -0800 (PST)

from matt's example

k

---

From: Wojtek Sylwestrzak <[email-masked]>
Date: Tue, 25 Feb 1997 22:40:24 +0100 (MET)

> in the proper spirit when prunes don't work]

Probably. but personally I don't even like the idea of hierarchical
exploders - in my view this is an overkill. hierarchical mail distribution ?
is this list so busy ?
probably the concept is fine (a little like the bitnet listservs) but
in reality it only gives headaches to those wanting to get off the list.

but if you're considering multicasting email ... that's another story. 
I'm in ;-)

(sorry for this off topic)

--w

---

From: [email-masked] (Alan Batie)
Date: Tue, 25 Feb 1997 14:06:21 -0800 (PST)

> but if you're considering multicasting email ... that's another story. 

I believe it is called "USENET newsgroup".

-- 
Alan Batie                     ------        What goes up, must come down.
[email-masked]        \    /        Ask any system administrator.
+1 503-264-8844 (voice)         \  /         --unknown
D0 D2 39 0E 02 34 D6 B4          \/          5A 41 21 8F 23 5F 08 9D

---

From: Wojtek Sylwestrzak <[email-masked]>
Date: Tue, 25 Feb 1997 23:17:22 +0100 (MET)

> I believe it is called "USENET newsgroup".

Almost, but we aren't now on one, are we ?
But perhaps we should..

Sorry for being a layman here, but is there any promising work underway
to multicast NNTP feeds ? At first this sounds reasonable thing to do ?
but then of course it couldn't be nntp as we know it.

--w

---

From: [email-masked]
Date: Tue, 25 Feb 1997 14:40:40 -0800 (PST)

> but then of course it couldn't be nntp as we know it.

MUSE - circa 1993/94 from some good folks inside UUnet.
Never had enough intertia to take the world by storm.

-- 
--bill

---

From: Wojtek Sylwestrzak <[email-masked]>
Date: Tue, 25 Feb 1997 23:50:19 +0100 (MET)

> Never had enough intertia to take the world by storm.

was it any good ?
perhaps the mbone was not widespread enough by then ?

--w

---

From: [email-masked]
Date: Tue, 25 Feb 1997 15:00:54 -0800 (PST)

> perhaps the mbone was not widespread enough by then ?

I really don't remember all that much.  NNTP operations/mgmt was/is a
line I never really crossed.  Anyone else care to chime in here?

-- 
--bill

---

From: William Robertson <[email-masked]>
Date: Tue, 25 Feb 1997 16:48:51 -0800

was it any good ?

 not really.  it used multicast, but it was total brute force broadcast 
 where uunet, the transmitter, was at the center of the world.  

rob
			  william robertson
        network engineer, hotwired  +1 415  276 8471 (voice)
                 [email-masked]  +1 888  912 0300 (pager)

---

From: George Michaelson <[email-masked]>
Date: Wed, 26 Feb 1997 11:02:07 +1000

If MBONE and 6Bone teach us anything, its that -bone architectures grow best
when they map naturally to real physical point-to-point architectures.

If you look at news, news is a <semi>cast based on establishing a set
of point-to-point relationships which generally track relationships in
the outsideworld, and often network architectures, but not always the latter.

I think MNTP (Multicast News Transfer Protocol?) would work well if somebody
deployed it on a large campus and showed it scaled for people who do NNTP
across the 10-20 host setup. Then you can leverage that into the outside-org
relationships by finding an upstream feed who can see demonstrable traffic
drop by making newsfeeds follow network topology and become traffic efficient.

Lets just pretend that the newsfeed rulesets don't actually encode 1003
arcane "I want this but not that" choices for a host of smaller feeds...

As an ISP, the company I work for has already done the traffic flow costings
on news and we KNOW that we make money from selling what we fetch once to
as many people as we can. If somebody can show me that multicast is a
good way to reduce core redistribution costs across a national network then
its a plausible argument for *ANY* ISP with a real network to get mcast
aware. We are hyper-cost concious.

cheers

-George
--
George Michaelson         |  connect.com.au pty/ltd
Email: [email-masked] |  c/o AAPT,
Phone: +61 7 3834 9976    |  level 8, the Riverside Centre,
  Fax: +61 7 3834 9908    |  123 Eagle St, Brisbane QLD 4000

---

From: "Heiko W. Rupp" <[email-masked]>
Date: Wed, 26 Feb 1997 08:58:32 +0100

> to multicast NNTP feeds ? At first this sounds reasonable thing to do ?

As someone already pointed out, there was Muse from UUnet. I am 
currently working on a more or less (*) implementation, called Mcntp.
A quick-and-dirty version already worked well and I expect an alpha version
of the final code to come within the next weeks.

-- 
NTG Netzwerk und Telematic GmbH   /          Heiko W.Rupp
Geschaeftsbereich Xlink         \/           phone: +49 721 9652 0
Vincenz-Priessnitz-Str. 3       /\ link      fax:   +49 721 9652 210
D-76131 Karlsruhe, Germany     /_______      email: [email-masked]

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 26 Feb 1997 09:11:53 +0000

>aware. We are hyper-cost concious.

why do you need someone to sho you it will reduce core costs?
its obvious it will....
 
what is missing is simply a decent relaible 1-n bulk transfer protocol
to run it on....but there are several candidates lurking in the
wings....

once upon a time, the people who wanted it would just write one-
nowdays most  ISPs are too busy making money ,and wanting everyone to like
them to actually put much of  anything back into the community....

of course, the COST of running a decent well engineered mbone is higher
than just running  a unciast backbone - that is the INVESTMENT you
have to make before you get the payback of not replicating all that
traffic, and paying so much in line rental to the telcos:-)

trouble is most ISPs beancounters don't let them inveest in new tech,
anymore than what they know for now (go fast, route more safwely
unicast), because of the manic growth in dumb busness is the main
profit area at the moment....

 jon

---

From: Zheng Wang <[email-masked]>
Date: Wed, 26 Feb 1997 10:35:53 +0000

> Never had enough intertia to take the world by storm.
 
MUSE does not retransmit lost packets. 

UCL has done a reliable mcast mail delivery system called MMD,
which is designed to deal with the problems of large mailing list.
We actually asked for some volunteers from the mbone list for 
testing over a year ago.

If you are interesting, there is a paper about it
ftp://cs.ucl.ac.uk/darpa/mmd.ps.Z
Maybe we should have a large scale experiment.

Cheers
Zheng

---

From: "James E. [Jed] Donnelley" <[email-masked]>
Date: Wed, 26 Feb 1997 08:25:17 -0800 (PST)

> >...If somebody can show me that multicast is a
>why do you need someone to show you it will reduce core costs?
>Its obvious it will....
>
>what is missing...
> jon

Jon - I don't understand this argument.  It seems to me that
any ISP sees such a small part of the overall Internet that
beginning to use multicast for bulk data redistribution will not benefit
any given ISP substantially.  The main benefit would seem to
be in the aggragate.  If that is the case it isn't clear
what will drive (i.e. motivate) any individual organization
to adopt multicast routing or transport.

At this point in time it appears to me that:

1.  There is a lot of work involved in supporting multicast,
2.  To be effective others must adopt it at essentially the same time, and
3.  The main benefits are only visible in the aggragate (that is, the
incremental benefit to an individual ISP from beginning to support
multicast is small compared to the costs).

This seems an awkward situation.  The benefit to the whole seems
substantial and clear (as you say), but to the individual
organizations the investment does not seem worthwhile.

The approach at UUnet where they have developed essentially
a whole multicast distribution network is the only way I have
yet seen out of this dilema.  Unfortunately that case would not
seem to apply to the Internet as a whole or to most ISPs.

What do you see as the motivating factor in getting Internet ISPs to
put the required work into multicast?

Jed Donnelley    [email-masked]   Phone: (510) 422-4309
http://www.webstart.com/jed/    FAX: (510) 423-1355

---

From: Jonathan Day <[email-masked]>
Date: Wed, 26 Feb 1997 18:07:45 +0000 (GMT)

> multicast is small compared to the costs).

This partly depends on what's being multicast, who to and where from, IMHO.
eg: Imagine you're running a number of services in which a large number of
people are receiving duplicate information. Say, for example, IRC, or
something of that kind. This offers two immediate and obvious benefits:

a) No duplication, so less overheads on the server and the network

(This frees up capacity, potentially allowing the ISP to sell additional
services)

b) Simpler structure, therefore (potentially) better stability

(Stability is a function of complexity. The more complicated something is,
the more likely it is to go wrong. Why does this matter to an ISP? Well,
time is money. An unavailable service isn't earning you anything, and costs
money to restart.)

For services where only a few, or even just one, person is interested in the
information at a given time, multicasting is harder to justify. You can't
remove duplication that isn't there.
 
> organizations the investment does not seem worthwhile.

IMHO, it's easy to determine it's usefulness to a given organisation by
checking the level of redundancy at any given moment in time. This is going
to vary across services and across organisations, irrespective of their
size or nature. You can't get much smaller than a single ring intranet,
but if you've a file-server stuck at one end that's getting large numbers
of simultaneous duplicate requests, you might well start looking at alternate
methods of sending things - if only to save wear on the disk!
 
> put the required work into multicast?

There are four alternative methods of sending data. I've also listed the
case in which I would seriously consider using that method.

1) Unicast, direct

Small number of requests simultaneously, small number of repeat requests

2) Unicast, cached

Small number of requests simultaneously, large number of repeat requests

3) Multicast, direct

Large number of requests simultaneously, small number of repeat requests

4) Multicast, cached

Large number of requests simultaneously, large number of repeat requests

(Where 'small' and 'large' refer to some function of users & volume of data)

Now, I might be barking up the wrong tree entirely here. I certainly wouldn't
want, or expect, anyone to take any of the above as absolute truth. However,
I do hope there's enough meaning somewhere in that lot for you to get something
useful out.

Jonathan

---

From: "Matthew V. J. Whalen" <[email-masked]>
Date: Wed, 26 Feb 1997 16:50:53 -0500

> where uunet, the transmitter, was at the center of the world.  

Only uunet broadcast the messages?  Why wouldn't everyone who 
participated in the news mcast broadcast any new messages they
received through other feeds?

-matthew
[email-masked]
Shop as usual...........................and avoid panic buying

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 27 Feb 1997 01:38:15 +0000

>to adopt multicast routing or transport.

self fulfillig negative prophsy = the raison d'etre of IP is bandwidth
sharing  - multicast is a leverage _par excellence_ in the same
direction - we built TCP/IP stacks for zilch for everyone - now we've
done multicast ones, lotsa people are confused, becuase they think
anything useful should cost more.....they forget history..

 >1.  There is a lot of work involved in supporting multicast,

you must have a poor ISP

 >2.  To be effective others must adopt it at essentially the same time, and

why? it is incrementally better...

 >put the required work into multicast?

maybe you need evryone to get a better price/performance betfore they
move to another ISP - that is all there is to it....

50%  multicast for 1-100 transmissionis stilll 1/2 the backbone
trafic........anyone who can't see that, and hasn't got a
dvmrp/pim/mospf argument against it is incompetent.....

but there are some deployment arguments against the latter...

cheers

 jon

---

From: George Michaelson <[email-masked]>
Date: Thu, 27 Feb 1997 12:10:32 +1000

I think Jon is right, it shouldn't be neccessary to 'justify' multicast
to an ISP because importing 1 and selling 1+ is a margin in anybodys language.

The problem is that (as he says) 'new' is nowadays equated to 'charge more'
because when it comes down to it, the margins in selling vanilla 1 and 0 is
pretty thin.

Mind you, I don't think utilities should be selling anyway, I think the
sewers should be paid for from the tax budget but thats a whole other story.

Really, the issue is inertia.

	changing news is effort
	adding scope rules is effort
	defeating FUD is effort.

ISPs are nothing if not lazy. The ones who understand things, and who deploy
new feature early and leverage customer relations from it are the smart ones
who do well. 

-George

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 27 Feb 1997 01:38:15 +0000

you must have a poor ISP

cheers

 jon

---

From: Dave Pascoe <[email-masked]>
Date: Thu, 27 Feb 1997 00:53:09 -0500 (EST)

> received through other feeds?

They would, in theory...the experiment was small and short-lived.  So the 
comment Rob made about UUNET being in the center of the universe was a
little off base and misleading.

The truth is that not much data was gathered....or if it was, it wasn't
presented in the research paper.

--
Dave Pascoe  | mailto:[email-masked]  | Voice: 508.647.7362
KM3T         | http://www.mathworks.com   |   FAX: 508.647.7002
PGP fingerprint: 53 AD 71 88 2F AA 45 AC D0 2E 68 91 71 77 39 AF

---

From: George Michaelson <[email-masked]>
Date: Thu, 27 Feb 1997 16:25:41 +1000

From memory, the WB model of recovery is traffic efficient because
the chained/persistant datastore can be done at the lowest possible
TTL by neighbours in a multicast tree. But then its a very dense
model of data, because its held as the abstract objects and not their bitmaps.

I don't think NNTP or email can do that, unless its done more like a bgp AS
exchange where people blat out differences of message-id and then
do fixups in the smaller horizon zone. Hmmm that might be interesting,
models of how to reduce large data down to a small hash and then exchange
hashlists in bursts to check up on whats missed from the flow passing by.

That might work for people doing this kind of thing on UDLR as well
with a lower b/w feedback chain somewhere (handwaving) else.

You could do a lot of pre-loading web caches if you could make that work.

Maybe what people need to do in recovery mode is work out how to make a generic
model of large-data small hash get passed around efficiently within defined
zonal ttl regions to avoid too much cost to catch up.

Maybe thats how it works in rmp land anyway.

-George, clueless as usual...

---

From: "Mahesh Ramachandran" <[email-masked]>
Date: Mon, 3 Mar 1997 03:11:41 -0500 (EST)

Several months ago, there was a site multicasting usenet news. And I guess
there were several listeners also, since the path headers had a number
of sites of the form multicast.<domainname>. It was probably in beta 
testing at that time. Anyone have further info?

thx
-rr

|> 
|> > > > Sorry for being a layman here, but is there any promising work underway
|> > > > to multicast NNTP feeds ? At first this sounds reasonable thing to do ?
|> > > > but then of course it couldn't be nntp as we know it.
|> > > > 
|> > > > --w
|> > > 
|> > > MUSE - circa 1993/94 from some good folks inside UUnet.
|> > > Never had enough intertia to take the world by storm.
|> > > 
|> > > -- 
|> > > --bill
|> > > 
|> > 
|> > was it any good ?
|> > perhaps the mbone was not widespread enough by then ?
|> > 
|> > --w
|> 
|> I really don't remember all that much.  NNTP operations/mgmt was/is a
|> line I never really crossed.  Anyone else care to chime in here?
|>