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

From: [email-masked]
Date: Fri, 27 Nov 2009 14:25:09 EST

In einer eMail vom 27.11.2009 19:28:17 Westeuropäische Normalzeit schreibt  
[email-masked]:

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

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".
Totally in sync.

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

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".

Yes, replicated unicast ! My idea was: building a cascade tree of  unicasts 
for sake of multicasting towards millions of receivers in a most  
economical way:
To catch the basic idea: the sender sends the data to 10 receivers (or  
their proxies), which in return send them to 10 further receivers etc.
Given that each party gets the same list of participants it will be able to 
 identify its 10 successors based on its own position inside this list.
Furthermore: the degree 10 might not be sufficient if there are only m  
branching-capable nodes while n>>m receivers are to be serviced.So I was  able 
to compute the adequate "degree of cascading" and also to compute the  
adequate positions of the branching-capable nodes inside this list of  
participants.
Effectively, there is only unicast between any two branching capable nodes, 
 and let's say 90 % of the receivers are stupid ones being leaves of the 
cascade  tree.
 
Disadvantage: via the same physical link several copies of the same packet  
might be forwarded.
Advantage: states are required just at a minority of  
branching-nodes.Combined with location-aware routing the disadvantage might  be reduced 
eventually upon further study. 

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

I will read the sent draft in the coming days.
 
Heiner

---

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

> In einer eMail vom 27.11.2009 19:28:17 Westeuropäische Normalzeit  
> schreibt [email-masked]:
> Yes, replicated unicast ! My idea was: building a cascade tree of  
> unicasts for sake of multicasting towards millions of receivers in a  
> most economical way:
> To catch the basic idea: the sender sends the data to 10 receivers  
> (or their proxies), which in return send them to 10 further  
> receivers etc.
> Given that each party gets the same list of participants it will be  
> able to identify its 10 successors based on its own position inside  
> this list.
> Furthermore: the degree 10 might not be sufficient if there are only  
> m branching-capable nodes while n>>m receivers are to be serviced.So  
> I was able to compute the adequate "degree of cascading" and also to  
> compute the adequate positions of the branching-capable nodes inside  
> this list of participants.
> Effectively, there is only unicast between any two branching capable  
> nodes, and let's say 90 % of the receivers are stupid ones being  
> leaves of the cascade tree.
>
> Disadvantage: via the same physical link several copies of the same  
> packet might be forwarded.
> Advantage: states are required just at a minority of branching- 
> nodes.Combined with location-aware routing the disadvantage might be  
> reduced eventually upon further study.

I think we should try to use multicast where it is available but not  
require it end-to-end or else we'll never have a solution deployed.  
This is already evidence from the IPv4 multicast Internet, where is is  
available in many places but can't be trusted to be everywhere.

The point is that the routing folks should deliver a "multi-recipient"  
service to the applications so app writers can assume there is end- 
point multicast capability (i.e. joining groups, send 1 packet from  
the app to the group, etc).

And how we, at the routing layer, get those packets to all recipients  
is open for architectural discussions. One example is doing AMT over  
LISP-Unicast versus doing LISP-Multicast.

Dino