Subject: [Sigtran] M2PA : LS messages on stream 0

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 22 Jul 2002 08:12:16 -0400

Amish,

(I changed the name of the thread)

> -----Original Message-----
> From: Amish Chana [mailto:[email-masked]]
> Sent: Sunday, July 21, 2002 1:23 PM
> To: [email-masked]
> Subject: RE: [Sigtran] M2PA list of comments on draft version 5 -
> multiple links on the s
>
>
> Tolga,
>
> >[TOLGA] If you think that SCTP blocks the delivery of link
> status message
> >by
> >sending it from the same stream like data, then you probably also think
> >that
> >this happens also with MTP2.
>
> I am referring to blocking at the SCTP receiver, if an earlier
> data message
> was overtaken or corrupted. SCTP will not deliver the link status
> message to
> M2PA until the data message is successfully received. If the MTP2
> receiver
> discards a MSU because it is corrupted, it does not discard or block the
> subsequent LSSU - it processes it!
[TOLGA] IMO, you are comparing two different things. SCTP corresponds to the
wire, which carries the messages in case of MTP2. But in that analogy, SCTP
is a perfect wire, which does not have any corruption. The corruption, which
might cause SCTP retransmissions is on the layer below, and does not have
any corresponding entity in the physicall wire case with MTP2.
>
> >What we need to do is to mimic MTP2 behavior.
> >It is not blocking, it is just simulating a link in IP domain and
> >preserving
> >sequence. If a link status message is received after a data message with
> >MTP2, the same should happen with M2PA.
>
> What is the advantage of mimicing MTP2 behaviour with regards to the
> sequencing between MSUs and Link status messages? What do you gain/loose?
[TOLGA] I think to behaeve as MTP2 is one of the main goals. SCTPs role in
M2PA is giving services provided by a physicall wire. Missequencing is not
possible on a physicall wire. So, it should be the same with M2PA. It is not
just comparing what you gain/loose. IMO, it is not just against the M2PA
concept but also against the general layering model.
>
> You are simply introducing unnecessary delays at the receiving
> end by using
> a single stream.
>
> BTW, please note that sending a
> >message from stream0 might further delay it, IP network does not
> care about
> >streamIDs.
>
> Yes, and sending all the messages on the same stream does not
> mean the link
> status message will be delivered any faster (it will just take
> much longer
> if a preceding message is lost).
[TOLGA] The importance thing is sequencing. You might send message1 from
stream1, message2 from stream0 and message3 from stream1 , and it is very
well possible that message1 and then message3 are delivered to M2PA on the
receiving end before message2. But if they are sent on the same stream, it
is sure that they will be delivered to the M2PA at the receiving end in the
same order.

4.1.7 of M2PA refers to Q.703, to justify use of stream0 for link status
messages. IMO, it is obvious that the corresponding section in Q.703 talks
about prioritizing when sending messages from MTP2 and processing received
messages in MTP2. So, this corresponds to the behavior of M2PA, when sending
and processing messages, not to the behavior of SCTP. Once M2PA sends a
message, sequence should be preserved, like on a physicall wire.
>
> A.
>
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: [email-masked]
Date: Tue, 23 Jul 2002 12:08:39 +0530

Hi all,

There is an issue with having two different streams for MSU and LSU in M2PA.
The issue relates to FSN and BSN sequencing that are being sent along with LSU
as well as MSU.
LSUs and MSUs are sent on different SCTP Streams and no guarantee on the order
of arrival at the Peer can be given.
This could cause the out of order arrival of FSN and BSN values at the Peer,
which in turn would lead
to rejecting of the current association according to M2PA Draftv5.

Here is a short example to illustrate this:

          A                        B
       +--------+                     +---------+
       |        |                     |         |
       |        +---------------------+         |
       +--------+                     +---------+

1) MSU with FSN values 1, 2, 3 and BSN value 0 are sent from A to B. The message
is received at B.
2) MSU with FSN value 1 and BSN value 3 is sent from B to A. The message is
received at A.
3) Some time elapses with no message from B, A now sends an INSERVICE LSU to B
with FSN as 3 and BSN as 1. This message is sent on Stream 0
    and is in transit on the Network.
4) B sends another MSU with FSN as 2 and BSN as 3. The message is received at A.
5) A sends another MSU with FSN as 4 and BSN as 2. The message is received at B.
6) The LSU that had been sent in (3) now reaches B and has both its FSN and BSN
values out of sync. According to the current draft the association should be
discarded.

I guess the above consideration was missed out while adding FSN and BSN to Dual
Stream M2PA.
Now either we should allow only a single stream for a link or else we should
explicitly define a mechanism for handling the above scenario.

Regards
Anshoo.

----- Original Message -----

Al Varney <[email-masked]> on 07/23/2002 08:44:16 AM

To:   [email-masked]

Subject:  RE: [Sigtran] M2PA : LS messages on stream 0

At 11:28 AM 7/22/02 -0400, Tolga Asveren wrote:
>And here an example where using stream0 for LS messages is not a good idea:
>(although in my opinion, to have a model where responsibilities of layers
>are not mixed is a more important argument)

    I don't believe there is a "right" answer to this particular issue --
either one works well, considering the inadequacy of STCP to exactly
emulate a "wire".  But since you are the one arguing "layer purity", I
think you need reconsider your argument ... see below.

>A was sending Data to B. Then it decides to send LS OOS, and it is delivered
>to the receiving M2PA before some Data messages, which were sent before LS
>OO. So, those messages, which have already reached receiving SCTP
>successfully won't be delivered to M2PA. So, after changeover they need to
>be retransmitted. If sequence was preserved -like in the case with a
>physicall wire-, there wouldn't be a need to retransmit those, because
>during changeover, B would inform A that it received those messages.

    But the exact same thing can happen with SS7 MTP2 -- if you respect the
protocol layering.  If A (MTP3 layer) sends "Data" to B, MTP2 will
typically place "Data" in the transmit buffer of the specified link.  If A
(MTP3 layer) then indicates "send LS OOS" for the same link, the MPT2
priority rules state that LS OOS will be sent IN FRONT OF the "Data"
message.  And thus "Data" will not be delivered to the far-end MTP3 -- nor
will those messages in the re-transmit buffer (or SCTP equivalent).  (This
presumes "Data" isn't in the process of being sent when the LS OOS
indication arrives at MTP2.)

    So if you look at it from the MTP3 layer rather than the wire itself
(Layer 1), you have the same potential out-of-order processing possible
with both SS7 and with M2PA using Stream 0 for LS messages.  SS7 does NOT
promise to deliver LSSUs and MSUs in the same order indicated by the
sending MTP3.

    I don't claim there aren't other arguments for a single-stream for all
M2PA data (simplicity of reading 1 stream vs. 2, for example).  I'm not
sure they are sufficient to remove the ability to "expedite" LS messages
using Stream 0.  (Presuming SCTP will send a new Stream 0 message before a
whole buffer full of Stream 1 messages, that is.)

Al Varney

---

From: [email-masked]
Date: Tue, 23 Jul 2002 19:22:41 +0530

Hi Jeff...

You are right, this method can be used as a work around for this problem.
What you have suggested, would render the FSN and BSN values in LSU useless.
The only useful purpose for them seems to be acknowledging MSUs, using the
INSERVICE Message,
and here too if the BSN does not suit the receiver it can be discarded.
Then why don't we just remove FSN and BSN entirely from LSU and add provision
for dummy acks on MSU stream itself.
This would ensure that we validate all the FSN/BSN values that are sent on the
Link.
Tom, what do you think?

Best Regards
Anshoo.

[email-masked] on 07/23/2002 06:53:43 PM

To:   Anshoo Sharma/HSS@HSS
cc:   [email-masked]

Hello Anshoo,

I have encountered several scenarios of out-of-sequence link status
messages during testing of my M2PA v5 implementation.

I addressed the problem in the following manor:

1) The FSN of a link status message is ignored.
2) The FSN of a user data message must be in-sequence,
otherwise it is a protocol error.
3) The BSN of any message is validated. If valid, it is
used to drain the retransmit queue (an ACK) and update
link L2 data. If not valid, then the BSN is simply ignored.

Regards,

Jeff

[email-masked]@ietf.org on 07/23/2002 02:38:39 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:

Hi all,

There is an issue with having two different streams for MSU and LSU in
M2PA.
The issue relates to FSN and BSN sequencing that are being sent along with
LSU
as well as MSU.
LSUs and MSUs are sent on different SCTP Streams and no guarantee on the
order
of arrival at the Peer can be given.
This could cause the out of order arrival of FSN and BSN values at the
Peer,
which in turn would lead
to rejecting of the current association according to M2PA Draftv5.

          A                        B
       +--------+                     +---------+
       |        |                     |         |

1) MSU with FSN values 1, 2, 3 and BSN value 0 are sent from A to B. The
message
is received at B.
2) MSU with FSN value 1 and BSN value 3 is sent from B to A. The message is
received at A.
3) Some time elapses with no message from B, A now sends an INSERVICE LSU
to B
with FSN as 3 and BSN as 1. This message is sent on Stream 0
    and is in transit on the Network.
4) B sends another MSU with FSN as 2 and BSN as 3. The message is received
at A.
5) A sends another MSU with FSN as 4 and BSN as 2. The message is received
at B.
6) The LSU that had been sent in (3) now reaches B and has both its FSN and
BSN
values out of sync. According to the current draft the association should
be
discarded.

I guess the above consideration was missed out while adding FSN and BSN to
Dual
Stream M2PA.
Now either we should allow only a single stream for a link or else we
should
explicitly define a mechanism for handling the above scenario.

Regards
Anshoo.

----- Original Message -----

To:   [email-masked]

Al Varney

---

From: [email-masked]
Date: Tue, 23 Jul 2002 12:57:02 -0400

Al,

Yes, M2PA does contradict Q.703 regarding FSN and BSN. It states 

"When M2PA receives a message with Backward Sequence Number equal to
'n', it may remove all messages with Forward Sequence Number <= n from
its queue."

It should be, according to you,

"When M2PA receives a [User Data] message with Backward Sequence Number 
equal to
'n', it may remove all messages with Forward Sequence Number <= n from
its queue."

Barry Nagelberg

Al Varney <[email-masked]>
Sent by: [email-masked]
07/23/2002 12:43 PM

        To:     [email-masked]
        cc: 

>link L2 data. If not valid, then the BSN is simply ignored.

    I think you should address the "problem" by following Q.703 
requirements.  Both the FSN AND BSN of LSSUs are effectively ignored by 
MTP2 (see Q.703 5.2.2(b) and Figure 14, Sheet 2 for BEC method and Q.703 
section 6.3.1 and Figure 16, Sheet 2 for PCR method).

    So you should not validate the FSN or the BSN of any LS message, per 
Q.703.  M2PA doesn't contradict this, does it?

Al Varney