Re: [tana] Why not SSM?

[Stanislav Shalunov <[e-mail]>]

[TANA BoF co-chair hat on]

TANA is an IETF transport area activity the main focus of which is  
working on congestion control that keeps delay low across congested  
bottlenecks.  Related transport issues, such as UDP framing, the use  
of multiple transport connections, etc., are also in scope.

The discussion of multicast as it applies to the architecture of P2P  
apps is completely off-topic for TANA.

[TANA BoF co-chair hat off]

P2P applications as we have them today *are* implementations of  
multicast for overlay logistical networking.  Overlay networking is  
the use of end nodes of an underlying network to route traffic in a  
virtual (overlay) network.  Logistical networking is moving and  
storing entire files (or big chunks of data) instead of just  
delivering packets.

Another such overlay implementation of logistical multicast are CDNs.

If multicast on the Internet worked, there would be no need for P2P  
apps and, therefore, no P2P apps.  Reasons why multicast doesn't work  
on the Internet today are various and variously viewed.  From my  
perspective, the main reasons are:

1. Multicast architecture is not locally scalable.  As the number of  
multicast joins grows globally, a given router becomes busier.  This  
is particularly brutal with ASM, but SSM, which is meant to make  
multicast a bit more locally scalable, and does achieve this goal  
compared to ASM, still does not have the same scalability properties  
as unicast.

2. Multicast configuration is very fragile.  Every use of multicast I  
was involved in started with a debugging session.  The session  
involved experts of level that not every ISP can be expected to employ  
and was invariably rather long.  If doesn't just work, not at all.

3. Pricing for multicast is complicated.  Do you charge per bit in?   
Then the ISP loses.  Per bit out?  Then the sender has little  
incentive to use it over unicast.

4. Multicast has no good answer for congestion control.

P2P addresses all of these problems.  It is locally scalable (any  
point on the network sees amount of traffic proportional to local  
activity), robust (in fact, it not just works without debugging  
sessions by ISP personnel, but, as we're all are too acutely aware,  
often even in the face of attempted external disruption), and, because  
it runs over unicast, allows the unicast pricing model and congestion  
control to be applied.

The cost of these advantages is bit efficiency that is not as high as  
that of multicast.  In particular, the most expensive traffic, that on  
the last-hop links, doubles with P2P.  Transit traffic can also be  
quite suboptimal.

The great news about P2P is that the bit efficiency can be  
incrementally improved without losing any of the advantages.  The main  
way to do so is caching.  An additional way of improving bit  
efficiency is better peer selection (see also ALTO).

In TANA, our goal is to do neither of these.  We're here to work on  
congestion control.  See the TANA problem statement:
http://tools.ietf.org/html/draft-shalunov-tana-problem-statement-01

Perhaps, in the future, all of the main four problems I list above are  
solved somehow.  The need for the overlay hack that P2P is then might  
go away.  TANA, however, is not working on categorizing or solving  
multicast deployment problems.

-- 
Stanislav Shalunov
Director, Engineering
BitTorrent Inc


On Aug 15, 2008, at 5: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.
>
> 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.
> If anyone is aware of further problems (and i guess there are  
> plenty), please enlighten us.
>
>
> 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

--
Stanislav Shalunov



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