I have some IPTV questions regarding fast leave and QoS:
1. Channel Changes / Increased Bandwidth
How are channel changes handled with the ePMP system? A typical IGMP snooping system (fast leave turned off) will hang on to a stream for several seconds, so when changing channels a 2 Mbps stream can quickly turn into 5 or 6 streams overloading a link until they stop. Is this resolved with fast leave?
2. Multiple Streams on One SM
If a customer has multiple IPTV connections, and both are watching the same channel, will fast leave shut down the 2nd connection when the first one changes channels... or will it recognize there were two IGMP requests for the same stream behind a single SM?
3. MIR
When will there be an option to apply the MIR to only one VLAN? For example, the MIR could be applied to the Internet service VLAN, but could leave the VoIP and IPTV VLANS unlimited? The AP would still prioritize Voice and Video traffic as necessary when the overall limits are hit, but then IPTV and Voice would not take slices of a customer's rated Internet service.
Fast leave with break all streams to the AP that are tuned to the same channel until they establish again. Fast leave for the iptv provider situation, bad.
Essential when the AP gets the leave message, it kills that group regardless if others are still a member.
With a good switch, you can stop the channel hang behavior. We see the group hang for a few seconds essentially stacking the channels for 6 to 10 seconds with cheaper switches. Our junipers track the grouping and will end a streat like you’d get from fast leave unless another device is in the group, then the group lives.
Switches like netonix (igmp is busted in them) and the few Netgears I’ve fiddled with don’t stop the streams quickly. That said $200 switch vs. $1500 switch.
I agree that fast leave in general is bad, but the ePMP implemenation appears to be intended for use with IPTV. The GUI help description says:
"IGMPv2 Fast Leave Support: When enabled, the AP will drop IGMPv2 Leave packets coming from subscribers if there are still other SMs subscribered (sic) to this group downstream."
It seems like it is intended to be used with a fast leave capable switch. It would be just right if it also tracked multiple requests from the same SM. I suppose I'll have to test it.
I've only just started using Juniper hardware, but not yet for multicast. I'll have to get a spare and see about testing on the bench.