Subject: [NSIS] NATFW NSLP Issue 66: Possibility of NOTIFY storms

From: Martin Stiemerling <[email-masked]>
Date: Sat, 18 Feb 2006 12:36:31 +0100

Hi all,

Elwyn has raised an issue at the last IETF meeting about the  
possibility of notification storms. See also issue 66 in the issue  
tracker at https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue66.

The issue has been described with pictures in the slide set shown at  
the last NSIS session in Vancouver (IETF-64):
http://www.stiemerling.org/ietf/ietf64/ietf64_nsis_natfw_nslp_v1.ppt

Short summary of this issue:
- A given NATFW NSLP forwarder (NF1) has installed NATFW stated for  
many flows
- NF2 is a upstream forwarded of NF1
- NF2 fails in operation and drops out (for whatever reason)

+------+        +------+        +------+
|      |        |      |        |      |
|  NIs |========|  NF1 |--------|  NF2 |---->
|      |        |      |        |      |
+------+        +------+        +------+

                         <~~~~~~~~ "Storm"

In the case NF2 is shut down/drops out, but is still able to generate  
NATFW NSLP messages, NF1 will receive, possibly, as many NOTIFY  
messages as session are installed between NF1 and NF2. This is what  
Elwyn calls a "notification storm".

Things to know about the "relationship" of NF1 and NF2: The NATFW  
NSLP requires using the C-MODE of the NTLP. The C-MODE offers  
reliable, congestion controlled, transport of NTLP and NSLP messages  
between two adjacent peers. Further, NATFW NSLP MAY send NOTIFY  
messages but the MUST not send them, i.e., NSLP nodes can send them  
but the do not need to send them.

My conclusions about this issue, which has partially been discussed  
with Robert and Andrew at the last meeting:
Yes, there is a risk that a node is generating many NOTIFY messages  
upon an error condition
(either node failure or an upstream link is going down). But there  
are several, already existing, measures to avoid a storm towards  
upstream nodes:
- Using the C-MODE: The transport protocol (currently TCP) takes care  
of some sort of rate limiting, since the receiver (here NF1) would  
not be able to read all NOTIFY messages at once. NF2 would be blocked  
by the TCP socket in sending new messages, unless NF1 has read more  
from its sockets (I do not go into TCP details for that).
- This could lead to a growing NSLP sending queue at NF2, which in  
turn gets stuck.  In the case, the node fails anyway, this queue will  
lengthen the shutdown process or the queue will be flushed by the  
shutdown process.
- NF2 does not need to send all NOTIFY messages, due to the fact,  
that NOTIFY MAY be send. Therefore, in such an error condition, NF  
can refrain from sending so many NOTIFY messages (see also below for  
the countermeasure section)

Countermeasure:
A good way to avoid a NF generating many NOTIFY messages is to not  
generate these messages ;-) Instead of generating these messages, the  
NF can solely close the TCP connection (here NF2 is closing the  
connection) and does not need to send as many NOTIFY messages as  
sessions. NF1 must interpret the closing of the TCP connection as  
NOTIFY messages for all the associated sessions.

This behaviour has not yet been described in the draft, but if  
accepted, it would go in an applicability statement on how to treat  
this case.

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis