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

From: "May, Howard" <[email-masked]>
Date: Thu, 3 Oct 2002 10:52:42 +0100

Tolga,

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: 30 September 2002 15:57
> To: [email-masked]
> Subject: RE: [Sigtran] M2PA v6: Two Out of Three Valid BSN
> 
> 
> Anshoo,
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > [email-masked]
> > Sent: Monday, September 30, 2002 9:28 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [Sigtran] M2PA v6: Two Out of Three Valid BSN
> >
> >
> >
> >
> >
> > Hi Brian,
> >
> > Checksum failiure can cause any of the fields in the Message to
> > be corrupt,
> >  then why is the special consideration being given to BSN.
> > The two out of three BSN scheme would have been suitable, had we
> > been taking
> > into the consideration the FSN/BSN values in the Link Status
> > Messages as well.
> > Since that is not the case, I am not sure how we would be
> > deriving any benefit
> > from this scheme.
> [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.
> > 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.  

Cheers

> >
> > Regards
> > Anshoo.
> >
> >
> >
> >
> > "Brian F. G. Bidulock" <[email-masked]> on 09/30/2002 
> 02:58:43 PM
> >
> > Please respond to [email-masked]
> >
> > To:   Anshoo Sharma/HSS@HSS
> > cc:   [email-masked]
> >
> > Subject:  Re: [Sigtran] M2PA v6: Two Out of Three Valid BSN
> >
> >
> >
> >
> > Anshoo,
> >
> > A bit error which is not caught by the checksum algorithm.
> >
> > --brian
> >
> > [email-masked] wrote:
> > (Mon, 30 Sep 2002 11:36:37)
> > >
> > >
> > >
> > > Hi Tolga,
> > >
> > > Since SCTP provides a reliable and sequenced service on a 
> single stream,
> > > the Sequence Numbers should not fall out of order as long as
> > > both Peers are functioning correctly. Hence, in case the
> > Sequence Numbers
> > > do fall out of order, the Link should be brought into Out 
> Of Service.
> > >
> > > Can you please exemplify a scenario where the sequence numbers
> > can fall out of
> > > order?
> > >
> > > Regards
> > > Anshoo.
> > >
> > > > > Since FSN/BSN in the Link Status Messages are being ignored,
> > > > > FSN/BSN that need to be processed are only in the User Data
> > > > > Messages (actual
> > > > > data and zero data),
> > > > > These would all be on a Single Stream and hence should
> > never fall out of
> > > > > sequence.
> > > > [TOLGA] If your argument is that those messages won't 
> get ever out of
> > > > sequence, then is it ever possible that two messages on a
> > wire (for MTP2
> > > > case) can get out of sequence?
> > > > Maybe it should be considered that MTP2 has checksum of 16
> > bits whereas SCTP
> > > > has checksum of 32 bits.
> > > > > Then why do we have the Two out of Three flexibility for BSN.
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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: [email-masked]
Date: Thu, 3 Oct 2002 17:56:16 +0530

Hi,

-----Original Message-----
From: "May, Howard" <[email-masked]>
To: <[email-masked]>
Cc: "Tolga Asveren" <[email-masked]>
Sent: Thursday, October 03, 2002 3:22 PM
Subject: RE: [Sigtran] M2PA v6: Two Out of Three Valid BSN

Tolga,

> 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.
> are detectable with checksum, to make the procedure in Q.703
[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.
[Anshoo] Even I would suggest the same. Since there seems to be no other reason
besides covering implementation errors, can we please remove this procedure from
the Draft.

Regards
Anshoo.

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus.

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 3 Oct 2002 09:25:22 -0400

Howard,

> [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)
> [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 
[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

---

From: "May, Howard" <[email-masked]>
Date: Thu, 3 Oct 2002 15:33:54 +0100

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 :))

H

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 3 Oct 2002 10:54:13 -0400

Howard,

> From: May, Howard [mailto:[email-masked]]
> Sent: Thursday, October 03, 2002 10:34 AM
> To: [email-masked]
> Cc: Tolga Asveren
> 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.

---

From: "May, Howard" <[email-masked]>
Date: Thu, 3 Oct 2002 17:10:36 +0100

Tolga,
> 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?

Based on what is said so far I vote for failing the link on the first erroneous BSN.

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 3 Oct 2002 13:03:37 -0400

Howard,

> Sent: Thursday, October 03, 2002 12:11 PM
> To: [email-masked]
> Cc: Tolga Asveren
> 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.

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 4 Oct 2002 10:41:04 -0400

Howard,

> Sent: Friday, October 04, 2002 10:13 AM
> To: [email-masked]
> 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?
[TOLGA] What I explained till now is just a guess to explain the reason
behind that procedure in MTP2. If that is true, and if 32 bit checksum is
good enough, I wouldn't feel uncomfortable with that change.
> Howard
> > > > > > [TOLGA] I am not sure for the real reason, why this 
> procedure 
> > > > > > exists in
> > > > > > implementation of the protocol, this is quite odd 
> (but maybe 
> > > > > > this is the
> > > > > > case)
> > > > > > Such a procedure might be usefull, not to detect 
> the link as 
> > > > > > faulty, because
> > > > > > BSN value caused by bit error- not , unless there 
> is another 
> > > > > > bit error,

---

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Mon, 7 Oct 2002 13:29:33 +0200

Brian,

as stated below, the first figure is from the m2pa draft, therefore MTP3 means MTP3 functionality (including a point code)

second figure as stated below, my interpretation of your "direct conversion"!
If my interpretation is wrong, please provide the correct one.

If you prefer to not show the nodal interworking function (NIF), it's also fine for my, but you definitly have no MTP3 functionality in the second figure (in consequence also no point code)! The NIF only passes messages (LSSUs, MSU's) back and forth, without having to cope with e.g. retransmission. 

greetings

HannsJuergen

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]]
Gesendet: Montag, 7. Oktober 2002 13:15
An: Schwarzbauer Hanns Juergen
Cc: 'May, Howard'; [email-masked]; [email-masked];
[email-masked]
Betreff: Re: [Sigtran] M2PA v6: Two Out of Three Valid BSN

Hanns,

How is MTP3 in the first figure and NIF in the
second figure different?

--brian

Schwarzbauer Hanns Juergen wrote:      (Mon, 07 Oct 2002 12:53:18)
> Dear all,
> 
> figure 2 from the m2pa v006 draft shows what m2pa is heading for:                                                                        
>                                                                           
>                                                                           
>     ********  SS7   ***************   IP   ********                       
>     * SEP  *--------*     SG      *--------* IPSP *                       
>     ********        ***************        ********                       
>                                                                           
>     +------+                               +------+                       
>     | TCAP |                               | TCAP |                       
>     +------+                               +------+                       
>     | SCCP |                               | SCCP |                       
>     +------+        +-------------+        +------+                       
>     | MTP3 |        |    MTP3     |        | MTP3 |                       
>     +------+        +------+------+        +------+                       
>     | MTP2 |        | MTP2 | M2PA |        | M2PA |                       
>     +------+        +------+------+        +------+                       
>     | MTP1 |        | MTP1 | SCTP |        | SCTP |                       
>     |      |        |      +------+        +------+                       
>     |      |        |      | IP   |        | IP   |                       
>     +------+        +------+------+        +------+                       
>                                                                           
>                Figure 2 from m2pa-06 draft
> 
> The figure below shows my understanding of "direct conversion"                                
>                                                                           
>     ******** SS7 ***************  IP *************** SS7 *******          
>     * SEP  *-----*     SG      *-----*     SG      *----*  SEP *          
>     ********     ***************     ***************    ********          
>     +------+                                            +------+          
>     | TCAP |                                            | TCAP |          
>     +------+                                            +------+          
>     | SCCP |                                            | SCCP |          
>     +------+                                            +------+          
>     | MTP3 |                                            | MTP3 |          
>     +------+                                            +------+          
>     | MTP2 |                                            | MTP2 |          
>     |      |     +-------------+     +-------------+    |      |          
>     |      |     |     NIF     |     |     NIF     |    |      |          
>     |      |     +------+------+     +------+------+    |      |          
>     |      |     |mtp2* | M2PA |     | M2PA |mtp2* |    |      |          
>     +------+     +------+------+     +------+------+    +------+          
>     | MTP1 |     | MTP1 | SCTP |     | SCTP | MTP1 |    | MTP1 |          
>     |      |     |      +------+     +------|      |    |      |          
>     |      |     |      | IP   |     | IP   |      |    |      |          
>     +------+     +------+------+     +------+------+    +------+          
>    mtp2*: only a very basic functionality from MTP 2                      
>    NIF:   Nodal Interworking function                                     
> 

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

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 8 Oct 2002 09:11:50 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, October 07, 2002 4:11 PM
> To: Jakob Heitz
> Cc: [email-masked]
> Jacob,
> Jacob Heitz wrote:                                     (Mon, 
> 07 Oct 2002 07:33:57)
> > When the M2PA link fails, close the SCTP association
> > and start a new association.
> > 
> 
> Yes, we used to do that, but it is rather drastic for several 
> reasons and
> might not accomplish what is expected.
> 
> First off, if dropping the association and restarting it 
> actually results
> in a new association, the congestion window will have closed and the
> association will be back in slow start.  A full alignment 
> procedure intended
> to take the association out of slow start will be required.
[TOLGA] Not 100% related with this thread but still a comment: In the
scenario described, where some messages are lost/delayed (T3 expires), cwnd
will shrink to MTU, even if association is not dropped. There are a lot of
cases, where cwnd might shrink without association being dropped. I believe
cwnd shrinking problem should be addressed somehow. By the way, why do we
think that this is a problem just for M2PA?
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: [email-masked]
Date: Mon, 7 Oct 2002 09:48:38 -0400

I question whether it is correct or appropriate to use the 2 out of 3 BSNs 
to solve what is essentially a buffer clearing issue. Normally after an 
MTP-2 link goes out of service and comes back into service the buffers are 
cleared. Even if one did use the 2 out of 3 BSNs to handle stuck packets 
it seems that if there is more than one stuck packet in the network we 
would still trip the 2 out of 3 BSN error detection. So, I think it is 
worth doing some more thinking on a mechanism for flushing buffers. 

Does the 2 out of 3 BSNs extend to 2 out of 3 bad FIBs?

Regards,

Seamus

"Brian F. G. Bidulock" <[email-masked]>
Sent by: [email-masked]
 10/07/2002 08:39 AM
 Please respond to bidulock

        To:     "May, Howard" <[email-masked]>
        cc:     [email-masked], [email-masked], [email-masked]
        Subject:        Re: [Sigtran] M2PA v6: Two Out of Three Valid BSN

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:

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.

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.

As stuck packets are common in the network and SCTP will faithfully
deliver them late, this situation must be accomodated.

--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
>