RE: Questions on draft-ietf-vrrp-ipv4-timers-02.txt

OK, please excuse me for doubting you, but I'm
afraid this response has kinda supported my fears.
The issues you're talking about -- and I note
turning on logging as a specific case -- should
have the effect of delaying the processing of each
individual packet including the one that should
have prevented the flap. That suggests that the
over all timeout is too small, *not* that too few
packets were transmitted.
 
But since you've obviously investigated this way
beyond anything I've done, perhaps you already have
the more detailed data that would convince me.
First, are you sure your tests were checking the
number of packets transmitted without changing the
length of the timeout. And, second, were you able
to confirm that flapping was caused by packets that
were lost and not by packets that were delayed.
 
I'm not arguing against being able to configure
the number of retransmissions, as long as everyone
agrees VRRP needs it. I just want to make sure we
understand (and the spec expresses) what this really
accomplishes. In my experience (which was, admittedly,
limited to my implementation), I found that limits
to the timeout were *always* caused by packet latency,
never, ever by packet loss. I have seen problems
caused by packet loss, but with normal intervals
as much as with small ones.
 
On another note, I think we agree that the lowest,
reliable timeout period depends on many factors
in the implementation and in the environment; it
isn't something that can be defined by the
protocol. I wonder if, at these rates, we can or
should add some rules for "flapping recovery."
When a backup inappropriate takes over the VR,
the correct master knows it. I wonder if we should
add something for a master to announce that it was
inappropriately replaced and set a higher timeout
to avoid future mistakes? Just a thought off the
top of my head....
 
-don

-----Original Message-----
From: Hott, Robert W CIV B35-Branch [mailto:[email protected]]
Sent: Wednesday, March 29, 2006 3:49 AM
To: Don Provan; Steve Bates; [email protected]
Cc: Odonoghue, Karen F CIV B35-Branch
Subject: RE: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt


Don,
    What I have seen in doing some testing with faster advertisement
intervals and more/fewer advertisements leads me to a conclusion
with may or may not be correct. I will offer my observation though.
 
    I have done testing of various techniques for providing
survivable network environments. I have looked at standards-based
solutions as well as proprietary enhancements. I have looked for
solutions that can detect failures and recover in less than 1 second.
 
    When I have tested VRRP using timer settings which adhere
to the standard, I have seen very little problems. I can certainly
introduce a load on the network with can cause packets to be
dropped, but for the most part, devices are capable of transmitting
and receiving an advertisement within the 3 second window.
 
    When I have tested VRRP, and other protocols, using timer
settings which permit sub-second failovers, there have been
instances where flapping has occurred and I did not need to
introduce a load on the network. This observation leads me to
believe that the issue is in the implementation of the particular
survivability technology. With some technologies, it appeared
that the protocol was activated based upon a timer and that
the protocol would not perform faster than a certain rate,
regardless of the settings. In these cases, if the rate and
number of messages missed were configured in such a way,
flapping would occur! I have also seen cases where the
load on the network APPEARS to slow down the handling of
the advertisements (i.e., not high enough priority process),
and flapping has occurred. In some cases, enabling logging
has been enough to cause flapping to occur, when using
sub-second intervals. Please note that I have not always been
able to test with a particular vendor's top-of-the-line
device. That is one reason why I think it is important to test these
technologies with devices, and images, that are planned for
a particular computing environment.
 
    I hope this has cast a little light on my interest in sub-second
capability and a little on what I have seen when looking at
various technologies and implementations.
 
Bob Hott
 

-----Original Message-----
From: Don Provan [mailto:[email protected]]
Sent: Tuesday, March 28, 2006 18:33
To: Hott, Robert W CIV B35-Branch; 'Steve Bates'; [email protected]
Cc: Odonoghue, Karen F CIV B35-Branch
Subject: RE: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt


First, I just want to mention that I think Bob has the
answer to the "which time to use" question spot on. I
recall that the wording in the spec wasn't quite right
last time I read it (and it sounds like Bob agrees it
needs a little work), but the description Bob has here
in this e-mail agrees exactly with both my ponderings
and my experience on what can go wrong and what the
rules should be to make sure they don't.
 
But my purpose for writing this is to explore another
question, one that comes up over and over and I've
never felt satisfied about. Bob says, "As you move into lower 
time intervals between Advertisements, missing 3 Advertisements is very 
likely and flapping occurs." 
 
Now I *don't* have experience in actual networks where
these lower tolerances are required, so I ask this
without having an opinion, but is it in fact true that
that per packet failure rate increases in cases where
a shorter failover time is desired? What is the
characteristic of these environments that makes
the standard of 3 packets less reliable that in an
environment where a 3 second failover is acceptable?
It seems counter intuitive to me -- when you retransmit
faster, it causes a problem, and the solution to that
problem is to retransmit *even faster*? -- but, as I
say, it's probably just something about the target
application that I don't yet understand.
 
Or is this just because people have always wanted to
be able to configure the number of retransmissions, so
now's the chance? I admit to being a little concerned
with depending on only 3 retransmissions regardless of
the rate, but I've never actually been able to justify
any reason why three packets wouldn't be enough.
 
-don

_______________________________________________
vrrp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp