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

I greatly appreciate the input your are giving from your broader
perspective. We'd be foolish to ignore your advice. That's why I
asked about routing protocol specs: I have no experience with them
(lately), so I have no idea how they address issues such as queuing
delay. Presumably people working on routing protocols have discussed
these issues to death, *and* with tons of experience to inform them.
I can't think of any differences that makes VRRP unique, so I was
hoping we could leverage the wisdom already enshrined in more
mature specs.

Yes, I agree that a new mechanism is not required at this time.
-don

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Mark Handley
> Sent: Tuesday, November 04, 2008 9:41 AM
> To: don provan
> Cc: Stephen Nadas; TSV Dir; vrrp
> Subject: Re: [VRRP] 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