Subject: mboned: FYI: Relayed Multicast Protocol

From: David Meyer <[email-masked]>
Date: Wed, 16 Nov 2005 07:18:35 -0800

pdf attached.

	Dave

> > ITU Standardized Technology Set To Spawn New Era Web Broadcast
> >  _____
> >
> >With the popularity of blogs, podcasting and web-based photo  
> >libraries,
> >web content has become something much more accessible to the  
> >individual
> >in the last few years. Now video looks set to be the next media to  
> >gain
> >popularity with the new generation of home based media moguls.
> >
> >Work on a new protocol that may spawn a whole new generation of
> >independent broadcasters is underway at ITU. Relayed Multicast  
> >Protocol
> >(RMCP) being developed by the ITU's Study Group 17
> ><http://www.itu.int/ITU-T/studygroups/com17/mgmt.html>  uses something
> >like a peer-to-peer model meaning that independent broadcasters no
> >longer have to subscribe to a fat-pipe, instead relying on a  
> >collection
> >of 'peers' or 'relay agents', in other words other people's computers.
> >Peer to peer type traffic is reckoned to make-up as much as 72 per  
> >cent
> >of current Internet traffic. And this figure is predicted to rise.
> >
> >RMCP allows the live broadcast of video or audio piggy-backing off  
> >other
> >users (or servers). So in a scenario where 100 people are demanding a
> >live broadcast, instead of serving each one of these clients their own
> >video stream, only one stream has to be provided and each user will be
> >served from another in the network. This has significant implications
> >for instance for businesses broadcasting live events, where a previous
> >scenario demanded 100 users be fed individual feeds, RMCP allows the
> >broadcast of just one.
> >
> >Juyoung Park the editor of the ITU-T Recommendations says that RMCP
> >allows for the efficient serving of hundreds of thousands of
> >simultaneous connection requests.
> >
> >Park says that the need for this type of protocol was identified by
> >content providers. Standardization means that a single client can
> >receive content from any number of suppliers.
> >
> >An alternative solution - IP Multicast - is not applicable in today's
> >networks according to Park. For a start the success of IP Multicast
> >would mean router upgrades throughout a network, something that many
> >operators would balk at, especially given the unclear benefits of IP
> >Multicast to their revenue streams.
> >
> >Park says that tests by his organization - ETRI - have shown that  
> >speeds
> >of 2 Mbit/s are possible. This reflects standard broadcast rates.
> >However he says that typically users will experience something more  
> >like
> >640 Kbit/s.
> >
> >ITU-T has published one Recommendation (ITU-T Rec. X.603) on the topic
> >outlining requirements, framework etc. The next two Recommendations  
> >due
> >in 2006 will focus on the technical specifications. One focusing on  
> >one
> >broadcaster to many clients, and the other on many broadcasters to  
> >many
> >clients.

----- End forwarded message -----

---

From: Jeremy Hall <[email-masked]>
Date: Wed, 16 Nov 2005 12:01:11 -0500 (EST)

What? you've got to be kidding.

What is this? inventing mrouted without any of the benefits? and no 
bandwidth reservation or congestion control? How does it elect who gets to 
pull what snippet from what person?

How can this succeed?

_J

> ----- End forwarded message -----

[Attachment, skipping...]

[application/pgp-signature is not supported, skipping...]

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

---

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

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.

My $0.02 worth.

Beau Williamson
At 11/16/2005 09:18 AM, David Meyer wrote:
>  mboned FYI Relayed Multicast 
> .ems<file://C:\DOCUME~1\bwilliam\MYDOCU~1\Email\Attach\mboned FYI Relayed 
> Multicast .ems <0880.0002>>
>*** PGP SIGNATURE VERIFICATION ***
>*** Status:   Good Signature from Invalid Key
>*** Alert:    Please verify signer's key before trusting signature.
>*** Signer:   David Meyer <[email-masked]> (0xA099D8A7)
>*** Signed:   11/16/2005 9:18:35 AM
>*** Verified: 11/16/2005 10:52:28 AM
>*** BEGIN PGP VERIFIED MESSAGE ***
>
>         pdf attached.
>
>         Dave
>
>
><file://C:\DOCUME~1\bwilliam\MYDOCU~1\Email\Attach\H1.pdf> H1.pdf
>
>
>*** END PGP VERIFIED MESSAGE ***

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Nov 2005 19:34:21 +0200 (EET)

On Wed, 16 Nov 2005, Beau Williamson wrote:
> 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.

mmm.. sounds something like... Skype?

(One important difference may be the amount of B/W needed for reliable 
"relaying")

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Jeremy Hall <[email-masked]>
Date: Wed, 16 Nov 2005 12:01:11 -0500 (EST)

How can this succeed?

_J

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 16 Nov 2005 19:17:22 -0500

Hello;

On Nov 16, 2005, at 11:57 AM, Beau Williamson wrote:

> 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

I can. In fact, this doesn't really sound like a new idea, unless it  
includes distributed storage (sure to be the next big buzz in this  
space). Of course, "broadcasting" might be more like "podcasting",  
some sort of mix of VOD and streaming. But I can guarantee you that  
people are planning on making money from this sort of thing. (Of  
course, whether they _will_ is another matter.)

I wonder what's the relation between this and the existing P2P  
protocols. Should know soon.

Regards
Marshall

> 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.
>
> My $0.02 worth.
>
> Beau Williamson
>>  mboned FYI Relayed Multicast .ems<file://C:\DOCUME~1\bwilliam 
>> \MYDOCU~1\Email\Attach\mboned FYI Relayed Multicast .ems <0880.0002>>