netdev - [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-next>] [day] [month] [year] [list]

Message-ID: <YXEoekVoLZK7ttUd@Laptop-X1>
Date:   Thu, 21 Oct 2021 16:44:42 +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: [IGMP discuss] Should we let the membership report contains 1 or
 multi-group records?

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