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

From: "May, Howard" <[email-masked]>
Date: Mon, 7 Oct 2002 14:55:48 +0100

Brian,
 
> 
> Howard,
> 
> As you seem to have a problem with this, here is another reason
> for 2 out of 3, (rather than the first BSN) and a general problem
> regarding BSN treatment.  Consider the following:
[hmay] Let me reassure you I would support the 'conversion' argument if consensus was reached by the authors that this was an appropriate argument. 

> 
> An M2PA link aligns and goes into service.  Several data packets
> get stuck in the network resulting in link failure (and LSOS is sent
> and received successfully on stream 0).  The link realigns and goes
> back into service (using stream 0).  The "stuck" packets from the
> previous in-service are now delivered.
[hmay] The scenario you have described prompts the following one:

Link comes in service for the first time
Transmit Message (fsn=1, bsn=0)
Transmit Message (fsn=2, bsn=0)
...
T7 Expires Fail Link
Link comes in service for the second time
Receive Message (fsn=0, bsn=1) - invalid BSN
Receive Message (fsn=0, bsn=2) - invalid BSN
Fail link.

> 
> How is the receiver of the MSUs to tell the difference between MSUs
> belonging the old in-service session and MSUs belonging to the new
> in-service session?  By resetting the FSN/BSN when a link goes into
> service?  Then the link will fail on the first abormal BSN unless
> the 2 out of 3 is used.
[hmay] Agreed.  But if we want to protect against that then why not also the scenario I have described?

> 
> As stuck packets are common in the network and SCTP will faithfully
> deliver them late, this situation must be accommodated.
[hmay] If this argument is accepted and what I have presented above is correct then we must  accommodate not only 2/3 but n/m.

That said I want to question the likelihood of this scenario being encountered.  Given stream 0 and 1 are both using the same SCTP Path they are both prone to the same IP conditions.  For the process of link alignment (including proving) to occur without problem while the User Data message continues to fail to be delivered seems improbable.  If we argue it does occur then surely it is quite probable that it is blocking other User Data messages that are held in the RX buffer.  These will then also be received by M2PA leading to us failing the link due to 2/3.

Howard

> 
> --brian
> 
> May, Howard wrote:                                (Mon, 07 
> Oct 2002 09:57:15)
> > Anshoo,
> > 
> > Brian has suggested a requirement that would be a reason 
> for preserving the
> > 2/3 procedure.  My understanding is M2PA may be used not to 
> offer MTP2
> > services directly to an MTP2 User but rather convert 
> existing MTP2 messages
> > into M2PA messages.  Preserving the  2/3 procedure supports 
> transparent
> > copying of the MTP2 SNs into M2PA SNs.
> > 
> > It is not clear to me at the moment whether this is an 
> appropriate reason
> > for deciding M2PA Procedures.  I am concerned that  we are 
> introducing new
> > requirements to M2PA that have not been considered during 
> the rest of the
> > design process.  Perhaps the  Authors could comment on this?
> > 
> > Howard
> > 
> 
> -- 
> 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: Mon, 7 Oct 2002 14:12:36 -0600

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.