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

[Marshall Eubanks <[e-mail]>]

Again, fyi

Begin forwarded message:

> From: Stanislav Shalunov <[e-mail]>
> Date: August 18, 2008 12:18:38 AM EDT
> To: The 8472 <[e-mail]>
> Cc: [e-mail]
> 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 [e-mail]  Mon Aug 18 08:57:15 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 0E6003A685F;
	Mon, 18 Aug 2008 08:57:15 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 8449D28C18F
	for <[e-mail]>; Mon, 18 Aug 2008 08:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.013
X-Spam-Level: 
X-Spam-Status: No, score=-102.013 tagged_above=-999 required=5
	tests=[AWL=-1.329, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1,
	SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id pOd+HYW9rWjb for <[e-mail]>;
	Mon, 18 Aug 2008 08:57:13 -0700 (PDT)
Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7])
	by core3.amsl.com (Postfix) with ESMTP id 05E043A659B
	for <[e-mail]>; Mon, 18 Aug 2008 08:57:12 -0700 (PDT)
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP-TLS id 12549288 for [e-mail];
	Mon, 18 Aug 2008 11:57:19 -0400
Message-Id: <[e-mail]>
From: Marshall Eubanks <[e-mail]>
To: [e-mail]
Mime-Version: 1.0 (Apple Message framework v926)
Date: Mon, 18 Aug 2008 11:57:16 -0400
References: <[e-mail]>
X-Mailer: Apple Mail (2.926)
Subject: [MBONED] Fwd: [tana] Why not SSM?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mboned>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mboned>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>,
	<mailto:[e-mail]?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: [e-mail]
Errors-To: [e-mail]

Again, fyi

Begin forwarded message:

> From: Stanislav Shalunov <[e-mail]>
> Date: August 18, 2008 12:18:38 AM EDT
> To: The 8472 <[e-mail]>
> Cc: [e-mail]
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tana
>
> --
> Stanislav Shalunov
>
>
>
> _______________________________________________
> tana mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tana

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

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