Subject: RE: mboned: FYI: Relayed Multicast Protocol

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 16 Nov 2005 12:35:11 -0500

Where practical implementations of TV program distribution over IP nets
today are "walled gardens," functionally similar to cable TV systems,
this RMCP tries to deliver TV programming (and other multicast
applications) over the open Internet, even before multicast-enabled
routers become the norm.

The basic approach is to use unicast IP, and have clients become relay
agents. Similar concept to MANET wireless ad-hoc nets. Each client may
become a relay, so that the clients will have to become aware of the
network topology and multicast relay tree topology.

My concerns would be:

1. Broadband links tend to be asymmetric these days, even beyond ADSL.
So it's not clear that a client can receive a reasonably high quality TV
stream, let alone relay that stream with equivalent quality back
upstream.

2. If the TV program delivery is meant to be non-real-time, which might
be more realistic, then Bittorrent is already out there, doing much the
same thing as RCMP.

3. Going back to real-time delivery, it certainly seems doubtful that
any single client could relay more than one program stream. Even with
H.264 compression, a TV stream equivalent to standard definition
programs requires about 2 Mb/s. But perhaps that's not a problem, if
there are enough clients out there to relay all the program streams.

4. Not sure how realistic it is to rely on the good will of other
clients for reception of your own TV programming. Isn't that also a
problem with Bittorrent? You depend on other supposedly disinterested
parties.

4. This does not appear to be something ISPs would work hard to help
deploy!

Bert

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

---

From: "Kevin C. Almeroth" <[email-masked]>
Date: Wed, 16 Nov 2005 13:43:28 -0800

>>I haven't gone through the document yet but on the surface it sounds like 
>>the individual clients relay to each other. If that's true, I can't see 
>>deploying a commercial service that supplies video to a group of paying 
>>subscribers that "depends" on getting the video from other clients.  This 
>>might be fine for those that are happy with the peer-to-peer model in use 
>>today to share files but that's a FAR cry from getting "reliable" broadcast 
>>video delivered.

This actually makes a lot of sense...  you download a 1.5 GB movie from a
bunch of peers.  You then buy a "key" from the provider that lets you
actually watch the movie.

Other users are incentivized to provide the download by getting some sort
of discount in the purchase of their own keys.

It is (or really should be) p2p with keys...  but called multicast...
relay multicast (think "bond, james, bond").

Otherwise, hmmm, let's see...  if this group finds out about a new
"multicast protocol" from a press release?!?  I'm not sure what
everyone is REALLY expecting.

-Kevin

---

From: "Kevin C. Almeroth" <[email-masked]>
Date: Wed, 16 Nov 2005 13:43:28 -0800

-Kevin

---

From: "Leymann, Nicolai" <[email-masked]>
Date: Fri, 18 Nov 2005 12:19:47 +0100

Hi,

> -----Ursprüngliche Nachricht-----
> Von: Beau Williamson [mailto:[email-masked]] 
> Gesendet: Donnerstag, 17. November 2005 15:28
> An: Marshall Eubanks
> Cc: Tom Pusateri; Dino Farinacci; [email-masked]; 
> [email-masked]
> Betreff: Re: mboned: FYI: Relayed Multicast Protocol 
> 
> 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.
> 
I agree. Several cache infrastructures are deploying a similar service for the distribution of content between caches (building a kind of overlay network between the caches). In this case such a approach may be valid because content is not realtime and the content is usually delivered on Demand to the end customers from the last cache. Even if you look on "Live Events" like Live8 this can be deployed; in this case tuning into a channel takes several seconds (15-30) and only a handfull of low bandwidth streams needs to be delivered to end users.

But for Live TV application this approach is not going to work for several reasons:

- channel switching times: 
Channel switching times are most critical for Live TV applications. End users want to experience the same zapping times as with "standard" scenarios. Depending on the video codecs to achieve acceptable times quite complex control mechanisms are needed. I do not see how this can be realized using RMCP or similar mechanisms.

- scalability:
Using some kind of overlay or application layer multicast means replacing P2MP connections with a corresponding number of P2P connections (speaking in terms of an IP-Network: using tunnels instead of IP-Multicast which as well provides limited scalability). This limits scalability at the ingress points (consider scnearios where you have a handful locations providing several 100 streams in HDTV quality to several 100 fanout locations).

- Changes in access networks:
Currently there is a move towards Ethernet based access networks which are well suited for IP-Multicast because the native broadcast/multicast capabilities of ethernet can be used. 

  Regards

     Nic

--
Nicolai Leymann
T-Systems International GmbH
Senior Expert, IP-Technologies
E-Mail: [email-masked]
Internet: http://www.t-systems.com