Subject: Re: [rrg] MIP in a future routing architecture

From: [email-masked]
Date: Thu, 26 Nov 2009 04:40:25 EST

In einer eMail vom 26.11.2009 02:35:49 Westeuropäische Normalzeit schreibt  
[email-masked]:

Did  anyone indicate if multicast was a fundamental requirement or   
fundamental component?

Dino

Multicast: It strikes me that multicast has never been a topic for RRG  
discussion, although it is mainly a routing issue.
 
State-less multicast would be a valuable topic, I thought 3 years ago when  
I tried to launch a respective EU-ICT project which was rated to be "very  
poor" (not only simple "poor" as was NIRA).
 
However, state-less multicast can be done by changing the multicast  
philosophy. Multicast must adjust, and not the routing architecture. Will say,  it 
can be accomplished with the current BGP as well.
Nevertheless, the combination "state-less multicast + location-based  
routing" might be even more beneficial. E.g. inspire future research  work as to 
minimize the hereby accepted disadvantages/costs.
 
Heiner

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Nov 2009 10:27:50 -0800

> In einer eMail vom 26.11.2009 02:35:49 Westeuropäische Normalzeit  
> schreibt [email-masked]:
> Multicast: It strikes me that multicast has never been a topic for  
> RRG discussion, although it is mainly a routing issue.

I would like to know if the RRG is going to recommend an architecture  
that explicitly says it won't include multicast, or it will implicitly  
include it but lack any reference to how it will scale. But I do think  
"multicast" is "routing".

> State-less multicast would be a valuable topic, I thought 3 years  
> ago when I tried to launch a respective EU-ICT project which was  
> rated to be "very poor" (not only simple "poor" as was NIRA).
>
> philosophy. Multicast must adjust, and not the routing architecture.  
> Will say, it can be accomplished with the current BGP as well.
> routing" might be even more beneficial. E.g. inspire future research  
> work as to minimize the hereby accepted disadvantages/costs.

What the RRG could recommend is that we don't support a native  
multicast architecture in the core but the edges could run multicast  
as defined today but the edges would perform "replicated unicast".

I provide references to a "replicated unicast" at the network layer as  
well as attaching doing core based native replication as in LISP- 
Multicast.

Dino

---

From: Tony Li <[email-masked]>
Date: Fri, 27 Nov 2009 17:08:10 -0800

> "multicast" is "routing".

Well, you may recall that when we started this work, we put together a 
list of requirements.  There were no explicit requirements for 
multicast.  Thus, I would think that this is orthogonal to the task at 
hand.  From the proposals that I've seen, most will deal with multicast 
implicitly.

> What the RRG could recommend is that we don't support a native multicast 
> architecture in the core but the edges could run multicast as defined 
> today but the edges would perform "replicated unicast".

That is certainly possible.  However, I hope that we have our sights set 
higher than that.  Replicated unicast is simply not multicast and 
clearly does not scale.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 28 Nov 2009 11:50:10 -0800

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?

Dino

On Nov 27, 2009, at 5:08 PM, Tony Li wrote:

> Dino Farinacci wrote:
>
>> I would like to know if the RRG is going to recommend an  
>> architecture that explicitly says it won't include multicast, or it  
>> will implicitly include it but lack any reference to how it will  
>> scale. But I do think "multicast" is "routing".
>
>
> Well, you may recall that when we started this work, we put together  
> a list of requirements.  There were no explicit requirements for  
> multicast.  Thus, I would think that this is orthogonal to the task  
> at hand.  From the proposals that I've seen, most will deal with  
> multicast implicitly.
>
>
>> multicast architecture in the core but the edges could run  
>> multicast as defined today but the edges would perform "replicated  
>> unicast".
>
>
> That is certainly possible.  However, I hope that we have our sights  
> set higher than that.  Replicated unicast is simply not multicast  
> and clearly does not scale.
>
> Tony

---

From: Tony Li <[email-masked]>
Date: Sun, 29 Nov 2009 01:47:08 -0800

> Do you expect multicast route scaling to be solved in some other forum 

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

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 29 Nov 2009 11:48:58 +0100

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

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.

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

---

From: Shane Amante <[email-masked]>
Date: Sun, 29 Nov 2009 07:57:06 -0700

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 ?
> 

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

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 29 Nov 2009 21:05:39 +0100

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.

> 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?
>>>> 
>>> 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] 
>> _______________________________________________ rrg mailing list 
>> [email-masked] http://www.irtf.org/mailman/listinfo/rrg
> 
> 
>