Re: new version of the draft

[Brian Carpenter CERN-CN <[e-mail]>]

Steve and people,

In view of what follows I accept multicast support as a valid
criterion. For me it's either a SHOULD, or a new category:
a DEFERRED MUST (must be a property of the protocol, but
not necessarily available at the start of deployment).
> 
> > ... 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.

OK, so the argument is that to *guarantee* a spanning tree that does
not use the same physical link N times, the spanning tree has to
be managed by the routers. I think I buy that, thanks. I refrained from
citing MBONE because I happen to know how many times the Washington
audiocast traffic went up and down the CERN-Amsterdam link :-(
> 
> > (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?
> 
I put it in parenthesis because I'm not sure I do believe it. Some
ATM experts do, but multicast over ATM is not even standardised.
And at best a subset of the Internet will be ATM based.
However that's probably not a debate for the criteria list -
see the comp.dcom.cell-relay newsgroup for example.

  Brian