Subject: New internet draft: "Scalable Timers for PIM"

From: Puneet Sharma <[email-masked]>
Date: Wed, 02 Dec 1998 14:56:46 -0800

Hi,

We have submitted a new internet draft called "Scalable
Timers for Protocol Independent Multicast (PIM)" to 
the Internet Drafts list.

We will also be presenting it at Orlando IETF.

Here is the abstract:

PIM uses of periodic refresh messages, sent at fixed intervals to keep
multicast forwarding state alive while adapting to changing network
conditions. This has raised concerns regarding its scalability.  These
fixed join-prune timer-values fail because they use time as a metric
for bandwidth; they adapt neither to (1) the wide range of link speeds
that exist in most wide-area internets, nor to (2) fluctuations in the
amount of network state over time.

In this document we propose a scalable timers approach in which
timer-values adapt dynamically to the volume of PIM control traffic
and available bandwidth on the link. 

A postscript version with diagrams is also available from:

ftp://netweb.usc.edu/pub/puneetsh/pim/stimers_id.ps

Regards,
Puneet.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 2 Dec 1998 20:04:02 -0500 (EST)

> We will also be presenting it at Orlando IETF.

I still have the same comments as before, which don't appear to have
been addressed (or even mentioned) in this draft.

I agree with the basic idea of scalable timers, and I believe
that scalable timers can work.  However, I have two problems 
with the specific mechanisms proposed for _receivers_ in this
draft:

1) They don't appear to work well on multiaccess links.
   It's unclear as to whether it requires keeping group state 
   _per neighbor router_ (which PIM does not) or just per 
   interface.  If only per interface, then I believe both
   proposed mechanisms are broken.  If per neighbor,
   then that's a potential state problem compared to existing PIM.

2) There appears to be a lot of unnecessary complexity in having
   the receiver guess at the senders current rate, rather than
   just having the sender tell the receiver.  For example,
   if the holdtime for all state varies together (i.e. if
   the holdtime changes from X seconds to Y seconds, then it
   does so for ALL joins from that sender to that receiver),
   then the sender can place a holdtime based on his _current_
   send rate in every join, and the receiver can update all its
   holdtimes accordingly.  The main point here is that you
   can never do worse with MORE information.  That is, the
   receiver can always do more intelligent things when it
   knows the sender's belief of the current holdtime, than
   when it doesn't.

   Furthermore, I would contend that having the receiver accept
   the sender's last holdtime it heard about as authoritative
   at that instant makes no additional assumptions than what 
   are made without such acceptance.

-Dave