From: Hangbin Liu <liuhangbin@gmail.com>
To: network dev <netdev@vger.kernel.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
David Ahern <dsahern@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Li RongQing <lirongqing@baidu.com>,
Kevin Cernekee <cernekee@chromium.org>,
Taehee Yoo <ap420073@gmail.com>
Subject: [IGMP discuss] Should we let the membership report contains 1 or multi-group records?
Date: Thu, 21 Oct 2021 16:44:42 +0800 [thread overview]
Message-ID: <YXEoekVoLZK7ttUd@Laptop-X1> (raw)
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
next reply other threads:[~2021-10-21 8:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-21 8:44 Hangbin Liu [this message]
2021-10-28 9:19 ` [IGMP discuss] Should we let the membership report contains 1 or multi-group records? Hangbin Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YXEoekVoLZK7ttUd@Laptop-X1 \
--to=liuhangbin@gmail.com \
--cc=ap420073@gmail.com \
--cc=cernekee@chromium.org \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=lirongqing@baidu.com \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox