Subject: [MBONED] Fwd: [tana] Why not SSM?

From: Marshall Eubanks <[email-masked]>
Date: Mon, 18 Aug 2008 11:57:16 -0400

Again, fyi

Begin forwarded message:

> From: Stanislav Shalunov <[email-masked]>
> Date: August 18, 2008 12:18:38 AM EDT
> To: The 8472 <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [tana] Why not SSM?
>
> [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 From [email-masked]  Mon Aug 18 08:57:15 2008
From: Marshall Eubanks <[email-masked]>
To: [email-masked]
Date: Mon, 18 Aug 2008 11:57:16 -0400
Subject: [MBONED] Fwd: [tana] Why not SSM?
Sender: [email-masked]

Again, fyi

Begin forwarded message:

> From: Stanislav Shalunov <[email-masked]>
> Date: August 18, 2008 12:18:38 AM EDT
> To: The 8472 <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [tana] Why not SSM?
>
> [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 meanto 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 bandwidt 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 bandwth 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
>
> --
> Stanislav Shalunov
>
>
>
> _______________________________________________
> tana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tana

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

idth 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
>
> --
> Stanislav Shalunov
>
>
>
> _______________________________________________
> tana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tana

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 19 Aug 2008 11:08:40 +0900 (JST)

(It seems that my mail was discarded by ietf mail server (again). I
resend this mail to this ML again.)

There shouldn't be such simple answer for IP multicast vs. P2P.
It depends on various factors and conditions. Each has pros. and
cons. Neither P2P solves every problem.
So, we can just say, it depends.
Regards,
--
Hitoshi Asaeda
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 19 Aug 2008 11:08:40 +0900 (JST)

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 19 Aug 2008 11:39:47 +0200

the question is indeed much more complex than initially depicted: at
which level mcast is used overlay vs IP i.e. store&forward (caches) vs
only forward traffic, in IP mcast sources can themselves be replicates
(mcast locally where high user density are observed and unicast
remotelly) while caching efficiency depends on localisation i.e how
close to the end-user (delay x bw consumption) and are also subject to
local scaling issues, underlying traffic properties i.e. stream vs bulk,
etc. now, there are certainly open questions for IP mcast beyond
deployability (congestion control is certainly one of them) but the same
applies to P2P/caching. all these elements should be taken into account
for a finer analysis before drawing fast conclusions (if such is the
intention).

thanks,
-d.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hitoshi AFrom [email-masked]  Tue Aug 19 02:40:16 2008
Content-class: urn:content-classes:message
Date: Tue, 19 Aug 2008 11:39:47 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Hitoshi Asaeda" <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [MBONED] Fwd: [tana] Why not SSM?
Sender: [email-masked]

the question is indeed much more complex than initially depicted: at
which level mcast is used overlay vs IP i.e. store&forward (caches) vs
only forward traffic, in IP mcast sources can themselves be replicates
(mcast locally where high user density are observed and unicast
remotelly) while caching efficiency depends on localisation i.e how
close to the end-user (delay x bw consumption) and are also subject to
local scaling issues, underlying traffic properties i.e. stream vs bulk,
etc. now, there are certainly open questions for IP mcast beyond
deployability (congestion control is certainly one of them) but the same
applies to P2P/caching. all these elements should be taken into account
for a finer analysis before drawing fast conclusions (if such is the
intention).

thanks,
-d.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hitoshi Asasaeda
> Sent: Tuesday, August 19, 2008 4:09 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [MBONED] Fwd: [tana] Why not SSM?
> 

eda
> Sent: Tuesday, August 19, 2008 4:09 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [MBONED] Fwd: [tana] Why not SSM?
>