Subject: RE: WAN multicast status

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Sat, 30 Sep 2000 10:30:24 +0100

Henry's analysis is quite right.

Joining a multicast group today is not
associated to any AAA...

Until we don't have this defined, 
commercial uses of Multicast seem to
be quite limited.

(ditto was true for mobile IP)

alessio

> ----------
> From: 	Henry Sinnreich[SMTP:[email-masked]]
> Sent: 	29 September 2000 15:56
> To: 	John M. Zwiebel; Tony Ballardie
> Cc: 	idmr; mboned; maddogs
> Subject: 	RE: WAN multicast status
> 
>  ^ I'd like to try and generate a discussion on why the idmr and
> mboned
>  ^ lists have been so quiet for so long. Why is this?
> A personal opinion in hindsight: The multicast community did not
> develop and standardize the AAA and payments issues related to
> multicast. ISPs had no business model to justify the investment
> in multicast...
> Don't blame Real and Microsoft.
> 
> Having this explanation, right or wrong, am now trying to get
> SIP folks to worry about AAA and payments for SIP services. If
> we don't learn from history, we will have to repeat it...
> 
> Forgive my comments.
> 
> Henry
> 
> Henry Sinnreich
> MCI WorldCom
> 400 International Parkway
> Richardson, Texas 75081
> USA
> 
> >-----Original Message-----
> >From: [email-masked]
> >[mailto:[email-masked]]On
> >Behalf Of John M.
> >Zwiebel
> >Sent: Thursday, September 28, 2000 8:41 PM
> >To: Tony Ballardie
> >Cc: idmr; mboned; maddogs; [email-masked]
> >Subject: Re: WAN multicast status
> >
> >
> >
> >
> > ^
> > ^ I'd like to try and generate a discussion on why
> >the idmr and mboned
> > ^ lists have been so quiet for so long. Why is this?
> >
> >Mostly I believe that now is a time for deployment.
> >All the talking
> >is done and folks are actually doing it.
> >
> >The "major" problem though is still the lack of
> >compelling content
> >which can reach a very large audience.  Some of the road-blocks
> >are:
> > --DSL -- last hop can't do multicast (ie DSLAM can't replicate
> >   a Single packet over different links);
> > --DOCSIS model for cable -- they want access control
> >at layer-2 and
> >   there isn't a clear winner at layer-3 or above;
> > --ISP provider topologies -- for example AOL has
> >tunnels across
> >   other ISPs and so (like the DSLAM) multicast
> >replication doesn't happen
> >   at the last hop;
> > --alternate technologies that don't have anything to
> >do with multicast
> >   but which may preclude deployment of multicast in
> >the near term because
> >   they are incompatable;
> > --failure of Real and Microsoft to provide an open
> >internet broadcast
> >   standard, combined with their need to maintain
> >control over the content
> >   to the last hop to be able to realize a profit from
> >sales of
> >   their technology.
> > --the knowledge that MSDP can only be a stop-gap
> >protocol for interdomain
> >   multicast combined with the lack of progress on
> >BGMP which is viewed
> >   as being too complicated.
> > --No way of determining the BW of the link requesting
> >a multicast
> >   stream and therefore no way of insuring the link
> >doesn't get overwhelmed.
> > --The perception that video over the internet is
> >never going to be any
> >   better than the 2" window you see over Real
> >
> >The "good news" is that there is progress being made
> >in each of these
> >areas, the bad news is that its still going to take
> >too long to get it
> >done, since (for me at least) it should have happened
> >years ago.
> >
> > ^
> > ^ Content distribution networks (CDNs) and companies
> >are emerging, together
> > ^ with content providers (the 1-many application
> >driver has arrived). The CDN
> > ^ companies are building virtual topologies, but they
> >seem to be bypassing IP
> > ^ multicast in their designs in favour of application
> >level mcast and other
> > ^ solutions.
> >
> >IMHO, these networks provide the layer-4 and above
> >control over the
> >content that a "Republicrat" would require to maintain
> >control over the
> >content distribution.  The model of "free TV" doesn't
> >translate that well
> >to an internet that can't put content in every home so
> >advertisers don't
> >know the size of the potential market.  The CDN
> >network provides better
> >feedback.
> >
> >However even CDN can and will recognize benefits from
> >multicast and so
> >will deploy it and use it.  It would appear to me that
> >they are using
> >what they know now to gain market position.  They know
> >about multicast
> >but they don't know that it really works because of
> >all the roadblocks
> >listed above.
> >
> >I like to think of this as a free-speech issue though.
> > :-)  layer-3
> >multicast is for the "masses" where everyone can be
> >their own TV station
> >(50,000 channels and nothing on).  Republicrat
> >multicast for the elite
> >who want to control what the masses see. (1984) :^)
> >
> >FWIW, enterprise multicast is doing great.
> >
> >Where do we have to go from here?
> >
> >Well, SSM, being made possible via IGMPv3 is going to be a
> >huge driver for interdomain multicast.  It "would be
> >nice" if the web
> >page that advertises the SSM session could be enhanced
> >to record the
> >participants in the group so that it could act as an
> >RP rather than
> >having to depend on the RP to be located in the network.
> >
> >Once that is accomplished, then it "would be nice" if
> >that same RP
> >process could be used to set up an interdomain bi-dir
> >group.  Since in
> >bidir PIM the RP can be anywhere, it just becomes a
> >vector end-point.
> >If you could have a "ip pim  rp-address 0.0.0.0 bidir"
> >(a very gross
> >generalization of what would be needed) any one
> >sending to a multicast
> >group served by the default RP would send out a
> >"vector" that receivers
> >would join to.  All vectors must eventually merge at infinity.
> >
> >Both of these solutions remove the need for MSDP and
> >BGMP, they do
> >present other challenges though that may be more
> >difficult to solve,
> >but they wouldn't have to be solved in the network.
> >
> >Finally, I'd like to see the model change for sending
> >to a multicast
> >group.  Allowing a source to dump traffic on to a
> >network and expecting
> >the network to just deal with it does not work in
> >large scale and
> >especially interdomain multicast.  For years at every
> >IETF, the beer
> >sessions have always devolved to requiring an RTS/CTS
> >multicast sender
> >capability.  No one wants to do it because it doesn't
> >fit the model
> >proposed by Deering.  Well, ethernet connectors don't
> >have slide-locks
> >any longer (at least no one buys ones that do) so its
> >time to change
> >the sender model or at least have some kind of an
> >alternative to the
> >current model where anything can get dumped out and it has to
> >be "taken care of".
> >
> >2 cents.  Not reflecting anyone's reality but my own.
> >I'm lost in
> >a lost world of hopes and dreams of interdomain
> >multicast becoming a
> >reality so I can go to the beach.  :-)
> >
> >-------------------------------------------------------
> >-----------------------
> >	John Zwiebel                       Phone: 408-526-5303
> >	Cisco Systems Inc.
> >	IP Multicast Group
> >
>

---

From: Randy Bush <[email-masked]>
Date: Sat, 30 Sep 2000 08:45:03 -0700

> Joining a multicast group today is not

sending unicast is not associated with any aaa.  this explains why unicast
is such a dismal failure.

randy

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 30 Sep 2000 16:58:53 +0100

good point

a couple of centsworth:

imminent life of multicast predicted.

1/ cisco finally have somethign that works
2/ sprint and a couple of other BIG isps care
coz
3/ customers realize that their SERVERs dont cost as much if they
multicast 
and
4/ we have some custoemrs with enuff bandwidth (xDSL/cable) and are
_always on_ (sort of critical to simulataneous delivery somehow:-)
to want streamed media in numbers 
and
5/ we have several flavours of reliable multicast nearly "approved" by
the "friends of TCP friendliness"  officers
which means
6/ lots of other quite useful stuff will also get multicast not just
dubious video/audio

what is not happening is
a) multicast for dial up (the AAA comment may be relevant there though
really it aint difficult to authenticate/filter/firewall IGMP for gods
sakes)
b) many-to-many coz we dont know how to do interdomain and we dont see
the latent demand yet - however, that said, the number of cute devices
(playstation 2, dreamcast etc) that will wanna do 10 or even 100
player games and not use a server are gonna be quite impressive even
by todys phobile moan and matrix denizens expectations...

 >>is such a dismal failure.

 cheers

   jon

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 1 Oct 2000 05:01:54 +0859 ()

Randy;

> is such a dismal failure.

Not a proper comparison, because multicast is essentially a resource
reserved communication (you must reserve a routing table entry (resource
much more precious than bandwidth) for each group).

So, one can say:

> sending resource reserved unicast is not associated with any aaa.
> this explains why resource reserved unicast is such a dismal failure.

and some AAA effort is certainly necessary to make multicast
deployable.

However, it, by no means, is a sufficient condition.

It does not mean that current multicast protocols are usable if SIP
and yet another complex protocol are piled up on it.

It does not mean IETF is doing something meaningful for multicast or
AAA, either.

							Masataka Ohta