Subject: assert applied to s or (s,g)

From: [email-masked] (Ravi Shekhar)
Date: Tue, 3 Nov 1998 19:23:51 -0500 (EST)

Hi,
    In PIM-DM, does the result of an assert apply to the associated 
    <source, group> pair or does it apply to the <source> for all 
    possible groups?

        For eg, if routers R1 and R2 have asserted for <s1, g1>,
    do they need to assert for <s1, g2>? 

    In PIM-SM it makes sense as different sets of routers might be
    forwarding data for different groups on a LAN. But in DM, since 
    initial flooding is independent of group, it might not be any
    more beneficial to do asserts for the same <source> again and 
    again.

    Thanks.
    - Ravi Shekhar.

---

From: Liming Wei <[email-masked]>
Date: Tue, 3 Nov 1998 17:36:10 -0800 (PST)

> From: [email-masked] (Ravi Shekhar)
>
> Hi,

I've been hearing this for years :-).  One issue is consistency,
i.e. either assert is for all groups, OR it is only for one group. We
can't make it optional. So to do the optimization, we need another bit
to say, "assert for all groups".

But a more important issue is that it may not buy much when "s1"
is sending to g1, g2 does not exist yet, and when it is time to
assert for g2, g1's assert was already done. All subsequent timeout
and re-assert *might* be helped, BUT that will bring up issues with
syncing the prune timers across groups...

I'd say, nice idea, how about lets hold off pushing it into the current
version 2 specification, while investigating more over coffee or
a drink or something :-) ?

-Liming

---

From: [email-masked] (Ravi Shekhar)
Date: Tue, 3 Nov 1998 21:11:42 -0500 (EST)

>to say, "assert for all groups".
    
    I agree that the bit will be required to interoperate with existing 
    implementations of PIMDM. But some sort of extra information is required
    even if we postpone it for the later versions of PIMDM. 

>assert for g2, g1's assert was already done. All subsequent timeout
    
    On the contrary, I think thats the exact situation where its beneficial. 
    If assert for <s1, g1> is already done, there is no need to do assert 
    for <s1, g2>. Keep the result of assert with <s1>.

    Not to mention that associating assert with the source will help 
    in reducing the state in each router - assert timeout will be per 
    <source> as opposed to per <source, group> pair.

>syncing the prune timers across groups...
    
    I dont see how it is required to sync prune timers across groups.

    It is required to sync the prune timer for <s1, g1> with the 
    assert-timeout for the <s1> (which we have to do even now). 

    Why is there a need to sync <s1, g1>'s prune timer with the prune 
    timer of <s1, g2>?

    - Ravi Shekhar.

---

From: Liming Wei <[email-masked]>
Date: Tue, 3 Nov 1998 20:38:02 -0800 (PST)

Ravi,

I think you just re-started a thread on designing/debugging a
protocol machinery on the fly.

>     even if we postpone it for the later versions of PIMDM. 

It definitely should be considered for later versions of
PIMDM, given so many alternative ways of achieving similar results.
(To say something more general, without targetting your idea, we don't
 want to suck in each and every of those machineries on the way of
 discovery, and gradually mutate into a protocol of the united
 nation of good ideas. But please do not take this as a rejection
 to new ideas. We must be open to what we discuss, and have to be
 cautious to what we want to put in.
 And BTW, this source-based assert idea was proposed by a number of
 PIM co-authors before, but didn't make it for different reasons.)

>     <source> as opposed to per <source, group> pair.

That reduces one timer, but you require extra maintenance on
all the known sources, independent of the multicast routing
table. Currently we don't require that. And btw, the benefit
of reducing that one timer is rather insignificant (while
the assert optimization is, but it can be achieved by various
other proposals).

>     Why is there a need to sync <s1, g1>'s prune timer with the prune 

None of the pruned interfaces should expire as long as the single
assert timer isn't (else you haven't achieve anything).

Again, from this interaction, you see how protocol ideas can appear
very close to being perfect, but always need one more round of
hashing.

-Liming

---

From: [email-masked] (Ravi Shekhar)
Date: Wed, 4 Nov 1998 11:04:42 -0500 (EST)

>That reduces one timer, 
    
    Not true. (n-1) timers/timeout-values if there are n groups active 
	from the same source.

    And as you said, assert optimization too. For all of those (n-1) 
    groups.

>assert timer isn't (else you haven't achieve anything).
    
    Can you elaborate on it a little more, if possible with an example. 
    I didnt get what you are trying to say.

    - Ravi Shekhar.