netdev - Re: [IGMP discuss] Should we let the membership report contains 1 or multi-group records?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 28 Oct 2021 17:19:46 +0800
From:   Hangbin Liu <liuhangbin@...il.com>
To:     network dev <netdev@...r.kernel.org>
Cc:     Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        David Ahern <dsahern@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Li RongQing <lirongqing@...du.com>,
        Kevin Cernekee <cernekee@...omium.org>,
        Taehee Yoo <ap420073@...il.com>
Subject: Re: [IGMP discuss] Should we let the membership report contains 1 or
 multi-group records?

Hello All,

Any comments?

Thanks
Hangbin

On Thu, Oct 21, 2021 at 04:44:42PM +0800, Hangbin Liu wrote:
> Hi IGMP experts,
> 
> One of our customers reported that when replying to a general query, the
> membership report contains multi group records. But they think each
> report should only contain 1 group record, based on
> 
> RFC 3376, 5.2. Action on Reception of a Query:
> 
>    1. If the expired timer is the interface timer (i.e., it is a pending
>       response to a General Query), then one Current-State Record is
>       sent for each multicast address for which the specified interface
>       has reception state, as described in section 3.2.  The Current-
>       State Record carries the multicast address and its associated
>       filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and source list.
>       Multiple Current-State Records are packed into individual Report
>       messages, to the extent possible.
> 
>       This naive algorithm may result in bursts of packets when a system
>       is a member of a large number of groups.  Instead of using a
>       single interface timer, implementations are recommended to spread
>       transmission of such Report messages over the interval (0, [Max
>       Resp Time]).  Note that any such implementation MUST avoid the
>       "ack-implosion" problem, i.e., MUST NOT send a Report immediately
>       on reception of a General Query.
> 
> So they think each group state record should be sent separately.
> I pointed that in the RFC, it also said
> 
> A.2  Host Suppression
> 
> ...
> 
>    4. In IGMPv3, a single membership report now bundles multiple
>       multicast group records to decrease the number of packets sent.
>       In comparison, the previous versions of IGMP required that each
>       multicast group be reported in a separate message.
> 
> So this looks like two conflicting goals.
> 
> After talking, what customer concerned about is that if there are a thousand groups,
> each has like 50 source addresses. The final reports will be a burst of
> 40 messages, with each has 25 source addresses. The router needs to handle these
> records in a few microseconds, which will take a very high resource for router
> to process.
> 
> If each report only has 1 group record. The 1000 reports could be sent
> separately in max response time, say 10s, with each report in 10ms. This will
> make router much easier to handle the groups' records.
> 
> So what do you think? Do you think if there is a need to implement a way/option
> to make group records send separately? Do anyone know if it's a press to let
> router handle a thousand groups with each having 25 sources address in a few
> microseconds?
> 
> Thanks
> Hangbin