Subject: Re: More comments on - I-D ACTION:draft-parker-isis-wg-mib-00.txt

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Thu, 3 Dec 1998 07:57:36 -0500 (EST)

Re: Peter Higginson's ResettingTimer issue:

It seems like there's two times. One
is the interval in which you actually send Hellos. The other is the
interval you report in those Hellos.

If you set the timer down, you clearly want to immediately start
sending hellos with the shorter interval, and reporting that short
interval in the Hello.

If you set the timer longer, how about sending a few Hellos with frequency=
the old, short interval, but with the timer listed in
those Hellos, the longer
interval? That way you wouldn't lose an adjacency if one Hello
gets lost. "A few" is probably should be equal to holdingMultiplier.
That way you wouldn't lose an adjacency when setting the timer longer
unless it would have gotten lost anyway without resetting the Hello Timer.

Radia

---

From: Mike Shand <[email-masked]>
Date: Thu, 03 Dec 1998 13:16:20 +0000

Radia,
	Yes, that seems much more sensible.

		Mike

---

From: Peter Higginson <[email-masked]>
Date: Fri, 04 Dec 1998 10:08:54 +0000

Mike,

One of the things that I am seeking to limit in the implementation is
the number of cases where you have to find and process all pending timers
of a particular type when there is a management change.

With mesh ATM networks and the proposal to extend the number of circuits
we could be talking large numbers here. Anything which instantly requeues
lots of hellos could be equally bad.

This is the reason that my prefered solution is to limit the max value 
and avoid the original 65535 problem.

What we have done in our implementation is count the timers up to >= the
set value so that the currently defined behaviour just works (without a
scan).

I am very much against anything that requires an implementation to go and
do comparisons of the times in the outstanding timers.

Peter

---

From: Mike Shand <[email-masked]>
Date: Fri, 04 Dec 1998 11:27:41 +0000

Peter,
	Well just sending a new hello immediately (possibly repeated as Radia
suggested, for which you only need the old value of the variable, not the
actual timer expiry time) seems to solve your objection to looking at
existing timers (unless your implementation cannot restart a running timer).

	However, it does of course potentially cause a large number of
synchronized hellos to be generated if you change lots of circuits all at
once (which is presumably what would happen with one of the 'system'
variable schemes).

	The classic solution the THAT problem of course would be to jitter the
sending of that first new hello. i.e. don't actually send the first hello,
but start a jittered timer.  Probably the simplest would be to delay a
random time between 0 and 1 seconds. This should give you a reasonable
distribution of your new hellos. Of course this might result in the loss of
a hello if you were already running very short timers. You could try
tweaking the delay according to your existing variable setting, but
whatever you do, if you don't look at your running timers, you could end up
in the situation where a timer was just about to go off, and any delay
would cause a hello loss (unless of course the other end sensibly
implemented a small margin of error to account for variable transit
delays). But what's the loss of a single hello between friends? (Disastrous
if you are silly enough to be running with a holdingMultiplier of 2, and
have some nasty transmission delays :-(

	OK, you could get around that by not actually stopping the running timer
when you started your random delay. Then if the real timer went off while
you were waiting you would treat that as the random timer going off and
carry on as above. But it's getting awfully complicated, and costs you
extra timers.

	I'm not sure that we can find a reasonable compromise between the maximum
timer value ever required and the maximum time that is tolerable to reset
to a shorter interval. If people think we can, then fine, but experience
shows that people have surprising ideas of what 'useful' timer values are.
(which is why we have all these parameters in the first place).

	Suppose we set the maximum value for any of these hello timers to 120
seconds. Do I hear screams of protest?

	Mike

BTW, the maximum theoretical value for the hello timers is of course in
general limited to 65535/holdingMultiplier, owing to the 16 bits available
in the PDUs for the holding time. :-)

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 08 Dec 1998 00:11:29 -0500

Mike Shand wrote:
> snip ...
> snip ...

I personally think that it's good enough to say "transmit the hello
immediately" the 
way Radia's proposing. An implementation has to be smart about it a
little so .e.g.
I could imagine doing something that jitters all the necessary
retransmits after 
the default value changed over "number of timers changed"/C seconds. We
don't have
to deliver an implementation design but a spec that can be implemented
reasonably.
Including sub-second 
timers in the spec is a pain IMHO and given the system constraints in a
really loaded-box not very
accurate anyway ;-)  I know that we have the spacing already there but
that does
not have to be implemented using fine-granularity timers like the hellos
would have
so it's not quite the same thing IMHO.

		thank you

		--- tony