Subject: [rrg] Stateless Multicast resp. replicable Unicast (was...

From: [email-masked]
Date: Tue, 1 Dec 2009 03:43:23 EST

I think the Multicast discussion should continue, however it is a different 
 topic than mobility.
Therefore and because I once launched "MIP in a future routing  
architecture" I suggest to continue the discussion using above headline.
Also: the MIP- discussion might go on by using the unmodified  headline
Heiner

In einer eMail vom 29.11.2009 21:05:57 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hi  Shane,

> for 'live' content, given the inherent efficiency of  multicast.

I am not questioning the efficiency of multicast. In fact I  am looking 
at peercasting and can't find it's inefficiencies either  provided it is 
deployed in a proper manner.

I am not talking about  residential hosts replicating the live content. 
But if you place your  peercasting servers in the key network locations I 
could argue that  peercasting can be as efficient as multicast both in 
core as well as  distribution levels.

The difference between the two is just the way  such distribution tree is 
constructed. In multicast you have protocol  which in most cases (not 
talking about p2mp te) follows the unicast  routing to reach the src.

On the other hand in peercasting you can use  many other elements like 
RTT, feedback from ALTO servers, routing  proximity, sources load etc ... 
for the tree building decision which may  be hard to do by multicast.

While you are right that for live streaming  multicast may be the winner 
there is IMHO much bigger market for on demand  file, video,audio 
streaming where caching may be of huge importance. And I  guess this is 
very clear that hosts/servers are much better in content  caching then 
routers.

Cheers,
R.

> Robert,
>  
> On Nov 29, 2009, at 03:48 MST, Robert Raszuk wrote:
>>  Tony,
>> 
>> Isn't it a case that multicasting has been  already obsoleted in the
>> quite significant degree by peercasting  ?
>> 
>> http://www.viswiki.com/en/Peercasting
>  
> IMHO, I think it's rather difficult to predict that  peercasting
> has/will obsolete multicast, at least in the U.S. and,  specifically,
> for truly "live" content, e.g.: sports, news broadcasts,  etc.
> Unfortunately, the usual chicken-and-egg problem exists: no  widely
> appealing, legitimate content exists, therefore there is no  demand,
> hence very few SP's set-up their infrastructure to provide  multicast
> down to CE devices.  However, with the dearth of  *unicast*
> time/place-shifted video content coming online by the major  players
> (cf: Hulu, Apple, Netflix, Blockbuster, etc.), it may be a  matter of
> time, before we start to see a growing demand for  *multicast* video
> for 'live' content, given the inherent efficiency of  multicast.
> 
> Furthermore, while peercasting is an intriguing  application-level
> form of multicast, (therefore, allowing a content  owner/distributor
> more control over when & how they distribute  their content w/out
> having to wait for the network to be ready), it's  not without it's
> "challenges", specifically: - asymmetric BW on  residential access
> circuits, making it difficult to hairpin/push  content back up into
> the network; - lack of some form of CoS on lower  bit-rate residential
> lines to either: a) assist with pushing  hair-pinned content back up
> into the network; and/or, b) avoid  interfering with other legitimate
> apps on the access circuit, (e.g.:  VoIP, etc.) - etc.
> 
> I guess time will tell.
> 
>  -shane
> 
> 
> 
>> And I am not that convinced that  replication at network
>> router/switch level is that much more  efficient then replication at
>> the network host level. I think it  is just a matter of efficiently
>> determining the optimal  replication points.
>> 
>> Cheers, R.
>>  
>>> Dino Farinacci wrote:
>>>> Well if multicast  proper is not on the requirements for scaling
>>>> the routing  architecture, how can we set our sights higher?
>>>>  
>>>> Do you expect multicast route scaling to be solved in  some
>>>> other forum like perhaps SAMRG?
>>> I  think you can just work on it.  No permission is required.   But
>>> first you should take this up with the guys who have been  working
>>> on multicast for the last 17 years.  ;-)  Seriously tho, if that's
>>> a useful work item, the RG can take  it up after   this work item
>>> is complete. Tony  _______________________________________________
>>>  rrg  mailing list [email-masked] 
>>>  http://www.irtf.org/mailman/listinfo/rrg
>>  _______________________________________________ rrg mailing list 
>>  [email-masked] http://www.irtf.org/mailman/listinfo/rrg
> 
>  
> 

_______________________________________________
rrg  mailing  list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: [email-masked]
Date: Tue, 1 Dec 2009 04:18:19 EST

In a previous email I said (more or less) Stateless Multicast is  
independent from the scalablity issue and that was in view of my older Cascade  Tree 
of p2p-relays proposal. 
But now I become fully aware of the mutual help. Cartainly, I was always  
aware that the receiving hosts can't be the relaying nodes (uploading is too  
slow), instead it must be something close to them: the egress router, or 
the ETR  (which has a correspondent node in TARA however with a routable and 
not just  mappable token).
 
Is cascade tree routing (cascade tree of p2p's) itself scalable ? Oh yes.  
Just claim the scale ratio, i.e just claim the needed cascade degree!
 
The second message is: any tree of p2p's will benefit if relay nodes can be 
 identified, no matter whether they have routable or (just) mappable  
addresses.
 
Heiner