In einer eMail vom 27.11.2009 19:28:17 Westeuropäische Normalzeit
schreibt [email protected]:
> In einer eMail vom 26.11.2009 02:35:49 Westeuropäische Normalzeit
> schreibt [email protected]:
> 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 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
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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
