Subject: Re: [Sigtran] (M2PA) Comments on M2PA v8

From: "Rohan Pascal S Goveas" <[email-masked]>
Date: Mon, 2 Jun 2003 18:40:05 +0530

All,
 See inline for  comment on point number 2.
-Rohan

----- Original Message -----
From: Tom George <[email-masked]>
To: <[email-masked]>
Sent: Saturday, May 31, 2003 3:55 AM
Subject: Re: [Sigtran] (M2PA) Comments on M2PA v8

> Here is how I think I should fix this:
>
> 1. Delete the sentence in 4.2.1
> "M2PA SHOULD ignore the FSN and BSN contained in a Link Status message."
> There is no harm in using those fields, as long as they are used
> appropriately. This will also fix the inconsistency David Lehmann
> pointed out.
>
> 2. In 4.1.4, M2PA should resynchronize its sequence numbers after PO the
> same way MTP2 does. In the case of Q.703 Figure 13 sheet 7, the BSNR
> would come from the LS Processor Recovered message instead of the first
> MSU/FISU as in MTP2.
>
>>>>>>>
>>>>< ROHAN >  In my opinion it is may be wrong to take the BSNR from the LS
Processor Recovered message.
           In case of Q.703 the BSNR is taken from MSU/ FISU. The MSU/FISU
is sent only after a Local Processor     Outage is ended and a Continue or
Flush is received.
          M2PA as such does not explicitly say that a Flush or Continue
should be sent for the Procesor Outage to be ended as in Q.703. Now suppose
in case the end point sends a LS Processor Outage followed by a  Flush
command the end which receives the LS Processor Outage recovered will take
the BSNR from this message and starts T7 for messges which are flushed or
discarded although these messages are already flushed form the remotes
Receive buffer.
  I  think we can have a option of sending a Empty User data message in
additon to Processor Outage Ended and the BSNR will be taken from the Emty
User data message rather than the LS Processor Recovered. Sending of Empty
User data message can be based on Flush or Continue command from MTP3.
>>>><ROHAN>>>

> 3. The statement in 4.2.1
> "For message types other than User Data, the Forward Sequence Number is
> set to the FSN of the last User Data message sent."
> needs some qualification. After PO, it is set as in item 2 above.
>
> 3. "Flush buffers" is going to mean about the same in M2PA as it does in
> MTP2. It will have to apply to both M2PA and SCTP buffers.
>
> 4. "Continue" after PO will mean that M2PA starts receiving and
> processing the messages that were buffered and not acknowledged during
> PO.
>
> tomG.
>
>
> Long ago Jeff Craig wrote:
> > > page 29, 4.2.1:
> > >
> > >     "M2PA SHOULD ignore the FSN and BSN contained in a Link Status
> > >     message."
> > >
> > >     This sentence contradicts Q.703 Figure 13, Sheet 7 of 7, which
> > >     indicates that the BSN of the M2PA LSPR should be used by the
> > >     recipient to set the initial FSN upon exiting remote processor
> > >     outage condition.
> > >
> > >     M2PA differs from MTP2 in that both sides buffer user data
> > >     received during processor outage. This difference needs to be
> > >     explained in detail in the draft. Processing of the buffered
> > >     messages needs to be explained for the cases of both FLUSH and
> > >     RESUME. As it stands now, the draft contradicts Q.703 and
> > >     does not explain how the M2PA peers keep sequence numbers
> > >     synchronized when existing from the processor outage condition.
> >
> > I think you are right here, too. I will need to think about this one.
>
> --
> * Tom George       PB7-24001 (near B-21)      [email-masked]  *
> * 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
> * Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
> * I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
> * to advertise or represent its position,  operations, or activities. *
> _______________________________________________
> 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: Tom George <[email-masked]>
Date: Mon, 02 Jun 2003 15:49:19 -0500

The LS PR should be sent in M2PA under the same circumstances as the
MSU/FISU in Q.703. (If that is not clear enough, maybe I should change
the wording in 4.1.4.)

I did not explicitly mention the Flush/Continue because you need to
follow the MTP2 procedures. 

I am wary of using an empty User Data message at the end of PO to
indicate the BSNR. As I stated in a message last week, the receiver will
not be able to tell if the empty UD message was sent before or after the
LS PR. 

tomG.

---

From: Tom George <[email-masked]>
Date: Tue, 03 Jun 2003 13:07:55 -0500

Here are the details on how I took care of this. 

tomG.

> appropriately. This will also fix the inconsistency David Lehmann

I deleted it.

> would come from the LS Processor Recovered message instead of the first

After this sentence:
"When the local processor outage condition ends, M2PA SHALL send a Link
Status Processor Recovered message to its peer. "

I added:
"The BSN value in this
message is used by the peer to resynchronize its sequence numbers, if
this is required by MTP2."

> needs some qualification. After PO, it is set as in item 2 above.

On further review, this is almost identical to the wording in Q.703
section 5.2.1 last sentence. I think this is OK as it stands, and it is
understood that there are exceptions for initialization and
resynchronization.

> MTP2. It will have to apply to both M2PA and SCTP buffers.

There is one difference between M2PA and MTP2 flushing. In MTP2, the
Flush command goes from LSC to TXC (Q.703 Figure 8 sheet 13). TXC
removes all of the MSUs from the RTB and TB. 

In M2PA, some of the messages that would have been kept in the RTB/TB in
MTP2 were transmitted by SCTP and are buffered at the receiving end.
These messages should be flushed, too. 

So I added this to 4.1.4 (just before "In other respects..."):
"If M2PA receives a Flush command from MTP3, M2PA SHALL discard the
incoming messages that were queued and unacknowledged during the
processor outage condition."

> processing the messages that were buffered and not acknowledged during

Right after the paragraph about Flush, I added:
"If M2PA receives a Continue command from MTP3, M2PA SHALL begin
processing the incoming messages that were queued and unacknowledged
during the processor outage condition."

---

From: Tom George <[email-masked]>
Date: Tue, 03 Jun 2003 13:26:28 -0500

I just clarified some of the wording in 4.1.4 to answer some obvious
questions. Here is the revised text.

tomG.

----------------------------------
4.1.4 Processor Outage

The Link Status Processor Outage message replaces the SIPO message of
MTP2. Unlike MTP2, the message SHOULD NOT be transmitted
continuously. M2PA SHALL send a Link Status Processor Outage message
to its peer at the beginning of a processor outage condition where
MTP2 would send SIPO. M2PA MAY send additional Link Status Processor
Outage messages as long as that condition persists. 

When the local processor outage condition ends, M2PA SHALL send a Link
Status Processor Recovered message to its peer. This message is used
to signal in the end of the processor outage condition, instead of an
MSU or FISU as in MTP2. The BSN value in this message is used by the
peer to resynchronize its sequence numbers, if this is required by
MTP2.

While in a local processor outage condition:

   (a) Any User Data messages received from the peer MUST NOT be
       acknowledged and MUST be buffered.

   (b) M2PA SHOULD continue to acknowledge User Data messages received
       and accepted by MTP3 before the local processor outage.

While there is a remote processor outage condition:

   (a) Any User Data messages received from the peer after the Link
       Status Processor Outage MUST NOT be acknowledged and MUST be
       buffered.

   (b) M2PA SHOULD continue to acknowledge User Data messages received
       and accepted by MTP3 before the remote processor outage.

If M2PA receives a Flush command from MTP3, M2PA SHALL discard the
incoming messages that were queued and unacknowledged during the
processor outage condition. Furthermore, M2PA SHALL discard messages
in the transmit and retransmit queues as required by MTP2. 

If M2PA receives a Continue command from MTP3, M2PA SHALL begin
processing the incoming messages that were queued and unacknowledged
during the processor outage condition.

In other respects, M2PA SHOULD follow the same procedures as MTP2 in
processor outage.
------------------------------------

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 3 Jun 2003 13:18:29 -0700 (PDT)

Tom,

[..snip..]
> in the transmit and retransmit queues as required by
[TOLGA]So also messages sent after local processor
outage ended but received before LSPR will be
discarded(?). How are they going to be retransmitted?

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 3 Jun 2003 16:56:31 -0600

Tolga,

In SS7 flushed messages are never retransmitted.  This
is because they are old and stagnant by the time the
Flush_buffers is issued and must be dicareded.

--brian

Tolga Asveren wrote:                                                                 (Tue, 03 Jun 2003 13:18:29)

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

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 4 Jun 2003 03:51:49 -0700 (PDT)

Brian,
--- "Brian F. G. Bidulock" <[email-masked]>
> Flush_buffers is issued and must be dicareded.
[TOLGA] Yes, but should we qualify also messages sent
after local processor outage ended but received on the
other side before LSPR (because they are sent on
different streams) as "old"?
> Tolga Asveren wrote:                                
>                                 (Tue, 03 Jun 2003
> 13:18:29)
> > > processor outage condition. Furthermore, M2PA
> SHALL
> > > discard messages
> > > in the transmit and retransmit queues as
> required by
> > > MTP2.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Jun 2003 11:43:50 -0600

Tolga,

Yes.

--brian

Tolga Asveren wrote:                                                                 (Wed, 04 Jun 2003 03:51:49)

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 4 Jun 2003 10:56:01 -0700 (PDT)

Brian,
> Yes.
[TOLGA]But why? They are sent after local processor
outage has ended. The sending side will keep timeout
information for such a message (T7) and because it
won't be acknowledged, link will be dropped.
>                                 (Wed, 04 Jun 2003
> 03:51:49)
> > > In SS7 flushed messages are never retransmitted.
> 
> > > This
> > >                                 (Tue, 03 Jun
> 2003
> > > > > If M2PA receives a Flush command from MTP3,
> M2PA
> > > > > SHALL discard the
> > > > Yahoo! Calendar - Free online calendar with
> sync
> > > to Outlook(TM).

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Jun 2003 12:22:59 -0600

Tolga,

If you want to avoid that, send your LPR in the
data stream.

--brian

Tolga Asveren wrote:                                                                 (Wed, 04 Jun 2003 10:56:01)

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 4 Jun 2003 11:39:06 -0700 (PDT)

I would think, this needs to be documented both to
warn people and to prevent interoperability problems.

  Tolga
wrote:
> 10:56:01)
> > >                                 (Wed, 04 Jun
> > > > > is because they are old and stagnant by the
> time
> > > the
> > > > [TOLGA] Yes, but should we qualify also
> messages
> > > sent
> > > > after local processor outage ended but
> received on
> > > the

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Jun 2003 13:12:42 -0600

Tolga,

Ok.  Add a paragraph somewhere that says:

LSPR, LSBE, LSA SHOULD be sent on stream 1.  All other
LS messages SHOULD be sent on stream 0.

Done.

--brian

Tolga Asveren wrote:                                                                 (Wed, 04 Jun 2003 11:39:06)

---

From: Tom George <[email-masked]>
Date: Thu, 05 Jun 2003 10:03:59 -0500

There may be a problem with sending LS PR on the Data stream. The
receiver has been queueing messages from stream 1 because of the RPO
condition. If the LS PR is sent on stream 1, it will be in the queue
behind those User Data messages. How will the receiver know that he has
received the LS PR message?

tomG.

> LS messages SHOULD be sent on stream 0.
  [...]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 5 Jun 2003 09:48:07 -0600

Tom,

What do you mean queueing?  Where? In the network? In SCTP?  In M2PA?
If in the network, the network is broken and the SCTP association will fail
anyway.  If in SCTP, M2PA is broken and should service it's receive buffer
better.  If in M2PA, M2PA is broken and should process LS as they arrive
and not wait on data.

Are you trying to say that M2PA stops servicing its receive buffer when
LSPO is received?  I don't think so.  That was one of the reasons we put
sequence numbers and acknowledgments in: so that SCTP could ack the message
without M2PA acking the message. M2PA should continue to service its receive
buffer but queue messages without acknowledging them.  The moment the LSPR
arrives, it can ack bufferred messages (unless it has latching of RPO to
LPO, in which case it waits for Continue or Flush from MTP3).

Could you explain the problem more?

--brian

Tom George wrote:                                                                      (Thu, 05 Jun 2003 10:03:59)

---

From: Tom George <[email-masked]>
Date: Thu, 05 Jun 2003 17:41:55 -0500

Good point. I confess I was thinking that M2PA could stop servicing the
receive buffer when there is an RPO. Not a good idea. Besides what you
said, M2PA needs to keep looking at incoming messages because some of
them might be empty User Data messages to ack previously sent messages. 

OK, I will keep thinking....

tomG.

---

From: Tom George <[email-masked]>
Date: Wed, 11 Jun 2003 15:12:47 -0500

I think this problem can be avoided. Suppose that messages are
transmitted in this order:

Type       FSN   stream
---------  ---   ------
User Data   1      1
User Data   2      1
LS PO       2      0
LS PR       2      0
User Data   3      1

The User Data messages arrive in order and the LS messages arrive in
order on their respective streams. But there are no guarantees about
their order relative to each other.

Tolga is concerned about the situation when the LS PR arrives after
the new User Data message. For example, say they arrive like this:

User Data   1      1
LS PO       2      0
User Data   2      1
User Data   3      1
LS PR       2      0

Does UD message 3 get unacked and thereby cause link failure?

Here is what happens:

User Data   1      1

    Message is passed to MTP3.

LS PO       2      0

    Mark RPO and notify MTP3. Buffer but do not ack incoming messages.

User Data   2      1

    This message goes into the buffer-but-do-not-ack queue. The T7
    timer is _not_ running at the other end.

User Data   3      1

    This message goes into the buffer-but-do-not-ack queue. The T7
    timer _is_ running at the other end.

LS PR       2      0

    Notify MTP3 that the RPO has ended.

    If MTP3 wants to Continue, then start processing the queued
    messages.

    If MTP3 wants to Flush, then M2PA should not delete all messages
    willy-nilly. It should note that in the LS PR message, FSN =
    2. Therefore:

       UD message 2 was sent before the PO, so flush it.

       UD message 3 was sent after the PO, so process and ack it.

tomG.

Tolga Asveren wrote:
>>>>is because they are old and stagnant by the time
>>>
>>the
>>
>>>[TOLGA] Yes, but should we qualify also messages
>>
>>sent
>>
>>>after local processor outage ended but received on
>>
>>the
>>
>>>>>>processor outage condition. Furthermore,
>>>>>
>>M2PA
>>
>>>>SHALL
>>>>
>>>>>>discard messages
>>>>>[TOLGA]So also messages sent after local
>>>>
>>processor
>>
>>>>>discarded(?). How are they going to be
>>>>
>>>>retransmitted?
>>>>
>>>>>
>>>Yahoo! Calendar - Free online calendar with sync
>>
>>to Outlook(TM).
>>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Jun 2003 16:04:51 -0600

Tom,

Send LSPR ordered on stream 1 and there is no problem,
because then the race condition between LS PR and DATA
is removed.

That is a simpler and more direct solution than expecting
the receiver to resolve races.  It seems rather pointless
to intentionally introduce races when SCTP provides an
ordered delivery service.

--brian

Tom George wrote:                                                                      (Wed, 11 Jun 2003 15:12:47)

---

From: Tom George <[email-masked]>
Date: Wed, 11 Jun 2003 17:35:53 -0500

But now you have a race condition between LS PO and LS PR.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Jun 2003 20:03:31 -0600

Tom,

Although it is hightly unlikely that a real network work
place them close enough together for there to be a race,
sending everything ordered on one stream would solve all
racees.

If one wants to use Q.703 state machines for the most part
then it appears that one should meet the same ordering
characteristics as an Q.703 link.

--brian

Tom George wrote:                                                                      (Wed, 11 Jun 2003 17:35:53)

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 12 Jun 2003 05:56:03 -0700 (PDT)

I also think like Brian. IMO Tom's solution is a nice
one, but isn't it just to use a second level of global
sequencing on top of stream based SCTP sequencing, to
prevent side effects of multiple streams? As far as I
understand, if this is the way to go, there will be
cases where one needs to look to FSN for sequencing
information and cases, where one does not need this.
IMO, this will complicate the protocol.

   Tolga 
wrote:
>                                   (Wed, 11 Jun 2003
> 17:35:53)
>                                       (Wed, 11 Jun
> 2003 15:12:47)
=== message truncated ===

---

From: Tom George <[email-masked]>
Date: Thu, 12 Jun 2003 16:05:59 -0500

Likewise, I think the probability of the User Data with FSN=3 arriving 
ahead of the LS PR is very small, too. The LS PR is sent first and in 
all likelihood the UD message will follow the LS message along the same 
path through the network.

The idea of the separate stream for LS is to expedite some of the LS 
messages (Busy, Busy Ended, PO, PR, OOS) past any queued messages at the 
receiving end.

For example: If node "A" is suffering from receive congestion (in SCTP 
or M2PA), and its peer "B" sends LS OOS (or LS PO), the message could 
get stuck for a relatively long time behind the data messages. In the 
meantime, A continues to send User Data messages to B. A does keep the 
messages in its retransmit queue, so they are available for 
changeover,so the messages are not lost. But it seems like this is not 
ideal. A might keep sending until its T7 timer expires, or until its 
MTP3 receives an XCO from B.

IMHO we should do what we can to expedite the LS messages. It would be 
even better to have some kind of prioritized stream scheme in SCTP, but 
you have to get by with what is available.

To me it looks like a tradeoff. The data stream makes the protocol 
complicated in places. But going to one stream means losing some ability 
to notify the other end of status changes in a timely manner.

tomG.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Jun 2003 08:31:26 -0600

Tom,

> MTP3 receives an XCO from B.

XCO must arrive within 0.5 seconds (1/2 T7) for Q.704 if this is not the
last link.  If it is the last link the point is moot.

Besides that, LS OOS does not have to be sent on another stream to be
expedited.  It could be sent unordered.

There is no similar argument for any other LS message.  It is the other
LS messages that have the race conditions.

So, send them all on one stream and send LS OOS unordered (and periodic).

> to notify the other end of status changes in a timely manner.

See different solution above.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran