From: David Miller <davem@davemloft.net>
To: haliu@redhat.com
Cc: mtesar@redhat.com, kuznet@ms2.inr.ac.ru, jmorris@namei.org,
kaber@trash.net, netdev@vger.kernel.org
Subject: Re: [PATCH] igmp: Make igmp group member RFC 3376 compliant
Date: Wed, 16 Nov 2016 11:19:43 -0500 (EST) [thread overview]
Message-ID: <20161116.111943.1827868712701090468.davem@davemloft.net> (raw)
In-Reply-To: <20161116062045.GB17935@leo.usersys.redhat.com>
From: Hangbin Liu <haliu@redhat.com>
Date: Wed, 16 Nov 2016 14:20:45 +0800
> Hi David,
>
> On Tue, Nov 08, 2016 at 10:26:25AM +0100, Michal Tesar wrote:
>> On Mon, Nov 07, 2016 at 08:13:45PM -0500, David Miller wrote:
>>
>> > From: Michal Tesar <mtesar@redhat.com>
>> > Date: Thu, 3 Nov 2016 10:38:34 +0100
>> >
>> > > 2. If the received Query is a General Query, the interface timer is
>> > > used to schedule a response to the General Query after the
>> > > selected delay. Any previously pending response to a General
>> > > Query is canceled.
>> > > --8<--
>> > >
>> > > Currently the timer is rearmed with new random expiration time for
>> > > every incoming query regardless of possibly already pending report.
>> > > Which is not aligned with the above RFE.
>> >
>> > I don't read it that way. #2 says if this is a general query then any
>> > pending response to a general query is cancelled. And that's
>> > effectively what the code is doing right now.
>>
>> Hi David,
>> I think that it is important to notice that the RFC says also
>> that only the first matching rule is applied.
>>
>> "
>> When new Query with the Router-Alert option arrives on an
>> interface, provided the system has state to report, a delay for a
>> response is randomly selected in the range (0, [Max Resp Time]) where
>> Max Resp Time is derived from Max Resp Code in the received Query
>> message. The following rules are then used to determine if a Report
>> needs to be scheduled and the type of Report to schedule. The rules
>> are considered in order and only the first matching rule is applied.
>
> ^^
>
> Would you like to reconsider about this? I also agree with Michal that we
> need to choose the sooner timer. Or if we receive query very quickly, we
> will keep refresh the timer and may never reply the report.
I'm still thinking about this, please be patient, I review a hundred
patches or more per day so it takes me time to get to tasks that
require deep thinking or real consideration on any level.
next prev parent reply other threads:[~2016-11-16 16:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-03 9:38 [PATCH] igmp: Make igmp group member RFC 3376 compliant Michal Tesar
2016-11-08 1:13 ` David Miller
2016-11-08 9:26 ` Michal Tesar
2016-11-16 6:20 ` Hangbin Liu
2016-11-16 16:19 ` David Miller [this message]
2016-12-07 12:38 ` Michal Tesar
2016-12-30 3:32 ` David Miller
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=20161116.111943.1827868712701090468.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=haliu@redhat.com \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=mtesar@redhat.com \
--cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).