Subject: RE: [Sigtran] M2PA v6: Two Out of Three Valid BSN

From: "May, Howard" <[email-masked]>
Date: Tue, 8 Oct 2002 09:21:19 +0100

Hi Brian,

>
> Howard,
> 
> May, Howard wrote:                          (Mon, 07 Oct 2002 
> 14:55:48)
> 
> > That said I want to question the likelihood of this scenario being
> > encountered.
> 
> The point is not that is it likely, the point is that it is possible.
> See the T7 thread.

[hmay] Can you make it more clear to me what you are saying.  Are you suggesting that we should protect against any possible scenario irrespective of the improbability of it happening.  In light of the uncontested scenario both Seamus and myself presented this argument does not support the 2/3 procedure.

> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 8 Oct 2002 03:08:33 -0600

Howard,

Failing a link on the first FSN or BSN means that any data "stuck" from
a previous in-service session of the link will continue to fail the link.
That data can be "stuck" while the link can go out-of-service and realign
is not so much of a corner case as one might think.  Router often use
queue overflow as a mechanism for determining which packets to drop under
congestion.  Link status packets are quite small by comparison to big
TCAP messages or IAMs.  That, during congestion, Link status packets slip
through while Data packets are repetitively lost is not so rare a concept.

I only see several things to do here:

  a) Provide a procedure which ignores "stuck" packets.
	
     The range of the sequence number in M2PA allows for quite accurate
     detection of bogus FSN and BSN.  There is a 3 x 10^-8 probability of
     mis-detecting the FSN/BSN error and repeating a previous MSU.  Therefore,
     there is really no reason to fail the link on either an unreasonable FSN
     or an unreasonable BSN.  These could merely be discarded.  (In constrast,
     Q.703 has a 1/128 chance of misdetecting an incorrect BSN--FSNs are
     handled through negative acknowledgements.) (By the way, this is also the
     case for MTP3b which has larger sequence numbers, but MTP3b still
     maintains the 2/3 BSN procedure).

     The current draft says to drop the link on the first unexpecpted FSN
     and 2/3 on the BSN.

  b) Drop the link between link alignments and ensure that SCTP does
     not "restart" the link.

     I don't know that keeping the SCTP from restarting the association can be
     guaranteed, even with orderly shutdown (if the new IG shutdown timer
     expires, the ABORT could go undetected and the peer might restart
     anyway.)

     Also, we considered that it was preferrable from a number of other
     standpoints to keep the association hot when the link is out of service.

  c) Provide a procedure to "unstick" packets.

     An example of this is PR-SCTP.  With PR-SCTP, M2PA could request that
     all outstanding Data packets to the peer be expired with a Forward TSN.
     That way, if these packets are delivered late, the peer SCTP will ignore
     them.

My preference would be to use (c) and make both FSN and BSN an N out of M
procedure (a) to handle the odd stuck packet that the Forward TSN did not
catch; and, in the absence of the implementation of PR-SCTP, recommend (b)
with (a) as a backup in the event that (b) fails and the peer SCTP restarts
the association and maintains some stuck data received just before the
restart (subsequent data will have the wrong TSN and be discarded).

Why do you think that MTP3b maintains the 2/3 BSN procedure when SSCOP
is incapable of missequencing just as is SCTP?

--brian

May, Howard wrote:                               (Tue, 08 Oct 2002 09:21:19)
> [hmay] Can you make it more clear to me what you are saying.  Are you
> suggesting that we should protect against any possible scenario irrespective
> of the improbability of it happening.  In light of the uncontested scenario
> both Seamus and myself presented this argument does not support the 2/3
> procedure.
> 
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> >