Subject: [MBONED] improvement suggestion on multicast

From: "GUO, Feng" <[email-masked]>
Date: Mon, 11 Jun 2007 10:02:19 +0800

Dear All,

   In most IPTV multicast deployments nowadays, all of the TV channels are
pushed to edge routers by configuring "igmp static join" command in edge
routers,i.e. all of (s,g)'s have the same forwarding tree. This will reduce
the delay in channel switching. A router, however, maintains separate
protocol-status and provides separate protocol-packets content for each
channel. This prolongs the route convergence, increases the status-space and
reduces the exchange rate of protocol-packets.

I got an idea to improve performance in those scenarios, please tell me your
comments about that? Thanks.

   It is to introduce (S,G/Mask) or (S/Mask,G/Mask) state in multicast
protocols in that deployment circumstances, i.e. the MFIB and protocol state
machine are (S,G/Mask) based instead of (S,G) based; and the same
modification for protocol packets, i.e. (S,G/Mask) JP instead of (S,G) JP,
which luckily PIM packets have the mask fields.

   This would be a simple and practical modification for multicast protocols
and implementation, and could improve the performance of IPTV services very
much. 

   Another useful situation is in the core network, even the IPTV channels
are not pushed to last hop routers, and they would be pushed to the converge
routers of core networks in many cases. It would be also good to introduce
the idea to core network deployments. 

   Eagerly hearing from you.

Sincerely yours,

Guo Feng

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

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 10 Jun 2007 20:31:09 -0700

> comments about that? Thanks.

This could become an endless disucssion ;-)) ... and seeing that what
you propose is really orthogonal to "statically administered trees",
let me just summarize that i agree many customers (not only IPTV) do this and
want to do this, and that we as a vendor also continue to support and
improve such functionality in our products (redundancy, ranges, yada yada
yada).

Personally i think that such 'static' router based setup of IP multicast
trees should be outside the scope of IETF work because IP multicast is
really about trees dynamically joined and built by host applications.

Static / router built trees can also easily be interpreted as just a router
based "application" joining to a tree (and discarding data), so no new
extension to IETF protocol suite required. 

I also think such provisioning is completely opposite to where i personally
would like IPTV services go to: Pull model == IP multicast == i as the
subscriber can dynamically request IP multicast TV content like i do request
web (unicast) content. I also think that network operators will become
less and less happy with "solution operators" (who run IPTV) to request
more and more per-stream provisioning commands in the network. And if
you add masks it may reduce the number of commands but will make
address administration more complex. 

> which luckily PIM packets have the mask fields.

You should watch Groundhog Day, young grasshopper ;-))
(aka: we have been there, and you should feel happy to not have been there!)

Check out the addressing format in the PIM spec. It does already contain
mask lengths for the address fields. I also think that if you try some
IOS 10.2 image from 1994, you may still find some code in it trying
to automatically create mask-length of < /32 for IPv4 based on received
joins for adjacent groups. That idea was quickly given up due to the
complexity and unlikelyness to be useful. The encoding was never removed
from the PIM spec though, there's just no explanation whatsoever how the poor
protocol state machinery should look like to support masks other than /32.
That is left as an exercise to young grasshoppers ;-))

Seriously: We've repeatedly thought that it might be useful to revive
this idea, but if you ask me:

 a) The state machinery is too ugly for PIM-SM -  (*,G) and (S,G)
    interactions with masks *yuck*. If at all, it should only be
    considered for PIM-SSM.

 b) Should only be done in conjunction with IGMP range-join extensions,
    or else it could not be supported in the real IP multicast model
    (driven by applications).

Still not on the top of the list of my priorities as far as what i 
consider to be most crucial for IPTV and other multicast solutions though.
   
> and implementation, and could improve the performance of IPTV services very

Only for such limited applications that are very little dynamic but
working around fixed ranges of groups. I quite frankly don't think that
the bundle-size of subscription options validates such hop-by-hop
extensions to PIM.

The resiliency customers want are better achieved with other means
(fast reroute, live-live, etc..), and the speed of tree building
in optimized implementations is already not an argument of concern
(up to multiple thousand trees / sec depending on router). Yet there 
may be in the future other applications beside IPTV for which it might
be more applicable.

> the idea to core network deployments. 

Consider that customers who would like to engineer every tree in their
network typically would like to use some form of VPN environment around their
core, and with multicast L3VPN (MVPN) solutions, whether they are using
RSVP-TE P2MP, mLDP or GRE based trees in the core, such aggregation can easily
be implemented as part of the MVPN functionality on PEs, such as for example
already Data-MDTs support it (there are extensions possible and requested
by customers though for such Data-MDTs/S-PMSI).

So, "core" based aggregation is no good reason to make the hop-by-hop protocol
(PIM) more complex, but rather a reason to consider it in PE functionality.

Overall, this hop-by-hop -hop aggregation signaling handling is more a nice
recurring discusion for a sake or beer, but less something that IMHO
would justify cycles in the IETF in the near future. Nevertheless,
if we should ever do IGMPv4, i am all for adding the option to do so there
! ;-))

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 10 Jun 2007 20:31:09 -0700

Cheers
    Toerless

---

From: "GUO, Feng" <[email-masked]>
Date: Mon, 18 Jun 2007 18:21:14 +0800

Thanks for your comments and sorry for replying late since I was on a
business travel. Please find the 5 pieces of reply below starting with
"*****GUO FENG*****"

Maybe I a few words on this idea could not make it very clear, I am close to
finishing a draft on this, maybe it would make discussion easier based on
that spec.

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: Monday, June 11, 2007 11:31
To: GUO, Feng
Cc: [email-masked]; [email-masked]
Subject: Re: [MBONED] improvement suggestion on multicast

let me just summarize that i agree many customers (not only IPTV) do this
and

******GUO FENG 1/5*****: 
By the improvement, trees are still built dynamically and could cope with
the topology dynamic changes. But the leaves are statically configured,
because: 
1. Under unicast scenario, the request sending by end-users has no impact on
control plane of routers, whereas it is a big problem for multicast pull
model that control plane of routers is impact substantially by end-users.
And this would be even worse for core routers. In IPTV deployment when
audiences do zapping or switch all of the channels in a very short time,
this could introduce flapping of multicast TIB. Not even mention about
network attacks. But if leaves are statically configured on edges routers,
this defect could be eliminated.

2. Since there are usually thousands of active end-users under each BRAS
equipment, from the statistic point of view, even by using pull model most
of edge routers would have all of the groups joined(at least in IPTV
deployment scenarios). So both models would have the same groups joined, but
the improvement I suggested would make the control plane of routers much
more stable.
    For core routers, this benefit would be even more obvious since there
are much more multicast end-users below them sending join.

from the PIM spec though, there's just no explanation whatsoever how the
poor

***** GUO FENG 2/5******
Automatically aggregation is not needed, aggregation triggered by statically
configuring a group set joining is enough for most of the deployment. And by
putting less intelligence to the protocol, the improvement would be easily
to implement.

   
******GUO FENG 3/5****
The improvement introduces a stable control plane, I do think this is very
important and deserves higher attention for expanding multicast deployment
besides other benefits of aggregation.

**** GUO FENG 4/5****
I do not think the application of this aggregation is limited, because as I
mentioned from the statistical point of view, once there are thousands of
active end-users below each routers, they would join bundle-size of
multicast programs in total.

***** GUO FENG 5/5****
I don't think this is a competitive solution with fast reroute etc., they
might be used in combination. And for performance, the improvement makes it
easier to achieve today's benchmark or higher for the same number of groups.

Consider that customers who would like to engineer every tree in their
network typically would like to use some form of VPN environment around
their
core, and with multicast L3VPN (MVPN) solutions, whether they are using
RSVP-TE P2MP, mLDP or GRE based trees in the core, such aggregation can
easily
be implemented as part of the MVPN functionality on PEs, such as for example
already Data-MDTs support it (there are extensions possible and requested
by customers though for such Data-MDTs/S-PMSI).

So, "core" based aggregation is no good reason to make the hop-by-hop
protocol
(PIM) more complex, but rather a reason to consider it in PE functionality.

Cheers
    Toerless

---

From: "GUO, Feng" <[email-masked]>
Date: Mon, 18 Jun 2007 18:21:14 +0800

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: Monday, June 11, 2007 11:31
To: GUO, Feng
Cc: [email-masked]; [email-masked]
Subject: Re: [MBONED] improvement suggestion on multicast

******GUO FENG 1/5*****: 

***** GUO FENG 2/5******

   
******GUO FENG 3/5****

**** GUO FENG 4/5****

***** GUO FENG 5/5****

Cheers
    Toerless