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
| ||
|
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
Powered by blists - more mailing lists