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

From: Marshall Eubanks <[email-masked]>
Date: Sat, 16 Aug 2008 12:15:39 -0400

Note that this is a cross post, and the total thread is on the TANA  
list.

Regards
Marshall

Begin forwarded message:

> From: Marshall Eubanks <[email-masked]>
> Date: August 16, 2008 11:19:04 AM EDT
> To: The 8472 <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [tana] Why not SSM?
>
>
> On Aug 16, 2008, at 11:00 AM, The 8472 wrote:
>
>> Marshall Eubanks wrote:
>>> There is a protocol called AMT intended to deal with this issue. See
>>>
>>> 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
>
> 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 nFrom [email-masked]  Sat Aug 16 09:15:39 2008
From: Marshall Eubanks <[email-masked]>
To: [email-masked]
Date: Sat, 16 Aug 2008 12:15:39 -0400
Subject: [MBONED] Fwd: [tana] Why not SSM?
Sender: [email-masked]

Note that this is a cross post, and the total thread is on the TANA  
list.

Regards
Marshall

Begin forwarded message:

> From: Marshall Eubanks <[email-masked]>
> Date: August 16, 2008 11:19:04 AM EDT
> To: The 8472 <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [tana] Why not SSM?
>
>
> On Aug 16, 2008, at 11:00 AM, The 8472 wrote:
>
>> Marshall Eubanks wrote:
>>> There is a protocol called AMT intended to deal with this issue. See
>>>
>>> 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
>
> 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 natative 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
>
>>
>>
>>> 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.
>>
>> -- 
>> The 8472
>> independent developer for the Azureus Vuze Bittorrent client
>
> _______________________________________________
> tana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tana

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

ive 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
>
>>
>>
>>> 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.
>>
>> -- 
>> The 8472
>> independent developer for the Azureus Vuze Bittorrent client
>
> _______________________________________________
> tana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tana

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