On (2011-04-29 18:34 -0400), david raistrick wrote:
3) as an a midstream network provider I have almost no motivation to support this. Sure, my network usage would be reduced - but I (more or less simplified here, but) make my living on each bit of traffic I carry - if I offered a way for providers and consumers to reduce their traffic, that would reduce the amount they pay me. Win for them, lose for me.
Aye. I'm always flabbergasted people complaining how other people should see the light and start to support multicast so we could reduce global bandwidth consumption. But multicast does not scale to global use, biggest problem is that for a router multicast is like flow switching, every flow you need to program in hardware. This means we'd need to regulate how and who can establish global multicast flow, which would unavoidably be unfair to some people. Second problem is security, random Internet user cannot change state in your routers today (except edge router ARP, which already is exploitable security problem), with multicast they can cause state to be changed in whole Internet. You need to be able to limit how many groups port can join, how fast port can join/leave per second, what groups port can join, same requirement is true for MSDP peers. It gets quite complex, quite fast, and these filters should be hardware based. We still regularly have security issues in BGP, it would be extremely unlikely if multicast didn't have lot of crash-Internet potential, due to end users ability to add/remove states from the core. Multicast has been and continues today to be solution for enterprise/application specific problems in closed domain and of course academic interest. If we actually want to reduce global bandwidth consumption, we need protocol which is stateless at least in in core. -- ++ytti