Re: Congestion questions and draft-ietf-vrrp-unified-spec-02.txt

I think primarily it's a problem with subsecond timeouts.  These bring
the possible timeout range below typical queuing delays at congested
routers, whereas before the default delays were long enough to be
fairly robust.

I've not been involved with VRRP, so feel free to ignore my advice.
However, I think that the simplest solution is to simply discuss the
potential issue in the spec, and leave it to vendors to decide how to
mitigate the potential problem.

Detecting thrashing and backing off would probably be beneficial, but
it's not worth delaying this spec over.  However the WG might think
whether this is something worth considering for an enhancement
document.

 - Mark

On Tue, Nov 4, 2008 at 5:30 PM, don provan <[email protected]> wrote:
> VRRP is operating as a routing protocol, and the queuing
> delay problem would seem universal to routing protocols.
> What do routing protocol specs say about this?
>
> Is this a problem only because of the subsecond changes?
> Or is it an issue with the existing VRRP spec and its minimum
> 3 second timeout? In the back of my mind, I've been thinking
> that the subsecond work was really just reducing the VRRP
> transmission rate limit so that the interval can be set low
> enough to be comparable with today's networks to what the 1
> second transmission rate was, vis-a-vis these same queuing
> issues in the networks available when VRRP was first published.
> The logic is that networks are a thousand times faster today,
> so a transmission rate of 1ms should be just as pedestrian
> today as a rate of 1 second was when VRRPv1 was invented.
>
> At the same time, all the points raised here seem reasonable,
> and I have to objection to the spec addressing them as people
> see fit. But as far as I know, no one has much experience with
> subsecond VRRP in real world environments, so I'm not sure what
> concrete suggestions we can make about it.
>
> I'd like to avoid complicating the spec with ways to deal
> with high transmission rates in heavily congested networks
> when we don't really know whether or not the *real* answer
> is "don't run high transmission rates in heavily congested
> networks." If anything, I'd say we should beef up the
> protocol's ability to deal with *any* intermittent connectivity
> failures rather than one that specifically deals only with
> the failures caused by unexpected queuing delays. For example:
>
>> It might also be possible to
>> specify that the master should automatically backoff its
>> Advertisement_Interval value when it observes such thrashing.
>
> This only deals only with queuing delays. If, instead, we
> taught backups to increase their timeout when they detected
> themselves thrashing, we'd handle the problem caused by queuing
> delay *and* problems caused by high packet loss rates with the
> same mechanism. But the real question is whether the protocol
> should deal with these issues at all, or whether it's
> sufficient for the network administrator to.
>
> -don
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]]On Behalf Of
>> Stephen Nadas
>> Sent: Tuesday, November 04, 2008 8:07 AM
>> To: Mark Handley; TSV Dir; [email protected]
>> Subject: [VRRP] Congestion questions and
>> draft-ietf-vrrp-unified-spec-02.txt
>>
>>
>> When Mark Handley reviewed
>> draft-ietf-vrrp-unified-spec-02.txt, one area
>> the WG should (imho) discuss  is excerpted below.
>>
>> This thread is started to discuss the below scenario.  Please
>> comment.
>>
>> Thanks,
>> Steve
>>
>> > From a transport area point of view, the main things we're
>> > looking for are whether the protocol will be well-behaved,
>> > especially from the point of view of congestion control.
>> > VRRP does not perform any form of congestion control, but as
>> > it is purely a link-local protocol, configured by a network
>> > operator to provide redundancy between two routers on the
>> > same LAN segment, this is not really an issue.  One presumes
>> > that a network operator choosing sub-second advertisement
>> > intervals knows what he or she is doing, and knows
>> > appropriate rates for their local circumstances.  Routers
>> > provide many ways to shoot yourself in the foot, and this one
>> > doesn't seem worth of concern.
>> >
>> > However, the draft does have a weakness when it comes to congestion.
>> > It does not provide any guidance to router vendors as to
>> > whether VRRP packets should receive priority treatment when
>> > being transmitted.  The potentially problematic situation
>> > occurs when a router is delivering more packets onto the LAN
>> > than can be accomodated, and so a queue builds up in the
>> > router.  Typical default queuing delays tend to be some
>> > generic wide-area RTT (so that a delay-bandwidth product of
>> > packets can be queued).  Thus packets being transmitted onto
>> > the VRRP-protected LAN could see perhaps 100ms or more of
>> > queuing delay.
>> > If VRRP packets enter such a queue, and the smallest VRRP
>> > Advertisement_Interval is configured, the
>> > Master_Down_Interval will be between 30 and 40ms.  Thus
>> > normal queuing delays might cause a VRRP backup to conclude
>> > that the master is down, and therefore promote itself to
>> > master.  Very shortly afterwards, the delayed VRRP packets
>> > from the master would arrive, causing a switch back to
>> backup status.
>> > However this process can repeat many times per second,
>> > causing significant disruption to traffic.
>> >
>> > My feeling is that, if possible, VRRP packets should be
>> > priority-forwarded onto the LAN, mitigating this problem.
>> > However, it's not clear this is always possible.  At the
>> > least, the draft ought to comment on this possible scenario
>> > and the risks of very low Advertisement_Interval values in
>> > the presence of congestion.
>> >
>> > It would presumably be possible for a VRRP master to observe
>> > such a situation is occurring frequently.  Under such
>> > circumstances, at the least a good implementation should log
>> > that there is a problem.  It might also be possible to
>> > specify that the master should automatically backoff its
>> > Advertisement_Interval value when it observes such thrashing.
>> >  I'll leave it to the VRRP authors to think over whether that
>> > might be desirable or might have unintended consequences.  I
>> > think the draft can be progressed without any such adaptive
>> > mechanism, but the authors may wish to think about it anyway,
>> > as it might improve VRRP's robustness.
>> >
>> _______________________________________________
>> vrrp mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/vrrp
>
_______________________________________________
vrrp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp