Subject: mboned: Re: [AMT] AMT scalabilty for sending sites

From: "Greg Shepherd" <[email-masked]>
Date: Thu, 23 Mar 2006 18:38:06 -0800

hello,

Here's an explaination of the scaling issue I failed to describe at
the mic today. Going back to Dave's preso with my 2nd bullet of "must
have sourcing.. etc.." - the intention was to provide sourcing with
the same scaling properties of native multicast, ie single stream.

The current AMT sourcing solution requires gateways to potentially
source to an unlimited number of relays as these relays receive PIM
joins for the AMT sourced content. I believe with this solution, AMT
sourcing will never be used.

So though I'd like to see sourcing removed from the draft, I'm willing
to comprimise with MAY, MAY, MAY to the three items Dave detailed
today.

Thanks,
Greg

On 12/19/05, Jean-Jacques Pansiot <[email-masked]> wrote:
> Hello,
>
> I have  a scalability concern with AMT for isolated hosts sending SSM
> traffic.
>
> For gateways receiving traffic, the more relays you have, the better,
> since a better relay can be chosen (and packets will be tunneled only
> once  to the gateway).
>
> However for a sending gateway, it seems that it will have to duplicate
> packets towards
> all joined relays for a given channel. So the more relays you have, the
> more stress on the gateway.
> For example, with one relay per AS, the gateway sends one copy of a
> packet per AS receiving the channel.
> This could be a problem, in particular for sites with low upload bandwidth ?
> Is that right, or do I miss something ?

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Pekka Savola <[email-masked]>
Date: Fri, 24 Mar 2006 05:03:23 +0200 (EET)

> sourcing will never be used.

You have the assumption, "with the same scaling properties of native 
multicast" which is I (and probably many others) don't share.  This is 
a transition mechanism: it's fine if the solution is sub-optimal. 
After all, that's why L2TP (or other kind of) tunnels can be set up 
with those scaling properties.  Specifically, AMT should optimize for 
the most common case -- and it does: receiving reuses native multicast 
infrastructure as far as possible.

IMHO, the most important reason for AMT to support sourcing is to 
allow similar functionality on the hosts as they might have on a 
native network.  I don't think AMT hosts/gateways will even try to 
source heavy multicast streams: instead, they could very well 
participate in small-scale multicasting such as some new multicast 
peer-to-peer signalling, low-bitrate video/sound conferencing (e.g., a 
webcam), etc.

If we don't allow sourcing, we'll be limiting the AMT applicability to 
those boring applications we know today, instead of allowing room for 
innovative new apps :-).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: "Greg Shepherd" <[email-masked]>
Date: Fri, 24 Mar 2006 11:08:39 -0800

> peer-to-peer signalling, low-bitrate video/sound conferencing (e.g., a

You have the assumption, " I don't think AMT hosts/gateways will even
try to source heavy multicast streams:" which I (and probably many
others) don't share. But  you are correct that other tunnels can be
set-up for sourcing - and will rendering AMT sourcing usless while the
success of AMT receiving will continue to motivate content and native
deployment.

Greg