IGMP Unsolicited Report Interval too long for IGMPv3?

IGMP Unsolicited Report Interval too long for IGMPv3?

[William Manley]

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.

There was a thread about this on linux-rdma in 2010 in the context of IP 
over Infiniband but it seems no patches got applied as a result of the 
discussion:

http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg05740.html

Would the right patch reducing the unsolicited report interval for 
IGMPv3 be acceptable now?

Thanks

Will

Re: IGMP Unsolicited Report Interval too long for IGMPv3?

[David Miller]

Please use netdev@vger.kernel.org for networking issues.

Thank you.

IGMP Unsolicited Report Interval too long for IGMPv3?

[William Manley]

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.

There was a thread about this on linux-rdma in 2010 in the context of IP 
over Infiniband but it seems no patches got applied as a result of the 
discussion:

http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg05740.html

Would the right patch reducing the unsolicited report interval for 
IGMPv3 be acceptable now?

Thanks

Will

Re: IGMP Unsolicited Report Interval too long for IGMPv3?

[Ben Hutchings]

On Mon, 2013-07-22 at 21:43 +0100, William Manley wrote:
> 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.
> 
> There was a thread about this on linux-rdma in 2010 in the context of IP 
> over Infiniband but it seems no patches got applied as a result of the 
> discussion:
> 
> http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg05740.html
> 
> Would the right patch reducing the unsolicited report interval for 
> IGMPv3 be acceptable now?

I suggest you post a patch and find out what people think of it.  That
usually gets more response than asking in the abstract.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: IGMP Unsolicited Report Interval too long for IGMPv3?

[Benjamin LaHaise]

On Mon, Jul 22, 2013 at 09:43:57PM +0100, William Manley wrote:
> 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.

		-ben

> There was a thread about this on linux-rdma in 2010 in the context of IP 
> over Infiniband but it seems no patches got applied as a result of the 
> discussion:
> 
> http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg05740.html
> 
> Would the right patch reducing the unsolicited report interval for 
> IGMPv3 be acceptable now?
> 
> Thanks
> 
> Will
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: IGMP Unsolicited Report Interval too long for IGMPv3?

[Hannes Frederic Sowa]

On Mon, Jul 22, 2013 at 05:18:55PM -0400, Benjamin LaHaise wrote:
> On Mon, Jul 22, 2013 at 09:43:57PM +0100, William Manley wrote:
> > 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 <william.manley@youview.com>
Suggested-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
 net/ipv6/mcast.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 99cd65c..db25b8e 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -44,6 +44,7 @@
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
 #include <linux/slab.h>
+#include <linux/pkt_sched.h>
 #include <net/mld.h>
 
 #include <linux/netfilter.h>
@@ -1376,6 +1377,7 @@ static struct sk_buff *mld_newpack(struct inet6_dev *idev, int size)
 	if (!skb)
 		return NULL;
 
+	skb->priority = TC_PRIO_CONTROL;
 	skb_reserve(skb, hlen);
 
 	if (__ipv6_get_lladdr(idev, &addr_buf, IFA_F_TENTATIVE)) {
@@ -1769,7 +1771,7 @@ static void igmp6_send(struct in6_addr *addr, struct net_device *dev, int type)
 		rcu_read_unlock();
 		return;
 	}
-
+	skb->priority = TC_PRIO_CONTROL;
 	skb_reserve(skb, hlen);
 
 	if (ipv6_get_lladdr(dev, &addr_buf, IFA_F_TENTATIVE)) {
-- 
1.8.3.1

Re: IGMP Unsolicited Report Interval too long for IGMPv3?

[David Miller]

From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Mon, 22 Jul 2013 23:51:08 +0200

> On Mon, Jul 22, 2013 at 05:18:55PM -0400, Benjamin LaHaise wrote:
>> On Mon, Jul 22, 2013 at 09:43:57PM +0100, William Manley wrote:
>> > 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 <william.manley@youview.com>
> Suggested-by: Benjamin LaHaise <bcrl@kvack.org>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>

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

Thanks.

Re: IGMP Unsolicited Report Interval too long for IGMPv3?

[Benjamin LaHaise]

On Thu, Jul 25, 2013 at 04:42:53PM -0700, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Mon, 22 Jul 2013 23:51:08 +0200
> 
> > On Mon, Jul 22, 2013 at 05:18:55PM -0400, Benjamin LaHaise wrote:
> >> On Mon, Jul 22, 2013 at 09:43:57PM +0100, William Manley wrote:
> >> > 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 <william.manley@youview.com>
> > Suggested-by: Benjamin LaHaise <bcrl@kvack.org>
> > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> 
> 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."

Re: IGMP Unsolicited Report Interval too long for IGMPv3?

[Hannes Frederic Sowa]

On Fri, Jul 26, 2013 at 09:11:23AM -0400, Benjamin LaHaise wrote:
> On Thu, Jul 25, 2013 at 04:42:53PM -0700, David Miller wrote:
> > From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > Date: Mon, 22 Jul 2013 23:51:08 +0200
> > 
> > > On Mon, Jul 22, 2013 at 05:18:55PM -0400, Benjamin LaHaise wrote:
> > >> On Mon, Jul 22, 2013 at 09:43:57PM +0100, William Manley wrote:
> > >> > 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 <william.manley@youview.com>
> > > Suggested-by: Benjamin LaHaise <bcrl@kvack.org>
> > > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > 
> > 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>

I just send a new patch with the priority changes for ipv4 included. I copied
your Acked-by, I hope this is ok.

Thanks,

  Hannes

Re: IGMP Unsolicited Report Interval too long for IGMPv3?

[Benjamin LaHaise]

On Fri, Jul 26, 2013 at 05:06:51PM +0200, Hannes Frederic Sowa wrote:
> On Fri, Jul 26, 2013 at 09:11:23AM -0400, Benjamin LaHaise wrote:
> > I think Hannes' patch is good step in the right direction, so please add:
> > Acked-by: Benjamin LaHaise <bcrl@kvack.org>
> 
> I just send a new patch with the priority changes for ipv4 included. I copied
> your Acked-by, I hope this is ok.

Sure, no problem.  Thanks for fixing this.

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

RE: IGMP Unsolicited Report Interval too long for IGMPv3?

[Lukas Tribus]

> Date: Mon, 22 Jul 2013 17:18:55 -0400
>> 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.

Packet loss will always result in a delay and I think William is well aware
of that.

off-topic: 1 second is not a problem in IPTV, 10 seconds are ([1]).



> 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.

While this certainly makes sense, congestion is not the only reason for
packet loss. There is no way to fix packet loss in lower network layers,
like ADSL, satellite links or IPoAC.

Improving retransmission by making it more predictable, bringing it closer
to RFC proposals and real life problems makes a lot of sense, imho. This
includes setting TC_PRIO_CONTROL, but I'm not sure it will fix Williams use
case.


lukas

[1] http://en.wikipedia.org/wiki/Zap_time 		 	   		  

Re: IGMP Unsolicited Report Interval too long for IGMPv3?

[Hannes Frederic Sowa]

On Tue, Jul 23, 2013 at 12:06:31AM +0200, Lukas Tribus wrote:
> > Date: Mon, 22 Jul 2013 17:18:55 -0400
> >> 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.
> 
> Packet loss will always result in a delay and I think William is well aware
> of that.
> 
> off-topic: 1 second is not a problem in IPTV, 10 seconds are ([1]).
> 
> 
> 
> > 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.
> 
> While this certainly makes sense, congestion is not the only reason for
> packet loss. There is no way to fix packet loss in lower network layers,
> like ADSL, satellite links or IPoAC.
> 
> Improving retransmission by making it more predictable, bringing it closer
> to RFC proposals and real life problems makes a lot of sense, imho. This
> includes setting TC_PRIO_CONTROL, but I'm not sure it will fix Williams use
> case.

Yes, it was merely meant as an RFC without the appropriate changes for IPv4
(I somehow missed this in the patch marker :| ).

Regarding the value of the IGMP unsolicited report interval, I would strictly
stick to the RFCs. So a change for IGMPv3 would be appropriate IMHO.

I would also suggest that posting patches would be favourable. I don't think
it should be too much work.

Thanks,

  Hannes