Article Index:
Why Does IPTV Use IGMP Multicasting?
Like other IPTV services, Telus Optik TV uses IGMP multicasting to efficiently deliver TV program data, or streams, to your TV. I won’t get into all the technical details here (and I’m over-simplifying things a bit too) but one of the main reasons for using IGMP multicasting is to save bandwidth. For example, if two TVs at the same home are watching the same stream, Telus only has to send the stream once. When the stream arrives at your router, the router then makes a “copy” of the stream and sends it to both TVs using IGMP multicasting.
In practice, I have observed that some (or maybe all?) of these IGMP multicast packets seem to be sent not only to each TV but also every networked device on your home network. This is okay if each device is on your wired LAN because there is lots of bandwidth available there, especially if those devices have gigabit network interfaces. However, it can cause problems on a WLAN, especially for wireless-G devices. Let me explain how I discovered this.
Adding a Second Wireless Access Point to the Telus Optik Network
As I said above, the Actiontec V1000H modem router has a built-in wireless-N wifi access point. For the most part, it does a great job of serving up wireless connections to most parts of my home, especially for wireless-N clients. However, the other day I was using my old wireless-G netbook in a far away corner of my home. Here’s a signal strength graph taken with Wifi Analyzer on my Android phone:
Wifi Signal - One Access Point
The V1000H is located on the west side of my home and the above measurement was taken on the east side, in a corner. That signal strength is good enough for my wife’s wireless-N notebook but it isn’t always good enough for my wireless-G netbook, which is experiencing some slowness and occasional dropouts on wireless connections to that access point. Thankfully, I had an extra wireless router lying around, which I hooked up the other day on the east side of my home to provide stronger signals to wireless clients on that side of my home. Specifically, that router is the Netgear WNR3500L, running the excellent third party firmware DD-WRT, version v24-sp2 (08/07/10) mega – build 14896. Here’s the signal strength graph with two access points:
Wifi Signal - Two Access Points
The red line represents the signal strength of the new router in the east part of my home. As you can see, the signal is much stronger, which provides a fast connection to my wireless-G netbook when it is in the east side of my home.
As an aside, you may be wondering why I didn’t use WDS mode and put both routers on the same SSID. First of all, WDS is not always compatible between different models of routers and since the V1000H is essentially a black box, I don’t think there is any way to get it to work in WDS mode with another model of router. Furthermore, WDS mode can cut your WLAN performance in half. Therefore, I decided to go with two separate access points using two different SSIDs.
Notice, however, that I put each access point on a separate non-overlapping channel to prevent interference between them. In North America, there are only 3 non-overlapping channels: 1, 6 and 11. If you are going to use multiple access points in your home, make sure you use only these channels and don’t use the same channel twice. In the two access point graph above, I used channels 6 and 11 and you can see that the trailing “tails” of each line do not overlap.
WLAN Performance Problems Due to IGMP Multicast Flooding
At first, my wireless-G netbook experienced great performance on the new WLAN. Here are some ping times between the netbook and the second access point:
Reply from 192.168.1.7: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7: bytes=32 time<1ms TTL=64
Reply from 192.168.1.7: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7: bytes=32 time=1ms TTL=64Ping statistics for 192.168.1.7:
Packets: Sent = 73, Received = 73, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 46ms, Average = 1ms
Wow! 1 ms average ping time and no lost packets! Great! Then I turned on the TV and got terrible wireless performance on my netbook. Here are the ping times on the netbook while watching IPTV:
Reply from 192.168.1.7: bytes=32 time=964ms TTL=64
Reply from 192.168.1.7: bytes=32 time=1833ms TTL=64
Reply from 192.168.1.7: bytes=32 time=59ms TTL=64
Reply from 192.168.1.7: bytes=32 time=1735ms TTL=64
Request timed out.
Request timed out.
Reply from 192.168.1.7: bytes=32 time=1560ms TTL=64
Request timed out.
Reply from 192.168.1.7: bytes=32 time=1950ms TTL=64
Request timed out.
Reply from 192.168.1.7: bytes=32 time=1583ms TTL=64
Request timed out.
Reply from 192.168.1.7: bytes=32 time=1670ms TTL=64
Reply from 192.168.1.7: bytes=32 time=1774ms TTL=64
Reply from 192.168.1.7: bytes=32 time=58ms TTL=64
Reply from 192.168.1.7: bytes=32 time=1634ms TTL=64
Reply from 192.168.1.7: bytes=32 time=2066ms TTL=64
Reply from 192.168.1.7: bytes=32 time=58ms TTL=64
Reply from 192.168.1.7: bytes=32 time=910ms TTL=64
As you can see, the ping times are very high and there is substantial packet loss! What can account for this? The answer is IGMP multicast flooding. The V1000H was sending a whole bunch of IGMP multicast packets to the WNR3500L, which in turn was sending those packets out its wireless interface to all connected wireless clients. The result was complete saturation of the capacity of the wireless interface, despite the strong wifi signal. No wonder the ping results sucked!
Now you may be wondering whether wireless clients connected to the V1000H also suffer from IGMP multicast flooding. I haven’t investigated this yet but I suspect the answer is “no” because my ping times seem fine when connected wirelessly to the V1000H while watching IPTV. I’m not sure how the V1000H prevents this flooding (or if it does at all) but it does warrant further investigation and a future story on NerdBoys.com.
Anyway, the task at hand was to prevent IGMP multicast flooding on the new WLAN I created with the WNR3500L. Flip to the next page to find out how I did it.
Article Index:
Thanks for taking some of the mystery out of Telus Optik TV.