NANC 368

Outbound Flow Control

Origination Date :10/18/2002



Business Need:

During the Oct ’02 LNPAWG meeting, a discussion took place surrounding outbound flow control, and the merits of changing the flow control of messages from the receiving end to the sending end.  The current implementation of flow control between the NPAC and SOA/LSMS systems is completely determined by the receiving end of the CMIP connection.  This approach works, but it allows the large buffers between the sender and the receiver to act as a queue when the receiver can’t keep up with the sender.  These buffers allow for, in some cases, hundreds of messages to be backed up between the sender and the receiver before the sender gets a congestion indication.  In some cases, the queue that builds up cannot be processed in 5 minutes, thereby causing departure times to expire and the association to be aborted.

Another negative impact of the current flow control approach is the lack of ability to correctly prioritize outbound messages.  In the LNP systems, the sender, not the OSI stack, manage the priority that is assigned to a message.  Once a large backlog of low priority messages is built up, any subsequent high priority message must wait for all those messages ahead of it in the queue.  If the sender carefully manages the outbound queue, then high priority messages won’t have to wait as long to be sent by the receiving system.

Refer to the Oct ’02 LNPAWG meeting minutes for a full recap of the discussion items regarding this topic.

Final Resolution:

Pure Backwards Compatible:  YES

By implementing Outbound Flow Control (OBFC) on the sender system, the various buffers in the OSI stack would not fill up as done currently.  It would be the sender’s responsibility to detect that (n) number of messages have been sent without receiving a response.  In this case, the sender should stop sending until the number of non-responsive messages drops below a threshold (t).  If implemented on both ends (NPAC and SP), outbound flow control would prevent congestion because neither side would fill the buffers between the 2 systems.

Oct ’02 LNPAWG, OBFC could be implemented at the NPAC without impacting SP systems.  SPs are not required to implement this concurrently with NPAC.

Nov ‘02 LNPAWG, OBFC would be set up for every connection to the NPAC.  Message processing speed and message prioritization for each SP is independent of other SPs (just like today, where one slow SP doesn't mean others are directly affected), regardless of each SP's setting.  Move to accepted.  Start working on detailed requirements.

Feb ’03 APT, need to consider how the implementation of OBFC would affect SLRs 2, 3, 4, and 5.

Implemented in FRS 3.3.0a and IIS 3.3.0a.

Related Release:

Implemented in FRS 3.3.0a and IIS 3.3.0a.

Status: Implemented