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

From: "May, Howard" <[email-masked]>
Date: Fri, 4 Oct 2002 15:13:23 +0100

Tolga,

I'm not quite sure I followed all your arguments but suspect we might have some level of agreement.

Would you at this stage support changing the procedure to failing the link on the first occurrence of an invalid BSN?

Regards

Howard

> 
> Howard,
> 
> > -----Original Message-----
> > From: May, Howard [mailto:[email-masked]]
> > Sent: Thursday, October 03, 2002 12:11 PM
> > To: [email-masked]
> > Cc: Tolga Asveren
> > Subject: RE: [Sigtran] M2PA v6: Two Out of Three Valid BSN
> > 
> > 
> > Tolga,
> > > 
> > > Howard,
> > > 
> > > > 
> > > > Tolga & Brian
> > > > 
> > > > The only reason I can find identified for the 2/3 procedure 
> > > > is Bit error not picked up by the checksum.  Brian you 
> > > > highlighted this a few emails ago.  I have been unable to 
> > > > find any comments on the probability of this happening.  Am I 
> > > > right in that it would require multiple bit corruption (given 
> > > > some kind of corruption is occurring I guess it is not 
> > > > unlikely we get multiple bits corrupted).  Is the SCTP 
> > > > checksum ineffective against such corruptions?  (Ooohh 
> > > > perhaps we could have the SCTP checksum changed a 
> second time :))
> > > [TOLGA] I think, whatever error detection mechanism one 
> > uses, there is
> > > always a possibility that a message is corrupted but not 
> detected as
> > > corrupted. SCTP has checksum of 32 bits, and MTP2 has 
> > > checksum of 16 bits,
> > > this may be considered.
> > > If we call it 2/3 procedure, I think it is easy to mix two 
> > > different things.
> > > I believe the procedure itself (to assume the link as 
> > faulty based on
> > > unexpected BSN value) is to handle the cases, where peer is 
> > > really filling
> > > BSN values wrong. But I guess, the reason, why there should 
> > > be 2 messages
> > > with unexpected BSN values out of 3 is, to prevent a false 
> > faulty link
> > > detection, because of a undetected bit error. 
> > [hmay] 
> > If we are guarding against just the peer using wrong values 
> > then let us fail it on the first erroneous value.  If we are 
> > also guarding against undetected bit errors then who made the 
> > decision that we would only allow for a single corrupted 
> > message rather than two or three simultaneous ones?
> [TOLGA]The purpose is not to detect against undetected bit 
> errors. As I
> tried to explain, handling bit errors and trying to avoid 
> false unexpected
> BSN detection because of bit error are two different things. 
> And probably
> the idea behind 2 out of 3 is, if the probability of BSN beng 
> corrupted and
> not detected is X, with that method probability of false 
> unexpected BSN
> detetction becomes X^2 (still not zero of course), and probably people
> thought X^2 is low enough to be ignored. Because SCTP has 
> checksum of 32
> bits, maybe even X is good enough for it.
> > 
> > Based on what is said so far I vote for failing the link on 
> > the first erroneous BSN.
> > 
> > > > 
> > > > H 
> > > > 
> > > > > 
> > > > > 
> > > > > Howard,
> > > > > 
> > > > > > > [TOLGA] Why do you think this procedure exists for 
> > MTP2? Your 
> > > > > > > argument is
> > > > > > > that there won't be any missequencing in SCTP, but 
> > similarly 
> > > > > > > one can argue,
> > > > > > > there won't be any misseqiencing on a wire(for 
> MTP2) either.
> > > > > > [hmay] Is it not the case that in MTP2 there is more scope 
> > > > > > for misequenced BSNs on account of prioritised Link Status 
> > > > > > messages and the use of FISUs.  Certainly misequencing on 
> > > > > > account of this is an implementation specific issue, but in 
> > > > > > the days when the processing able to be performed during 
> > > > > > single FISU emmission time was more limited, this kind of 
> > > > > > issue may be  more common and thus 2 out of 3 safeguard 
> > > > > more relevant.
> > > > > [TOLGA] I am not sure for the real reason, why this procedure 
> > > > > exists in
> > > > > MTP2. If it is to avoid some problems, which might arise 
> > > > > because of wrong
> > > > > implementation of the protocol, this is quite odd (but maybe 
> > > > > this is the
> > > > > case)
> > > > > > > > If I am missing anything here, please elaborate.
> > > > > > > [TOLGA] At the beginning I also thought on bit 
> errors, but 
> > > > > > > another reason,
> > > > > > > why BSN does not have an expected value might be, 
> that peer 
> > > > > > > M2PA (or MTP2 in
> > > > > > > case of Q.703)  fills it wrong. I tend to think, 
> > that is the 
> > > > > > > real reason for
> > > > > > > that procedure, because bit errors are handled as 
> described 
> > > > > > > in Q.703 10.2.
> > > > > > > (With the procedure defined in Q.703 5.3.1 it is 
> > possible to 
> > > > > > > detect some
> > > > > > > errors which are not detectable with checksum but I would 
> > > > > > > think, if there is
> > > > > > > really something wrong on the link, there would be 
> > enough bit 
> > > > > > > errors, which
> > > > > > > are detectable with checksum, to make the procedure 
> > in Q.703 
> > > > > > > 10.2 to work.)
> > > > > > [hmay] If (as I think you are suggesting) the 2 out of 3 
> > > > > > procedure is now only of significant value to 
> protect against 
> > > > > > M2PA implementation error, then without understanding why 
> > > > > > there is a specific risk of this error I don't 
> currently see 
> > > > > > why we should complicate the spec with the procedure.
> > > > > [TOLGA] I think, unless we are sure, why it is needed for 
> > > > > MTP2 case, it is
> > > > > hard to decide whether to include it or not, because only 
> > > > > like this, it can
> > > > > be decided, whether the same problem applies to M2PA 
> > case or not. 
> > > > > Such a procedure might be usefull, not to detect the link as 
> > > > > faulty, because
> > > > > of a wrong BSN value in the message caused  by a bit error, 
> > > > > which can't be
> > > > > detected by checksum. If the peer M2PA fills BSN values 
> > > > really wrong,
> > > > > following messages will also have unexpected BSN values, 
> > > > > otherwise -if wrong
> > > > > BSN value caused by bit error- not , unless there is another 
> > > > > bit error,
> > > > > undetectable by checksum.   
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > 
> > > > 
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> > 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 4 Oct 2002 09:05:34 -0600

Howard,

Leaving it at two out of three allows an MTP2 link to be converted
directly to an M2PA link.  Please leave it at 2 out of 3.

--brian

May, Howard wrote:                                 (Fri, 04 Oct 2002 15:13:23)
> Would you at this stage support changing the procedure to failing the link
> on the first occurrence of an invalid BSN?
> 
> Regards
> 
> Howard
> 

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/