On Thu, Jul 25, 2013 at 04:42:53PM -0700, David Miller wrote:

From: Hannes Frederic Sowa <redacted>
Date: Mon, 22 Jul 2013 23:51:08 +0200

quoted

On Mon, Jul 22, 2013 at 05:18:55PM -0400, Benjamin LaHaise wrote:

quoted

On Mon, Jul 22, 2013 at 09:43:57PM +0100, William Manley wrote:

quoted

If an IGMP join packet is lost you will not receive data sent to the 
multicast group so if no data arrives from that multicast group in a 
period of time after the IGMP join a second IGMP join will be sent.  The 
delay between joins is the "IGMP Unsolicited Report Interval".

In the kernel this seems to be hard coded to be chosen randomly between 
0-10s.  In our use-case (IPTV) this is too long as it can cause channel 
change to be slow in the presence of packet loss.

I would guess that this 10s has come from IGMPv2 RFC2236, which was 
reduced to 1s in IGMPv3 RFC3376.

Reducing the timeout does not solve the problem you are encountering, as 
any packet loss will still result in a 1 second delay.  I've encountered 
similar issues dealing with LCP Echo request/replies for keepalive 
messages on PPP sessions.  The correct approach is to queue the IGMP 
multicast join with a higher priority than other traffic in the system 
so that the requests are not lost due to congestion of a single queue.  
Sending packets with an 802.1p header might be appropriate in your 
use-case, or perhaps using higher priority internal queues.

Yes, we can do a little bit better. What do you think?

[PATCH net-next] ipv6: send igmpv3/mld packets with TC_PRIO_CONTROL

Reported-by: William Manley <redacted>
Suggested-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Hannes Frederic Sowa <redacted>

Ben, please give Hannes the feedback he is asking for.

Thanks.

I think Hannes' patch is good step in the right direction, so please add:
Acked-by: Benjamin LaHaise <bcrl@kvack.org>

		-ben
-- 
"Thought is the essence of where you are now."