In einer eMail vom 27.11.2009 22:14:40 Westeuropäische Normalzeit schreibt [email protected]:
> 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. You refer to an important point: Assume there are 1 Mio. receivers and among them there were enough which are able to "cascade-branch" such that cascade-degree = 10 is sufficiently high. Then 1+10+100+1000+10000 +100 000 = 111 111 nodes must be knowledgable, while 888 889 dumb ones could assume to get plain unicast data. Also, for any transit router, it's pour unicast as well. Also unicast requests within a narrow time-window might be served in this way, too. DoS attacks would fail ! Heiner 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
