Hi!
I suspect that the MLDv1 Host compatibility mode is ended prematurely.
In net/ipv6/mcast.c the "Older Version Querier Present" timeout is
computed as
max_delay = (ntohs(mld->mld_maxdelay)*HZ)/1000;
switchback = (idev->mc_qrv + 1) * max_delay;
idev->mc_v1_seen = jiffies + switchback;
RFC 3810 says that the timeout should be computed as
Robustness_Variable * Query_Interval + Query_Response_Interval. This
suggests that the line where switchback is computed should be changed
to something like
switchback = (idev->mc_qrv * 125 * HZ) + max_delay;
where 125 is the default Query_Interval in seconds
I would appreciate it if somebody can confirm if my suspicion is correct.
Regards,
Dragos
From: David Stevens <hidden> Date: 2012-08-02 12:59:05
netdev-owner@vger.kernel.org wrote on 07/26/2012 10:57:43 AM:
RFC 3810 says that the timeout should be computed as
Robustness_Variable * Query_Interval + Query_Response_Interval. This
suggests that the line where switchback is computed should be changed
to something like
switchback = (idev->mc_qrv * 125 * HZ) + max_delay;
where 125 is the default Query_Interval in seconds
Dragos,
I agree that it's too short, but this shouldn't be using the
default value, but rather the actual value of the querier, if one is
present,
as calculated from a QQIC in a query. I suggest saving the QQI,
decoded, in a new "idev->mc_qqi" which should be initialized to 125
but updated by received queries and then using:
switchback = idev->mc_qrv * idev->mc_qqi * HZ + max_delay;
+-DLS
On Thu, Aug 2, 2012 at 2:58 PM, David Stevens [off-list ref] wrote:
netdev-owner@vger.kernel.org wrote on 07/26/2012 10:57:43 AM:
quoted
RFC 3810 says that the timeout should be computed as
Robustness_Variable * Query_Interval + Query_Response_Interval. This
suggests that the line where switchback is computed should be changed
to something like
switchback = (idev->mc_qrv * 125 * HZ) + max_delay;
where 125 is the default Query_Interval in seconds
Dragos,
I agree that it's too short, but this shouldn't be using the
default value, but rather the actual value of the querier, if one is
present,
as calculated from a QQIC in a query. I suggest saving the QQI,
decoded, in a new "idev->mc_qqi" which should be initialized to 125
but updated by received queries and then using:
switchback = idev->mc_qrv * idev->mc_qqi * HZ + max_delay;
+-DLS
David,
MLDv1 packets do not have a QQIC field in the Query header. That is a
available for MLDv2 only. Consequently, MLDv1 queriers should fallback
on the Query Interval variable, which has a default value of 125
seconds. Since the Query Interval value is not user-configurable, I
assume that using the default value is a reasonable choice.
RFC 3810(MLDv2) does mention that the Older Version Querier Present
Timeout must be calculated using the Query Interval from the last
received Query. I think the RFC is wrong on that point because I don't
see how a MLDv1 querier can convey its Query Interval to a listener.
Regards,
Dragos
From: David Stevens <hidden> Date: 2012-08-02 13:58:55
Dragos Ilie [off-list ref] wrote on 08/02/2012 09:28:49 AM:
MLDv1 packets do not have a QQIC field in the Query header. That is a
available for MLDv2 only. Consequently, MLDv1 queriers should fallback
on the Query Interval variable, which has a default value of 125
seconds. Since the Query Interval value is not user-configurable, I
assume that using the default value is a reasonable choice.
The QQIC would come from v2 queries prior to the v1 query that
triggered us to switch to v1. But, see below.
RFC 3810(MLDv2) does mention that the Older Version Querier Present
Timeout must be calculated using the Query Interval from the last
received Query. I think the RFC is wrong on that point because I don't
see how a MLDv1 querier can convey its Query Interval to a listener.
I'll look through this some more. I think using a fixed timeout
is a bad idea since it doesn't account for shorter or longer interval
queriers intentionally configured that way. Ideally it should,
of course, be a positive indication that the v1 querier is gone
based on v1 querier data (your point).
+-DLS
On Thu, Aug 2, 2012 at 3:57 PM, David Stevens [off-list ref] wrote:
Dragos Ilie [off-list ref] wrote on 08/02/2012 09:28:49 AM:
quoted
MLDv1 packets do not have a QQIC field in the Query header. That is a
available for MLDv2 only. Consequently, MLDv1 queriers should fallback
on the Query Interval variable, which has a default value of 125
seconds. Since the Query Interval value is not user-configurable, I
assume that using the default value is a reasonable choice.
The QQIC would come from v2 queries prior to the v1 query that
triggered us to switch to v1. But, see below.
How about the scenario where you have only MLDv1 queriers? There will
be no prior v2 query
quoted
RFC 3810(MLDv2) does mention that the Older Version Querier Present
Timeout must be calculated using the Query Interval from the last
received Query. I think the RFC is wrong on that point because I don't
see how a MLDv1 querier can convey its Query Interval to a listener.
I'll look through this some more. I think using a fixed timeout
is a bad idea since it doesn't account for shorter or longer interval
queriers intentionally configured that way. Ideally it should,
of course, be a positive indication that the v1 querier is gone
based on v1 querier data (your point).
+-DLS
From: David Stevens <hidden> Date: 2012-08-02 14:25:52
netdev-owner@vger.kernel.org wrote on 08/02/2012 10:03:24 AM:
quoted
The QQIC would come from v2 queries prior to the v1 query that
triggered us to switch to v1. But, see below.
How about the scenario where you have only MLDv1 queriers? There will
be no prior v2 query
Yes, this is why I suggested initializing it to the
default of 125. If we actually saw v2 queries with different
intervals, we'd adjust longer or shorter, but use the default
only when we had no queries to update it.
+-DLS
Hi David,
I have been thinking about how to address your concerns about the
MLDv1-mode timeout. Unfortunately, I think by doing that we would stop
being compliant with RFC 3810 on the following points:
a) Section 5.1.9 states that the QQIC field is meant for other
multicast routers that are not the current querier. I "grep-ed" after
mld2q_qqic in the entire kernel source tree and it is not being used
at all. I take this as a sign that the field is not to be interpreted
by listeners. Of course, that does not mean we cannot use it, but see
b) below
b) Section 8.3.1 says that "if an MLDv1 router is present on the link,
the Querier MUST use the lowest version of MLD present on the
network". Also, "if an MLDv1 router is present on the link, the system
administrator must explicitly configure all MLDv2 routers to act in
MLDv1 mode". It seems to me that these statements together preclude a
scenario with MLDv1 and MLDv2 routers mixed together on the same link,
unless all routers speak MLDv1.
The current implementation for MLDv1 compatibility mode works very
badly. The listeners fail most of the time to join the groups on the
MLDv1 server. I suggest that my patch sent earlier this week is
pushed upstream, unless there are concerns that it will make things
worse than they are today. This will improve the behavior of MLDv2
listeners with MLDv1 routers and keep us compliant with the RFC. What
do you think?
On Thu, Aug 2, 2012 at 4:25 PM, David Stevens [off-list ref] wrote:
netdev-owner@vger.kernel.org wrote on 08/02/2012 10:03:24 AM:
quoted
quoted
The QQIC would come from v2 queries prior to the v1 query that
triggered us to switch to v1. But, see below.
How about the scenario where you have only MLDv1 queriers? There will
be no prior v2 query
Yes, this is why I suggested initializing it to the
default of 125. If we actually saw v2 queries with different
intervals, we'd adjust longer or shorter, but use the default
only when we had no queries to update it.
+-DLS
--
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
From: David Stevens <hidden> Date: 2012-08-03 13:00:56
Dragos Ilie [off-list ref] wrote on 08/03/2012 04:54:09 AM:
a) Section 5.1.9 states that the QQIC field is meant for other
multicast routers that are not the current querier. I "grep-ed" after
mld2q_qqic in the entire kernel source tree and it is not being used
at all. I take this as a sign that the field is not to be interpreted
by listeners. Of course, that does not mean we cannot use it, but see
b) below
The kernel doesn't use it because it doesn't use the QI in the
timer to switch back to MLDv2 -- the problem you're trying to address.
If you think that's a bug (and I agree it is), the QQIC is how we
determine the QI. Missing functionality isn't evidence we shouldn't
use the QQIC. :-)
b) Section 8.3.1 says that "if an MLDv1 router is present on the link,
the Querier MUST use the lowest version of MLD present on the
network". Also, "if an MLDv1 router is present on the link, the system
administrator must explicitly configure all MLDv2 routers to act in
MLDv1 mode". It seems to me that these statements together preclude a
scenario with MLDv1 and MLDv2 routers mixed together on the same link,
unless all routers speak MLDv1.
MLDv2 requires MLDv1 compatibility mode so there's no such thing
as an MLDv2 implementation that doesn't support MLDv1. The mechanism
for falling back to MLDv1 is required for exactly the case when there
is a mix of versions on the link; if that could never happen, none
of this code would be necessary or required by RFC.
The current implementation for MLDv1 compatibility mode works very
badly. The listeners fail most of the time to join the groups on the
MLDv1 server.
I'm not sure what you mean here. Certainly you can, as suggested
above, force all hosts on the subnet to use MLDv1 using the
"force_mld_version" sysctl and an MLDv1 querier will also do that.
They'll switch back to MLDv2 too soon, if the v1 queries happen
infrequently which you can trivially work around by querying more
often.
I suggest that my patch sent earlier this week is
pushed upstream, unless there are concerns that it will make things
worse than they are today. This will improve the behavior of MLDv2
listeners with MLDv1 routers and keep us compliant with the RFC. What
do you think?
I think it should be correct, and a fixed QI isn't. If we're going to
do a hack, I think a v2-based QI is better than a fixed value.
However, I was thinking we could directly
measure the v1 QI based on received v1 queries. The main problem with
that is you don't know if you lost one or not, but we could work
around that by using the min of a saved QI and the measured interval
since the last query from the same source. The measured QI with losses
is always a multiple of the actual QI.
So, when we get a v1 query, save a timestamp of it and use the timestamp,
if set, to compute the interval since the last query. If the interval
is less than our current QI, it's the new QI. For the switchback time,
we use QI if set and 125 if not, where not being set would indicate
we haven't gotten more than 2 v1 queries.
Finally, periodically (e.g., based on query counts, or multiple
larger QIs) reset in case an admin has increased the QI without a
reboot.
The QI value only matters if it's the same querier, so also
with the timestamp save the source querier IP address and reset
if you get a general query from a different querier.
+-DLS