Subject: Re: Raising the bar on the MBone

From: [email-masked]
Date: Mon, 4 Aug 1997 14:42:13 -0700 (PDT)

Hugh said:    

    I really don't want to let this part of the discussion die.
    Consider that N receivers want to receive a particular datastream.
    They have a choice of receiving it unicast or multicast.
    
    In the unicast case, the source has to send N streams to each
    of the N receivers.  The ISPs connection to the source has
    to carry N copies, and the subsequent links have to carry
    some fractions thereof as the paths diverge.  
    
    Now in the multicast case, the ISP has only to carry one stream
    from the source, an increasing number of streams up to the
    final destinations.  Now, in no case does the link ever have
    to carry more than one copy.

Everyone knows this.  Everyone accepts this.

Some things that I think keep getting ignored:

  --the additional state that the routers may
        have to carry depending on the protocol being used.

  --if the ISP's use closest exit routing, one ISP that has a lot of 
        sources can cause other ISPs to carry all of the multicast traffic.
        If the only way to charge for multicast is that the source pays,
        those ISP's with no sources get stuck with no income and a lot of
        traffic.  Sources pay for it with advertising.  How do receivers
        pay?

  --Current routing protocols are flat, no heirarchy.  Lot's of routes
        use lots of memory.  No BGP.

  --There aren't good ways of setting policy for who carries what.  No
        BGP for multicast.

  --There is little experience with multicasting over a large area.  The
        MBONE isn't a large area because its all tunnels.  (yes it covers
        the whole globe, so what.)

  --current protocols don't scale to cover the entire world.
        PIM densemode and DVMRP periodically flood everywhere even if they
        prune off quickly, which sometimes doesn't happen, there is a
        significant use of bandwidth in getting things to a stable condition.
        Where do you propose placing the RP for PIM sparsemode?  Can you
        imagine the dykstra that MOSPF would have to calculate?  Every router
        would have to be a cray.

  --There are a lot of mrouted machines running on unix boxes.  They can't
        handle all the routes in the internet.  How do you propose keeping
        these systems up and running?  

At first glance, one only sees the advantages of using multicast.  Its the
details that hurt.

This is just an opinion, but if I hold my breath till I'm blue (ie, if 
I constantly demand, which seems to be the operative word here) I'm not
going to get to ride in the space shuttle.  So, users can demand multicast
on the internet all they want, it isn't going to happen until the tools arrive

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 05 Aug 1997 08:54:50 +0100

>on the internet all they want, it isn't going to happen until the tools arrive

if we change the dvmrp/mrouted to do route aggregation, the unix mrouted's
will handle the full internet routes BETTER than some of the
commercial so called produicts out there, becvause memory is CHEAPER
and the mbone that is routing thru these boxes is not hugely
performance critical...if it is, then the basic entry prioce (given
people will have paid for lines that are fast enough for fasdt mbone
traffic) is to buy proper routers......

my guess is sometime soon, we will see a solid PIM or CBT release for a unix
box - that with a good gated setup will see you through the next 3
years or so....

and the rate of increase of PERCENT of the mbone that is in native
routers is quite healthy last time i looked.....

 jon

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 05 Aug 1997 08:54:50 +0100

jon