Re: new version of the draft

Steve Deering <deering@parc.xerox.com> Thu, 17 December 1992 08:42 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01587; 17 Dec 92 3:42 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01581; 17 Dec 92 3:42 EST
Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa03748; 17 Dec 92 3:44 EST
Received: from alpha.Xerox.COM by ftp.com with SMTP id AA21082; Thu, 17 Dec 92 03:38:13 -0500
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11521>; Thu, 17 Dec 1992 00:37:47 PST
Received: from localhost by skylark.parc.xerox.com with SMTP id <10782>; Thu, 17 Dec 1992 00:37:38 -0800
To: Brian Carpenter CERN-CN <brian@dxcern.cern.ch>
Cc: criteria@ftp.com, deering@parc.xerox.com
Subject: Re: new version of the draft
In-Reply-To: Your message of "Thu, 17 Dec 92 00:11:34 PST." <9212170811.AA15064@dxcern.cern.ch>
Date: Thu, 17 Dec 1992 00:37:38 -0800
X-Orig-Sender: Steve Deering <deering@parc.xerox.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <92Dec17.003738pst.10782@skylark.parc.xerox.com>

> ... We've had non-real-time multicast applications
> for years, such as LISTSERV on BITNET, and newsgroups.
> They have the property that the multicast spanning tree is built
> at application level (and lives in name space rather than address
> space). They also have the property that (in principle) the same
> traffic need never flow twice over the same link.

I don't think that is true, in principle or in reality, unless your
applications also live in the routers.  The MBONE is effectively
doing "application level" (at least, not hop-by-hop in the real routers)
multicast, and it is been impossible to limit all links to only one
tunnel.

> (Another argument against multicast at IP level is that ATM will
> do it better, but that is futuristic.)

What makes you believe that?  In what ways can ATM do it better?

Steve