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

[WG member hat on]

Mark,

Doesn't this apply to all routing protocols? AFAIK, the general
recommendation or practice is should be using netctrl queues for the
control traffic such as routing protocols and that should be documented
in some BCP independently. For example, does the OSPF spec
suggest/recommend how to handle congestion?

Regards
Mukesh

-----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