Re: [pim] Please respond! Re: draft-ietf-pim-explicit-tracking pim 2nd wglc

[Hitoshi Asaeda <[e-mail]>]

>> > 1. In Abstract, can we remove the usage of 'fast leave' and just
>> > keep 'shortening leave latency'. A quick google search on 'fast
>> > leave' shows that it is a known term in the context of IGMPv2 where
>> > a router does not send the group specific query and stops forwarding
>> > multicast traffic for the group on that interface. As here 'fast
>> > leave' is not referring to a similar behavior, I suggest to use
>> > 'shortening leave latency' instead.
>> 
>> Fast leave itself is a general terminology. It does not specific only
>> for the IGMPv2's procedure. For example, see rfc3810 (MLDv2).
> 
> RFC 3810 defines a normal leave in IGMP term as fast leave. I am not
> sure why that term was used in MLDv2 RFC. If someone on the list
> knows, I would want to know.
> 
> As this draft talks about both IGMP/MLD, and as 'Fast leave' is
> known as two different things in IGMP and MLD, to keep abstract
> protocol independent, I would suggest to not use 'Fast leave' in
> this draft.

RFC3376 also says;
      Routers may want to track per-host membership status on an
      interface.  This allows routers to implement fast leaves (e.g.,
      for layered multicast congestion control schemes) as well as track
      membership status for possible accounting purposes.

First leave is common terminology, not dedicated for IGMPv2.
(BTW, also you can see the word, "accounting", here as the potential
use case.)

>> > 3. In third par of section 1, first sentence seems complex to me.
>> >
>> Ok, I'll simplify the sentence to the following;
>> 
>>    Multicast routers send periodic queries within the General Query
>>    timer interval (i.e., [Query Interval] value defined in [1][2]) to
>>    keep the membership state up to date.
> 
> I am fine with this text. But are you sure you do not want to
>  mention solicited reports in and around this sentence. Previous
>  sentence was trying to bring out that synchronization happens
>  because general query triggers solicited reports.

Use of solicited reports is mentioned in the second paragraph, so it's
Ok.

> So I think it would be better to explain this in couple of sentences
> if you want to keep them in the draft. I understand that this may be
> out-of-scope of this draft but as this draft is suggesting that
> explicit tracking function is helpful in these two cases, it is
> better to explain how.

Giving too much explanation for out-of-scope topics leads confusion.
As rfc3376 does, this draft should simply show the potential use
cases.
Let's keep them as is, and if I get the similar concern from others,
I'll remove these use cases.

>> > 8. In section 3.2, in first sentence,
>> >
>> > In accordance with [1] and [2], whenever a router receives the State-
>> > Change Report, it sends the corresponding Group-Specific or Group-
>> > and-Source Specific Query messages to confirm whether or not the
>> > report sender is the sole member host.
>> >
>> > Can we reword the above because router does not always send
>> > Group-Specific or Group-and-Source Specific Query messages whenever
>> > it receives a State-Change Report? We can reword it to:
>> >
>> > In accordance with [1] and [2], whenever a router receives the State-
>> > Change Report, it might send the corresponding Group-Specific or
>> Group-
>> > and-Source Specific Query messages to confirm whether or not the
>> > report sender was the sole member host.
> 
> What I was trying to point out is that when a router receives
>  State-Change report, it does not always send a specific
>  query. Please refer to the table in section 6.4.2 in RFC 3376. So
>  the above statement is not fully correct. A router sends specific
>  query in only few cases.

Ok, I understand your point.
I'll slightly change the sentence as follows;
    ... whenever a router receives the State-Change Report messages
    and changes its router state, it sends the corresponding
    Group-Specific or Group-and-Source Specific Query messages to
    confirm whether or not the report sender is the sole member host.

>> > Please also note the change of 'is' to 'was' in the last part of the
>> > sentence.
>> 
>> I don't think "is" is wrong.
> 
> The host had sent a state-change report because the host does not
> want traffic for the channel. Router sends a specific query. Router
> needs to confirm whether there is any more members for this
> channel. So router is confirming whether the host was the last
> member or not. That is why I suggested to use 'was'.

I understand your thought, but still I prefer to use "is" here,
because the router needs to confirm the current state, not the
previous state the report sender sent the report.
Let's see IESG reviewer's comment.

>> > 11. A similar issue exist when LMQC and LLQC is explained in the above
>> > para.
>> 
>> I don't think so, because this sentence comes from rfc3810.
> 
> I think my comment was not clear here. What I was saying about the
> following sentence was:
> 
> The [Last Member Query Count] (LMQC) and [Last
> Listener Query Count] (LLQC) are the number of Group-Specific Queries
> or Group-and-Source Specific Queries sent before the router assumes
> there are no local members.
> 
> The last part of the sentence mention that router assumes there are
>  no local members after sending these many queries while router
>  assumes there are no local members only when LMQT expires. I was
>  trying to point out this difference.

Your understanding is correct, and the original statement is also
correct.
The router sends specific queries these times before it assumes there
are no local members. This statement is described in both rfc3376 and
3810. Also, this statement does not inconsistent the statement, "the
router assumes there are no local members when LMQT/LLQT expires",
what you said.

>> > 12. Last para of section 3.3 tries to describe how a lower values of
>> > LMQI/LMQC then the default suggested, can shorten the leave
>> > latency. But it does not clearly articulate how explicit tracking
>> > function helps if the two parameters are configured to the lower
>> > values. Can we add some details on that here?
>> 
>> LMQI/LLQI are the standard values defined in rfc3376 and 3810. All the
>> details and configurations are mentioned in them, and I believe
>> repeating these descriptions in this document wouldn't be needed.
> 
> I think you did not get my question. Let me rephrase this.
> 
> Without explicit tracking function, if we lower the LMQI or LMQC or
> both, leave latency can be reduced.
> 
> With explicit tracking function also, if we lower the LMQI or LMQC
> or both, leave latency can be reduced. So what is the
> differentiation explicit tracking function is bringing in here?

Comparing with no tracking condition, the explicit tracking function
lowers the risk of wrong membership expectation. Therefore with the
explicit tracking function, LMQI/LLQI can be shorter and LMQC/LLQC can
be smaller than both default values.
This is the reason that this doc says;
   the LMQI/LLQI MAY be set to 1 second or shorter. The LMQC/LLQC
   values MAY be set to 1 for the router, whereas their default values
   are the [Robustness Variable] value whose default value is 2.

>> > 13. In section 4, in 3rd para, in following sentence:
>> >
>> > The second case occurs when a router sends a specific query but does
>> > not receive a State-Change Report from a downstream host within an
>> > LMQT or LLQT period.
>> >
>> > I think when a host receives specific query, it generates a
>> current-state
>> > report. Right?
>> 
>> Right.
>> As the document says "membership expectation will be inconsistent due
>> to an outdated membership state", this section describes the situation
>> in which report messages sent by downstream members are not reached to
>> the router due to some trouble.
> 
> What I was trying to point out is that the sentence mention the
> 'State-change' report while a host generates 'Current-state' report
> when it receives a specific query so should the sentence be using
> 'Current-state' report.

Oh, good catch. It's typo. Thanks.

>> > 14. As host membership protocols are unreliable, there will always
>> > be a possibility of outdated membership state as packets may get
>> > lost. I am not sure how does explicit tracking function lowers this
>> > possibility.
>> 
>> This document does not say that the explicit tracking function lowers
>> that possibility. This section discusses how to lower the possibility.
>> If people misunderstand the point, I'll clearly say,
>>     Regardless whether the explicit tracking function is enabled or
>>     not, there are possibilities that a router's membership
>>     expectation is inconsistent due to an outdated membership state.
>> at the beginning of this section.
> 
> I think there are two issues here:
> 
> The section title is misleading. When I was reading the draft, I got
> an impression that explicit tracking function is lowering the
> possibility of outdated membership.

Ok, then how about, "Lowering the Risk of Wrong Membership
Expectation"?

> Second issue is that the section also does not clarify this clearly.

So as I said how about adding the followin sentence at the beginning
of this section?

   Regardless whether the explicit tracking function is enabled or
   not, there are possibilities that a router's membership
   expectation is inconsistent due to an outdated membership state.

>> > 18. In section 6, should not we talk about how the membership state
>> > information is deleted when the version is lowered and the channel
>> > is no more required.
>> 
>> Do you mean the following "MAY NOT" is not suitable for this document
>> as it's implementation dependent?
>> "the router MAY NOT flush the maintained membership state information"
>> If so, I could agree. I'll change "MAY NOT" to "may not".
> 
> I think you did not get my question. Let me rephrase it.
> 
> This draft suggest that router create a new state to explicitly
> track the host that are joining a channel. Let us assume that the
> host crashed before sending a leave. How and when this new state
> maintained in the router is removed?

Maybe I don't still understand your question.
If you are talking about outdated membership status due to the
maintained host crash, the membership status will be updated by
general query as mentioned in section 4.
If you are talking about the statement of flushing the maintained
membership state information in the older version compatibility mode,
if you think this behavior is implementation dependend, I'm Ok to
remove the statements starting from "On the other hand" in section 6.
Or other way you prefer?

>> > 19. If we can assume that the robustness count configured in a
>> > router truly represents the robustness of that network and if a
>> > packet is sent this many times, the intended destination will
>> > receive the packet at least once, this whole draft can be simplified
>> > a lot. There is no need to generate group or group-source specific
>> > queries even when all the hosts have left that channel. I am sure
>> > there is something I have missed because this is how fast/immediate
>> > leave is implemented for older version of protocols.
>> 
>> I tend to agree, but such protocol tuning is beyond the scope of this
>> document.
>> Also, we had discussions about specific query suppression in the
>> meetings several times. Our consensus was that the specific query
>> suppression should be the option (i.e. saying "SHOULD disable this
>> specific query suppression" as you see in section 3.2).
> 
> I think its not protocol tuning.
> 
> A network admin should always know its robustness against unreliable
> protocols. So the unsolicited messages should always reach the
> router. If we say that there are chances that unsolicited reports
> won't reach the router which are sent in multiple than in my
> opinion, there is no guarantee that solicited messages will reach
> the router.
> 
> This whole concept of explicit tracking function becomes easier if
> we follow the above logic.
> 
> Do you see an issue with the above logic?

I agree such discussion is interesting, but it is beyond the scope of
this document.
The solution regarding how the protocol robustness is improved and how
the message transmission is guaranteed is not simple. It is not solved
only with the explicit tracking function.
I'm happy to work on this topic, but it is not a good idea to discuss
such solution in this document.
(Note that the IGMP/MLD protocol tuning mainly for wireless and mobile
environment is issued in rfc6636 and the more general protocol
modification discussion is on going in the Mike's I-D.)

Regards,
--
Hitoshi Asaeda