Reduce Multicast channel changing time in triple-play network

[lap]

Hi all,

I have a customer which has a tripe play network. I attach the  following drawing so you can have a better idea how the network looks  like.

The access layer is composed of cisco WS-C4510R-E and connect almost 300 customers each to the triplay-play network. Each customer has a set-up box with give access to Internet, IP telephony and IPTV through multicast. The customer is running IGMP v2 and wants to reduce channel zapping time.

I have heard that it is possible and easier when running IGMPv3. But can it be possible to reduce zapping time with IGMPv2. Maybe by configuring IGMP immediate leave on the Cisco 4500?

Any ideas, suggestions, advices are really welcome.

Thanks in advance.

Regards,

Laurent

[Peter Paluch]

Hello Laurent,

Personally, I believe that the difference between IGMPv2 and IGMPv3 is not significant for this issue - actually, I do not know of any sound technical reason why the IGMPv3 should be faster at all. Perhaps if the source is known, the IGMPv3 may help to immediately build the source-based tree (with the PIM support, of course), but if the multicast source is not known then I am not aware of any other reason why the IGMPv3 should provide shorter zapping times. If anybody knows better please enlighten us!

As far as my knowledge goes, the major part of the zapping time is actually caused by the codec used to encode the video stream. One issue is the buffering - depending on the codec and player implementation, it may try to buffer up to several seconds of videodata before starting the playout. Another issue is even more technical: MPEG codecs, for example, send the videostream as a series of so-called frames of various types. Some of these frames contain the entire picture (the I-frames). Other frames contain only differences (deltas) from the previous and sometimes even following frames (the P-frames and B-frames). P-frames and B-frames themselves do not contain the entire picture information. An MPEG stream thus consists of I-frames sent at certain intervals, with a set of P-frames and B-frames inserted between two consecutive I-frames. The videostream can be, obviously, correctly displayed only after receiving an I-frame. The codec therefore first needs to wait until an I-frame arrives to provide a referential basis for the following P- and B-frames. As the I-frames may be sent relatively infrequently (hundreds of milliseconds or even units of seconds), waiting for the I-frames constitutes an important part of the overall zapping time.

The solution of this issue is probably outside of pure networker's competence - the IGMP or PIM are not at the fault here. After all, you could make a simple measurement at your customer - try sniffing the videostream at the STB, change channels and watch the time between the IGMP Join message and the arrival of the first videopacket to this group. This should take at most tens of milliseconds. The remaining time will be caused by the buffering and waiting for the codec to get in sync as I've described earlier.

I have heard of a Microsoft technology (I am sorry but I do not remember its name) that tried to reduce the zapping time by generating the I-frame for you on demand whenever you changed a channel, so that your codec would sync faster. It is possible that there are more vendors with the same technology. In any case, this would necessitate purchasing a specialized solution for IPTV.

Best regards,

Peter

[lap]

Hi Peter,

Thank you very much for your post. That was really well explained.

The part with I-frames and P/B-frames was really interesting. As you said there are different kind of things which can affect zapping time (Took from Cisco DOC):

• IGMP signaling delay - The IGMP leave and join messages sent by the STB. IGMP signaling is a very minor component of  channel change delay

• MPEG decoding delay

• I-frame acquisition delay

• Conditional-access-system (CAS) key acquisition delay

But could it still be possible to do something on the IGMP part even if it's no a lot?

I was thinking of configuring IGMP immediate leave on the 4510 but the problem is when one customer is zapping the switch will stop sending immediately multicast stream to the customer ans if someone else was watching the same channel on another TV at the customer place that will be a problem because it will loose the stream also.

So do you know any other method where we could reduce IGMP signaling delay? (At access layer or distribution layer)

Regards,

Laurent

[Peter Paluch]

Hi Laurent,

But could it still be possible to do something on the IGMP part even if it's no a lot?

The IGMP communication is solely between the client (the STB) and its IP gateway. There is really not much to improve here. As soon as the IP gateway learns about the wished group of the client, it will rely on the PIM protocol to build the multicast distribution tree and allow the traffic to flow to the client. The PIM protocol itself is also quick-acting and there are actually no timers to tune in PIM that could improve the zapping time.

As I suggested, it would be very helpful to actually perform measurements at the STB using a plain switch as a tap and a PC/notebook with Wireshark: change a channel (i.e. subscribe to a different group) and watch for the first packet being delivered to the new group, then measure the time between the IGMP Join message and the first multicast packet delivered there. As I indicated, the time shall be in order of tens of milliseconds, and it encompasses the entire IGMP+PIM signalling. I think that saving a few tens of milliseconds will not even be noticeable. I really recommend performing this measurement to see if the effort to improve the network response time itself is feasible at all.

I was thinking of configuring IGMP immediate leave on the 4510 but the 
problem is when one customer is zapping the switch will stop sending 
immediately multicast stream to the customer ans if someone else was 
watching the same channel on another TV at the customer place that will 
be a problem because it will loose the stream also.

That is correct. The IGMP Immediate Leave is suitable only for situations when there is a single host connected to a port. For multiple hosts subscribed to the same group, the Leave messages will cause interruptions in the multicast stream delivery. Furthermore, the Immediate Leave would be helpful only if there were bandwidth issues - an oversubscribed link because of many multicast streams flowing through it. However, whether this is also a cause of your problem is currently unknown and must only be confirmed by performing measurements.

Are you using IGMP Snooping on the access switches? Also, where is the routing performed - on the distro layer, or also at the access layer? In other words, where does the IGMP end and PIM start?

Best regards,

Peter

[lap]

Hi Peter,

Really nice explanation again!

I will do the test that you are advicing next week at our customer. I will let you know.

Are you using IGMP Snooping on the access switches? Also, where is the  routing performed - on the distro layer, or also at the access layer? In  other words, where does the IGMP end and PIM start?

Yes we are using IGMP snooping on the 4510 (access switch). The routing is performed on the distribution switch ( 7606 - PE on the drawing). So the access switches are only layer 2 devices doing IGMP snooping.

Regards,

Laurent

[Peter Paluch]

Hello Laurent,

I am glad to be of help to you.

Regarding the IGMP Snooping, it can actually be combined with the IGMP Immediate Leave processing. The reason is that the switch performing IGMP Snooping decides on a per-port basis whether a multicast stream shall be flooded through a particular switchport, without influencing other switchports. That means that instead of performing the Immediate Leave on the IP-network-wide basis (if configured on a Layer3 interface), with IGMP Snooping, the Immediate Leave may be activated on per-switchport basis, without having ill effects on other subscribers in the same IP network. If your network is connected strictly in such a manner that a single customer is connected to a single port on the 4506 and no two or more customers share the same switchport, you may allow the access switch (but only the access switch!) to perform Immediate Leave as a part of the IGMP Snooping using the global configuration level command

ip igmp snooping vlan N immediate-leave

Replace the N with the VLAN where the customer is located.

I am really interested in seeing the measurement results. Please keep me posted!

Best regards,

Peter

[lap]

Hi Peter,

That is true, only one customer is connected to a switchport on the 4510. But sometimes a customer can have 2 TVs at home and therefore 2 STB. I think in this case the immediate-leave feature will cause problems if the 2 TV are receiving the same multicast group and one of them is changing channel, no?

Regards,

Laurent

[Peter Paluch]

Hello Laurent,

But sometimes a customer can have 2 TVs at home and therefore 2 STB. I 
think in this case the immediate-leave feature will cause problems if 
the 2 TV are receiving the same multicast group and one of them is 
changing channel, no?

Yes, that is correct. There would be interruptions in the service. This setup - having 2 TV sets and therefore 2 STBs connected to a single access switch port - violates the assumption for proper function of the Immediate Leave - that there may be one and only one multicast-enabled host connected to the port controlled by the Immediate Leave.

Best regards,

Peter