Re: [tana] Why not SSM?

[Marshall Eubanks <[e-mail]>]

On Aug 15, 2008, at 8:15 PM, The 8472 wrote:

> I can't browse the archive right now, so sry if this has been  
> discussed before. I have suggested the following repeatedly in  
> various places and it always ended w/o any insight due to the lack  
> of knowledge regarding the core internet infrastructure.
>
> Everything i have seen so far amounts to alchemy...
> We're trying to preserve P2P-performance for the enduser while  
> easing the load on ISP infrastructure and maintaining fairness. The  
> problem is that P2P applications are a zero-sum-game. Things that  
> are downloaded must be uploaded somewhere else.
>
> All the voodo protocols can either shuffle the bandwidth around to  
> other ISPs or lower the overall performance of the P2P applications.  
> Considering that Comcast basically is highly allergic to any kind of  
> sustained upload due to... humhum... shortcomings in the cable  
> network infrastructure this would mean any effective solution would  
> more or less shift significant proportions of their upload to other  
> ISPs. Other ISPs in turn may not like transit rather than upload on  
> the last mile. Now... combine these two and you have conflicting  
> interests, which in turn might result in conflicting policies  
> between various ISPs.
>
> Anyway, i'm digressing. As i said all we can do with the current  
> approaches is shuffle around bandwidth. The real solution would be  
> breaking up the zero-sum-game. And multicast does exactly that.  
> Source-Specific Multicast (RFCs 3569, 4607) is ideally suited for ad- 
> hoc allocation of groups as nodes always join a (source, group)  
> tuple, i.e. there wouldn't be any collisions.
>
> Now let's imagine an ideal world. Globally scoped SSM works and is  
> available to every enduser (as source and as sink). 10 people with  
> 2Mbit upload each could serve an aggregate bandwidth of 20Mbit to an  
> unlimited amount (until we run out of v6 addresses) of group  
> subscribers. This would reduce the bandwidth consumed on the last  
> mile to downloads and almost no uploads, and transit bandwidth would  
> be 20Mbit tops (assuming non-redundant / sparse trees) - even less  
> assuming the 10 uploaders are spread throughout various ISPs.
>

There is a protocol called AMT intended to deal with this issue. See

draft-ietf-mboned-auto-multicast-09.txt


> Ok, back to the real world which is far from ideal. I know that many  
> home routers don't support IGMPv3, let alone IPv6/MLD. I also figure  
> that millions of mcast group subscriptions done at high churn rates  
> spread throughout the internet and at least ten-thousands of group/ 
> source tuples would put a significant strain on the routing tables.

It isn't SSM, but if this is a problem, IPv6 embedded RP might be  
worth looking into.


>
> If anyone is aware of further problems (and i guess there are  
> plenty), please enlighten us.
>

If you want to do a proposal, we will listen in MBONED.

Regards
Marshall


>
> But even if there are lots of obstacles, the idealized scenario  
> should show that it's worthwhile as it would tackle the problem at  
> its root instead of mitigating the symptoms. So, my question is if/ 
> how/when can we deploy SSM? Or why can't we?
>
> And even if we could there'd still be various open issues for  
> protocols running ontop of SSM, e.g. that SSM is unidirectional and  
> we'd need some congestion control feedback over multiple unicast  
> links to allow the sender to adjust his send rates, we also might  
> have to work with SSM scoped to the ISP/AS level and interconnect  
> various SSM-islands via unicast. We'd need strategies to minimize  
> the number of active groups while still providing enough choice for  
> downloaders to pick various streams to saturate their download link  
> etc. etc.
>
> --
> The 8472
> independent developer for the Azureus Vuze Bittorrent client
> _______________________________________________
> tana mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tana

_______________________________________________
tana mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tana