Subject: Re: mboned: FYI: Relayed Multicast Protocol

From: Dino Farinacci <[email-masked]>
Date: Wed, 16 Nov 2005 16:42:10 -0800

>> 	pdf attached.
>> 	Dave

    Here are my comments:

    o The slides seem to show replication is done inside the cloud but since
      the description indicates an overlay design, we know the replication
      is done at the edges.

    o The forwarding path is for a source-node to send one packet to a 
      neighboring node which in turn sends to another neighboring node 
      (similar to the path in a ring topology). The latency can't be good for
      the last guy. The solution would be better (but not as good obviously as
      native multicast) if the neighbor relationships were in a tree layout.
      Then there would be less duplication in the underlying network if
      configured closely to the physical topology (good luck).

    o The presenter indicates an advantage is that RMCP is an international
      standard. More often than not, that is a disadvantage since you can't
      have fast or maybe any change control.

    o Coupling the overlay delivery model with reliability is a good but
      natural idea. But the latency and dependence on your neighbor node will
      make this proposal a non-starter.

    If this could be implemented similar to an FDDI bypass switch then it
    would easier to swallow. But if you are going to have software in a
    neighboring node responsible for getting packets to you, there is going to
    be all kinds of security concerns and video quality concerns.

Dino

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 16 Nov 2005 20:11:59 -0500

>    be all kinds of security concerns and video quality concerns.

Given that lots of people wanting to use this are on broadband connections
(dsl or cable), and that your upload speed is much lower than your download
speed, you will probably be able to feed at most one downstream peer.

That means you end up with linear forwarding from one node to the next
and the error rate at any one node is the sum of the errors on every
link before it.

If you're just doing file transfer, then you could just use the existing
p2p networks. So this is meant for live but this doesn't seem to solve
this probelm well either since the quality gets worse the further away
you are.

My $0.02, just ignore it. Someone should teach these guys about AMT.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 16 Nov 2005 17:31:00 -0800

>> My $0.02, just ignore it. Someone should teach these guys about AMT.

    All good points.

Dino

---

From: Beau Williamson <[email-masked]>
Date: Wed, 16 Nov 2005 21:45:08 -0600

>My $0.02, just ignore it. Someone should teach these guys about AMT.

Someone should teach them the "realities" of IP networks.  Sounds like they 
are in la-la land to me.  But then what do I know.  I was the one that 
thought that the proposal to put PIM signaling in BGP was a BAD idea.

Beau

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 17 Nov 2005 00:53:53 -0500

Hi Beau;

On Nov 16, 2005, at 10:45 PM, Beau Williamson wrote:

> Someone should teach them the "realities" of IP networks.  Sounds  
> like they are in la-la land to me.  But then what do I know.  I was  
> the one that thought that the proposal to put PIM signaling in BGP  
> was a BAD idea.
>

Dear Beau;

I call this the generational problem - if everyone has about  the  
same resources, so that there are no super nodes, then even if you  
send out two copies of everything you receive, to get to 2000 people  
requires an average
path length of 10, which with even small amounts of packet loss is  
real bad news. There was a time when I
thought that this was fatal for any widespread distribution of  
streaming type material through P2P. Now I
don't feel that way, and here is why.

First, consider a podcasting type scenario (I send you instructions  
on what files to play, but not necessarily the files themselves).  
There, there is no guarantee that everyone gets or plays the "stream"  
at the same time, and yet it is now very popular.

Next, consider BitTorrent (http://en.wikipedia.org/wiki/Bittorrent).  
The  originator sends out one seed (copy of a file), and recipients  
start sharing 256 KB slices as soon as they  receive them. For a  
popular file, you have lots of people sending 256 KB slices of the  
file around, so you can actually receive it faster (from many  
sources) as you get more generations away from the source. Of course,  
you get stuff in random order; and the protocol keeps track of who  
has what slice. Since you have (for a popular file) multiple ways to  
get each slice, reasonable levels of packet loss are not a problem.

The protocol actually works well for popular stuff; it doesn't work  
so well if the file is unpopular. (If I never
request a slice, I can't send it to you.) And, once the initial  
distribution  is done, the file is unavailable except from the  
original source. Obviously, BT + podcasting is a form of streaming,  
and this is done today.

Fairly obvious extensions would be to move to a true streaming  
scenario, where the "file" is replaced by a (fairly long) buffer, and  
where participants may be receiving and sending copies of slices that  
they actually don't need
(i.e., acting more like multicast routers). The key here is that the  
protocol doesn't really care super much about efficiency (multiple  
people can send you those slices), and even a small set of P2P users  
(many millions) is a lot bigger than the potential number of channels  
at one time (by my estimates, likely to be order 100,000).

In addition, there is no reason that the BT protocol couldn't claim a  
fairly small amount of user's hard drives, so that multiple copies  
(encrypted or not) of stored media are already distributed (so that  
the popularity of content becomes irrelevant). IMHO distributed P2P  
storage is likely to be  as big a deal in the near future as  
distributed P2P bandwidth has been in the recent past.

Now, this may never be the means of distributing the US Superbowl  
broadcast, but that doesn't mean  that it doesn't have its uses. I  
think that for AMT-2 a useful idea might be to think about how to  
hook multicast edge routers into a BT type network, so that the  
bandwidth is truly flat rate in cost right out to the edge.

(BTW, I agree with you about BGP and PIM.)

Regards
Marshall

> Beau _______________________________________________________________

---

From: Beau Williamson <[email-masked]>
Date: Thu, 17 Nov 2005 08:27:35 -0600

Marshall,

I understand that this method could be successful for the sort of casual 
distribution of content.  I'm not disputing that.  What I was talking about 
was the use of this method as an alternative to providing video service to 
the home such as cable or other broadcast methods.  I just don't see it 
being able to play there.

Beau

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 17 Nov 2005 14:47:10 +0000

check out
http://www.research.microsoft.com/~pablo/avalanche.aspx
although, to be fair, the bittorrent folks were negative about it - we
did a net coded version of bittorrent as a student project, which also
demoed the idea....

there's no way you'd use this for many-to-many realtime because of the
delays ,but its plenty good for one-to-many streaming....

but of course, the ISPs of the world wil lbe turning on IP native ASM
Multicast any day now coz of all that IPTV latent demand

j.

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 17 Nov 2005 09:53:07 -0500

Play, yes. Displace, no.

I think we are in violent agreement here.

Marshall

On Nov 17, 2005, at 9:27 AM, Beau Williamson wrote:

> Marshall,
>
> I understand that this method could be successful for the sort of  
> casual distribution of content.  I'm not disputing that.  What I  
> was talking about was the use of this method as an alternative to  
> providing video service to the home such as cable or other  
> broadcast methods.  I just don't see it being able to play there.
>
> Beau