Subject: Re: [pim] pop-count issue, your input wanted

From: Stig Venaas <[email-masked]>
Date: Tue, 02 Oct 2012 14:34:40 -0700

Not a lot of feedback...

On 9/26/2012 10:40 AM, Stig Venaas wrote:
> As part of the IESG review of draft-ietf-pim-pop-count-06.txt,
> someone questioned that the Transit and Stub oif-List counts are
> only 2 octets.
>
> This means that with pop-count, we currently have a limit on 64k
> transit or stub oifs that can be counted for a tree. So if there
> are more than 64k hosts, or more than 64k pim routers, we cannot
> count them.
>
> Do you have any thoughts on whether we should extend these to 4
> octets?
>
> I think the alternatives are more or less these:
>
> 1. Not change anything, 65535 means 65535 or more oifs.
>
> 2. Introduce an exponential encoding, allowing larger values than
>     65535 but with less precision for large counts. Sort of like
>     max resp time etc in IGMP/MLD.
>
> 3. Extend in the future if needed. One could add a new 16 bit
>     option that is only included if the count is bigger than 64k,
>     to store additional 16 bits.
>
> 4. Simply extend to 32 bits.
>
> The semantics of the 2 could be different. The PIM count is likely
> to be smaller than the host count. So stub bigger than transit. But
> I suggest keeping them the same.
>
> Thoughts?

I think I'll go for 4, unless anyone has other ideas. Comments welcome.

Stig

> Stig
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 2 Oct 2012 16:42:37 -0700

> Not a lot of feedback...

Maybe i am overlooking something, but:

I think that in a large tree, the values for the size of the tree are
completely useless. Imagine routers with a fan-out of 10 each and a simple
tree, eg: you aggregate 10, 100, 1000, 10,000 OIF-entries on the
tree. If we look at the last-hop routers, maybe during an observation
period of 60 seconds between periodic joins sent upstream you
actually have a good amount of zapping activity, so the smallest
number of joiners during that period may be 2, and the largest number
of joiners may be 8.

So, what is this router going to send in the periodic join ?
The way i read the text, it may be randomnly the number of joiners
at the point in time when it has to send the periodic join. Lets
say on each of the leaf routers there is the same joiner behaviors
(quite likely for TV), so i end up at the top router with a randomn
number between 2,000 and 8,000. And i have no clue at all that this
number is even that randomn. It will just randomnly change every
6 seconds (top router aggregation 10 routers with maximum of 1000
joiners below, so this router gets 10 periodic joins every minute.
Figuring out the variability over time will take quite a while.

Meaning: I would like to see "aggregation of "Max Stub Oif List Count"
and "Min Stub Oif List Count". That's IMHO the only way to get an idea
about the actual dynamics of the number of joiners.

Once we know that the minimum number of joiners is dynamically a lot
smaller during an observation period than the maximum, it is also
clear that all the other parameters may be varying during the observation
period, but we likely want to only know the worst == max value
initially, eg i think the text should just change the names of

"Domain Count", "Node Count" "Diameter Count", "TZ Count" and 
"Transit OIF List Count" each to "Max XXX", eg: have them be defined
as the max - for Diameter this is already defined.

Wrt. to encoding, i think that i like accuracy because there are a
lot of deployment that really expect stable large trees and so
even a missing single joiner would be lovely to still see at the
root of the tree. So i think i prefer a 16/32 bit encoding for
max/min Stub Oif List count: 0-16383: 16 bit, when high bit is set,
then remaining 31 bits are the value - or something like that.

Also: Given how we're still here and this draft is not out the door,
i think it would be good to write a paragraph about how to use this
with PORT. Should a PORT router also send periodic updates when
pop-count is being used ? It could definitely avoid to do that
when the Min/Max values are still the same for the last 60 seconds
than they where for the prior 60 seconds, but that's of course unlikely.
But we could of course introduce another parameter optionally for
PORT which is the "Longest Observation Period", and with PIM every
router would set it to 60 seconds, and if PORT routers feel the need
to have longer observation periods, then this was easily observable
at the root of the tree. Of course this would also be useful if
any PIM had different periodic intervals than 60 seconds configured,
but i think that's unlikely.

Last but not least, i would really like to be able to count individual
joiners and not only OIF. Can we please define an "E" bit for
"Explicit Member counting", and a node setting this is indicating
that it is counting individual IGMP/MLD members as an OIF for the 
"Min/Max Stub OIF-List Count". How the node does that, eg: via
integrated IGMP snooping if it's an L2/L3 device, or via IGMP/MLD
explicit tracking, is insubstantial.

Cheers
    Toerless

---

From: Stig Venaas <[email-masked]>
Date: Wed, 03 Oct 2012 10:46:30 -0700

Hi

> Figuring out the variability over time will take quite a while.

I'm not sure what you get the numbers 2 and 8 from, but don't you
think that you will get some kind of average. Depending on exactly
when the users change channels and when the routers report, you
may report some that will leave before the next report, and you miss
reporting some that will join before the next report, but wouldn't
these details be averaged out?

> about the actual dynamics of the number of joiners.

I agree that could be useful to get some idea of the dynamics, but I
don't think we should do this change now.

> initially, eg i think the text should just change the names of

If we have min, then max also makes sense. But with what we have
now, I prefer the current.

> then remaining 31 bits are the value - or something like that.

Are you OK with just using 32 bits? This is simpler since there is
no variable length.

> Also: Given how we're still here and this draft is not out the door,

The draft is pretty much done. It passed last call and we're only
doing minimal changes based on the IESG/directorate reviews. The
only protocol change we need to consider IMO is the size of the
2 above defined fields.

I would suggest getting this out the door ASAP. Once we have some
implementations and experiences, we can consider adding some new
fields/options if needed.

> than they where for the prior 60 seconds, but that's of course unlikely.

Can we delay this until we see actual deployments? Your comments
seem reasonable though.

> explicit tracking, is insubstantial.

You wold also do this if there is a host on a point-to-point
interface then I assume? I agree it could be useful.

My take on this though is that this draft is finally practically done
after 8 years! This has been painful enough, and I would like to defer
any extensions until we have some experience with deploying this one
and we see the need.

This is just my view as an author though. It depends on what the WG
thinks. I'll post a version with the changes based on the IESG review
shortly. Then we can see what you and the rest of the WG thinks.

Stig