Subject: [tana] Why not SSM?

From: The 8472 <[email-masked]>
Date: Sat, 16 Aug 2008 02:15:32 +0200

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
[email-masked]
https://www.ietf.org/mailman/listinfo/tana

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 15 Aug 2008 20:45:28 -0400

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.
>
> 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.  
> 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.
>
> 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.
>
> 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

> 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

---

From: The 8472 <[email-masked]>
Date: Sat, 16 Aug 2008 17:00:28 +0200

> draft-ietf-mboned-auto-multicast-09.txt
I do not think this is suitable for the problems we are discussing here 
(namely P2P usage) as P2P systems try to ensure fairness between 
clients. AMT seems to do multicast manually by sending each multicast 
packet tunneled through unicast to each site. SSM is only suitable for 
P2P if the loss of control over fairness is compensated by the bandwidth 
amplification done by sending data once and multiplying it along the 
path. We'd basically have to do AMT manually over normal P2P-unicast 
links between existing (if there are any... which is one of my 
questions) multicast islands.

> If you want to do a proposal, we will listen in MBONED.
I'm asking questions (see subject), not aiming to make a proposal. I 
don't know enough about the current progress of mcast/ssm support on the 
internet or technical obstacles for its deployment. I also want to 
discuss SSM usage specifically in the context of P2P application 
development, so i figure this would be the appropriate list.

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 16 Aug 2008 11:19:04 -0400

On Aug 16, 2008, at 11:00 AM, The 8472 wrote:

> I do not think this is suitable for the problems we are discussing  
> here (namely P2P usage) as P2P systems try to ensure fairness  
> between clients. AMT seems to do multicast manually

in the absence of native multicast routing

> by sending each multicast packet tunneled through unicast to each  
> site. SSM is only suitable for P2P if the loss of control over  
> fairness is compensated by the bandwidth amplification done by  
> sending data once and multiplying it along the path. We'd basically  
> have to do AMT manually over normal P2P-unicast links between  
> existing (if there are any... which is one of my questions)  
> multicast islands.

For info on global Internet multicast, see http://www.multicasttech.com/status/

The whole point of AMT is to make it possible to ignore whether or not  
you have multicast routing.

This could lend itself to ALTO needs as well.

Suppose that a provider such as Comcast enabled multicast internally  
(which they are likely to do for IPTV anyway). In that case, internal  
Multicasts could use native router replication, optimizing bandwidth  
inside the network, which is the most valuable bandwidth to optimize.  
The provider could also provide a AMT gateway service to get to the  
rest of the world, enabling some measure of control (based on where  
the AMT relay is) on the P2P traffic flow. It would be trivial in that  
case to assign the interdomain P2P traffic to a lower priority traffic  
class on the outgoing interface.

If the provider wanted to do this, but had to roll it out in stages  
(say, one city at a time), AMT would mean that they could use one set  
of code everywhere (with AMT usage in the places without multicast  
routing).

The incorporation of AMT into a P2P network would provide a strong  
incentive for providers to adopt native SSM multicast, which is what  
you would want for your SSM proposal.

Regards
Marshall

> don't know enough about the current progress of mcast/ssm support on  
> the internet or technical obstacles for its deployment. I also want  
> to discuss SSM usage specifically in the context of P2P application

---

From: Stanislav Shalunov <[email-masked]>
Date: Sun, 17 Aug 2008 21:18:38 -0700

[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

--
Stanislav Shalunov