The implementation has already been done more than once. I spent a lot of time playing around with this, years ago.
I did not know that. Thanks for the correction.
The main obstacles are:
1) Multicast is not nearly widely enough deployed to be used as a general communications medium.
I would not characterize it as such. I think it is currently close enough, so that if the folks who collectively pour their time and effort into IRC, were to coordinate on choices of (non-UUnet) upstreams that support multicast, and the remainder (those without alternatives) were to tunnel to the (now-mainstream) multicast core, the benefits would outweigh the costs. Multihoming to get multicast may not cost much, if your total multicast traffic is small. Keep in mind you only have one copy of a given multicast stream, regardless of client base. Obviously, redundant multicast upstreams is advisable, if it's an important part of your business. The current folks doing multicast (and providing transit to those customers of theirs doing multicst), at tier 1 and peering with each other, includes the likes of Above.net, Exodus, Verio, Sprint, AT&T, Global Crossing, Level 3, Ebone, ESnet, Qwest, etc. The total list (which can be seen at http://www.multicasttech.com/status/mbgp.sum ) may only total about 3% of the AS's, but it's a very good 3%.
With companies like UUnet charging outrageous rates for multicast support or refusing to support it at all, this will not change.
2) IRC as it currently exists is not merely a message distribution system, ala USENET. IRC contains a lot of global state data, that has to be
For good or bad, there generally aren't networks *like* UUnet. (Let's not go there.) But to my knowledge, no one else charges for multicast, separately. If you give money to companies that do not support your efforts or requirements, who is to blame? Act in a coordinate fashion, and either 701 will support free (or sanely priced) multicast, or you'll be a customer of networks that already support it. propagated consistantly to all portions of the network. I don't want to waste too much bandwidth on this (especially since I'm neither an IRC admin nor user), but... The global state info, consider it as a whole. Any of that info is either used for forwarding decisions (data plane), or not, ie for "administrative" purposes (eg identifying current users on a given channel), correct? (Info about other IRC servers I would categorize as data plane stuff). In a multicast, true multicast, environment, the data plane would not require *any* servers, per se. That is the important element of multicast benefit. All the state info *for forwarding* would be kept on ISP router infrastructure (yes, scaling is an issue, blah blah blah). Large (regional or national) ISPs will generally have fully redundant and dynamic multicast infrastructure, if multicast is deployed. (I'm talking MBGP/MSDP/PIM, not DVMRP; redundacy include lots of RP's.) BTW, I know of what I speak; at my previous employer (Teleglobe), we had deployed such an infrastructure internationally and participated at the MIXs, and even provided multicast transit for the multicast feed from the OSLO IETF. The "other" state information, isn't part of the forwarding chain; if that were to remain on servers, and continue to be maintained via unicast TCP, there is no need to put all the other TCP/multicast stuff in. So you would have a hybrid client, using TCP and servers for state info, and multicast/UDP for actual messages. Attacking the servers doesn't affect messaging, and any attack on part of the multicast tree, towards any particular goal (eg nuking a particular client's connection), will be transient in nature and either (a) close to the victim, thus limited in scope and number of affected clients, or (b) a moving target within the multicast-enabled infrastructure, and virtually impossible to disrupt for extended periods short of bandwidth-based attacks. So how is this any better than the current status? Well, if a server dies for whatever reason, the communication pathways themselves are unaffected, only the convenience stuff. And since that gets propogated to other servers, client side software can select alternate servers for that information. Maybe I'm missing some fine points on how IRC is implemented. (3 and 4, security and deployment/conversion/porting - I acknowledged those issues in my original message.) If there is no interest in either stopping DDOS, or in a survivable IRC network, I'll stop contributing to this thread. I'd like DDOS activity to die off, but have no opinion or interest in IRC, per se. But I'd recommend those involved in IRC give this serious consideration. Brian Dickson