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