Subject: IGMPv3 protocol spec questions

From: Dave Thaler <[email-masked]>
Date: Fri, 28 Jan 2000 20:56:51 -0800 (PST)

I've already sent the authors some comments on the Appendix
a few weeks ago.

I just got a chance to go through the sections on Host behavior,
so here's my comments on those sections.  I still have not had
a chance to review the Router behavior sections.

I found at least 2 things in the protocol itself that look broken.
Details below.

-Dave

---
Comments on draft-ietf-idmr-igmp-v3-02.txt

Section 3.2, clarifying question:
Text says a host may limit size of source list whose filter mode is INCLUDE.
Does this wording mean a host MUST NOT limit the size of source list
for EXCLUDE?

Section 5.1, I believe the behavior specified here is broken:
> If more changes to the same interface state entry occur before all the
> retransmissions of the State-Change Report for the first change have
> been completed, each such additional change triggers the immediate
> transmission of a State-Change Report reflecting the difference between
> the newest state and the state *before* the first change for which
> retransmissions were not completed.

The reason the above is broken is because of the table preceding it,
and the sentence after the table:
> If the computed source list for either an ALLOW or a BLOCK State-Change
> Record is empty, that record is omitted from the Report message.

Example of broken scenario:
1) App joins group normally, i.e. IPMulticastListen(s,i,m,EXCLUDE,{})
2) Kernel sends TO_EX({}) [Robustness] times over the appropriate time
   internal.  Router gets this, everyone is happy.
3) App excludes a new source, i.e. IPMulticastListen(s,i,m,EXCLUDE,{A})
4) Kernel sends a triggered BLOCK({A}) and sets retransmission timer
   to random value up to 10 seconds.  Router receives this message.
5) Before the timer expires, App un-excludes the source. i.e. 
   IPMulticastListen(s,i,m,EXCLUDE,{})
   Since the retransmissions are not completed, the new change
   triggers the immediate transmission ... reflecting the difference
   between the newest state and the state after step 2.
   Since this state is identical, no messages are sent because
   of the second blurb quoted above (this also applies if the app
   instead left the whole group and rejoined it).
6) Regardless of whether the retransmission timer was restarted, 
   deleted, or left untouched, no further messages are triggered
   because the newest state, and the last fully-transmitted state
   are identical.  At this point, the application has asked to receive
   A, and the router is blocking it, resulting in a black hole.
This black hole continues until the next Query is received and
responded to, which can be up to 125 seconds later.

Summary: 0 packets lost, IGMPv3 causes black hole for up to 125 seconds.
(Or, if you prefer, you could say that "join latency is up to 125
seconds" since this is upon rejoining a left group or source).

Section 5.2, clarifying question:
If you receive two group-and-source-specific queries with
partially overlapping source lists, where neither is a subset of 
the other, current spec says you reply to both of them, meaning 
you may report some sources twice.  Is this the intended behavior?

Sections 7.2, 7.2.3, 8.12 are contradictory/broken regarding receipt of
IGMPv2 queries while in IGMPv1 Mode:
7.2 states:
> Each time a non-version 3 query is received, a host sets a timer: Older
> Version Querier Present Timeout.
8.12 agrees with the above, saying:
> The Older Version Querier Interval is the time-out for transitioning a
> host back to IGMPv3 mode once an older version query is heard.  When an
> older version query is received, hosts set their Older Version Querier
> Present Timer to Older Version Querier Interval.
Both of the above paragraphs say that the timer is reset when an
IGMPv2 Query is received while in IGMPv1 Mode.
7.2.3 on the other hand, contradicts them.  On the arrow for "R2Q"
coming out of "V1 Mode", the "RT" (reset timer) event is NOT shown,
hence the contradiction.

If the 7.2/8.12 behavior is correct (meaning you reset the timer),
then you can have a situation where only IGMPv2 routers exist, but
the host is stuck permanently in IGMPv1 mode.  This seems broken.

If the 7.2.3 diagram is instead correct and 7.2 and 8.12 are wrong,
then you can have a situation where only IGMPv2 routers exist now
(IGMPv1 router went away), and the host has just fallen back to IGMPv3 
mode due to the timer expiration.  Now all triggered reports (until 
the next IGMPv2 Query arrives up to 125 seconds later) will be IGMPv3 
reports that will be ignored by all routers.  This seems equally broken.

I think there needs to be two separate timers, 
a "Version 1 Querier Present Timer", and
a "Version 2 Querier Present Timer".

Section 7.2.1, contradiction in spec:
Table shows that an IGMPv2 report is sent in response to an IGMPv2
Query (and so on).  

However, the text preceding the table says that the version of report
sent depends on what version mode it's in, not the query version.
So in the case where the host is in (say) IGMPv2 mode, and it
receives an IGMPv3 query from a router that has restarted but has
not yet yielded to an older version querier (as 7.2 puts it),
should the host:
 a) send an IGMPv2 Report (according to the text before the table),
 b) send an IGMPv3 Report (according to the table), or
 c) ignore the query (can't find anywhere that says to do this) ?

Typos:

5.1 "source list for the effected multicast address"
s/effected/affected/

5.2 "messages have ben generated"
s/ben/been/

7.2 "immediately change it's state"
s/it's/its/