Subject: Re: M2PA: Acknowledgement Problem

From: Tom George <[email-masked]>
Date: Fri, 03 Aug 2001 17:30:18 -0500

Brian,

We are still not convinced that SS7 links withhold acknowledgement of an
MSU until the MSU is successfully delivered to MTP3. 

This information comes from Q.703. But T1.111.3 has similar information. 

[1] Section 4 - This section describes the Level 2 MSU acceptance
procedure.  In brief, it describes how Level 2 should determine if an SU
is properly formed before admitting it.  This includes Flag Detection,
Start of SU Detection, Bad Octet Detection ("7 ones" and non-8-bit
multiple), Bad Length (< 6 or > 279 octets), and Bad CRC.  The
implication is that if the SU passes these tests, it is "accepted" and
Ack is generated to transmitter. 

[2] Section 5.2.2 c) ii) - This section describes the further acceptance
processing of an MSU: "if the forward sequence number value is one more
(modulo 128, see 2.3.5) than that of the last accepted signal unit and
if the received forward indicator bit is in the same state as the last
sent backward indicator bit, the signal unit is accepted and delivered
to level 3.  Explicit positive acknowledgements to the accepted signal
units are sent ..." 

[3] Figure 14, (sheet 5 of 7) - Basic Reception Control - This sheet
describes the above procedure in SDL flowchart form.  At the top,
"MSU/FISU Accepted?" (yes), ..., "Signal unit = MSU?" (yes), "Received
Message to Level3", ..., "FSNX = FSNX + 1 ...", ..., 
"FSNX Value RC to TXC".  This latter step signals Transmission Control
to bump the next BSN value outgoing thus acknowledging the MSU. 

None of these passages state that MSU acknowledgements are withheld
awaiting successful processing by the upper layer. The text seems to
indicate the contrary. 

tomG.

On Fri, 25 May 2001, "Brian F. G. Bidulock" wrote:
> 
> Tom,
> 
> This is a separate note to attempt to address the acknowledgment
> problem in M2PA.  This problem occurs whenever M2PA attempts to
> give one of the following indications:
> 
>         Out of Service
>         Busy
>         Processor Outage
> 
> In the case of SS7 (SIOS, SIB, SIPO), the signalling link stops
> acknowledging received frames.  In the case of M2PA, SCTP
> continues acknowledging DATA chunks after these indications are
> sent.  This has the problem of clearing the MSUs from the sender's
> transmission and retransmission buffers and making them
> unavailable for retrieval should the link fail as a result of
> any of these indications (it always fails for "Out of Service").
> 
> This increases message loss due to failure.  At the SS7 link
> level, SS7 links DO NOT ACKNOWLEDGE MSUs UNTIL THEY ARE
> SUCCESSFULLY DELIVERABLE TO MTP LEVEL 3!
> 
> (Please excuse the caps.)
> 
> What is required for M2PA to bring message loss back down to
> acceptable levels is for M2PA to have a way of controlling when
> MSUs are acknowledged to the peer.  There are two ways of doing
> this:
> 
>         1)  Alter SCTP-ULP interaction to permit M2PA to tell
>             SCTP when to acknowledge DATA chunks and when not
>             to.
> 
>         2)  Put sequence numbers and acknolwedgement in the DATA
>             chunks with the MSUs themselves (i.e. put FSN/BSN in
>             the frame).
> 
> I prefer solution #2, because it will probably be a cold day
> before SCTP gets changed.
> 
> This is also a problem for M2UA.
> 
> --
> 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 ¦

-- 
* Tom George        972-519-3168         [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 3 Aug 2001 18:38:45 -0500

Tom,

You are missing the point: I said "succesfully deliverable," not
"delivered".  That is, there must not be a receive congestion
situation, nor a processor outage situation.  SCTP continues
acknowledging receipt of messages while a SIPO or SIB is in
transit to the peer.  This is unacceptable.  SCTP acknowledges
messages where SS7 does not.

So, regardless of your views about delivery to Level 3 (although
even your implementation does it), M2PA is still broken.

If you consult the SDLs for Q.703 and ANSI T1.111.3 you will find
that the MSU is passed to Level 3 *before* the ack is generated
to the TXC from the Basic Reception Control.  If one were to
follow the SDLs, an implementation would not acknolwedge MSUs
until successful delivery to MTP Level 3.  Note that the RC also
checks for receive congestion and processor outage conditions
before attempting delivery and before acknowledgement.

As it stands, M2PA has SCTP merrily acknowledging frames without
checking receive congestion or processor outage.   Nor, will SCTP
even check if the link is in service.  This is unacceptable, as
it traps these frames at the wrong end of the link, clearing them
from the transmitting SCTPs transmit and retransmit buffers,
making it impossible for the sending side to retrieve them in
changeover situations arrising from SIB, SIPO and SIOS.

As it stands M2PA will fail Q.782 conformance tests, in particular,
the changeover cases (where the implementation is not permitted to
lose a single message).

It will be necessary to include sequence numbering and acknolwedgement
from M2PA to M2PA at the ULP level to correct this error in M2PA.

--Brian

Tom George wrote:                            (Fri, 03 Aug 2001 17:30:18)
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

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

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Mon, 6 Aug 2001 07:03:28 -0500

Tom,

I agree with your analysis. While it is true that MTP2 withholds acks when
in PO and SIB states even if still accepting MSUs there is nothing in the
recs which extends the semantics of an MTP2 ack to MTP3. On the contrary,
the SIB implies an input buffer holding the MSUs in transit to MTP3. Only if
this buffer gets too full are acks withheld and SIBs transmitted.
For the SIOS case, though, MTP2 certainly does not ack or deliver MSUs once
in the OS state. I see, however, no problem if M2PA does not fully act the
same. And, ceterum censeo (=BTW), lets forget about retrieving any MSUs
already transmitted once ;o) It really is an unnecessary overkill.
Regarding references to Q.782, in an appropriately configured multi-homed
SCTP config, failing one path will pass all relevant Q.782 tests concerning
changeover/retrieval. 

Klaus

> -----Original Message-----
> From: Tom George [mailto:[email-masked]]
> Sent: August 03, 2001 6:30 PM
> To: sigtran
> Subject: Re: M2PA: Acknowledgement Problem
> 
> 
> Brian,
> 
> * PB2-1323       Intranet:  
http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Mon, 6 Aug 2001 13:12:56 +0200

sorry about jumping into this e-mail exchange, 

but I feel uncomfortable with the statements made by Brian below.

See my comment below.

HannsJuergen

> From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Saturday, August 04, 2001 1:39 AM
> To:	sigtran
> Cc:	Tom George
	[HJS]  ----snip-----

	In my interpretation, the SDLs only indicate when to pass the information about a certain event to another process. In the spirit of the SDLs, all the blocks shown e.g.  in figure 7/Q.703 could be interpreted as independent processes  that communicate with each other using the "messages" shown. In my interpretation the same assumption is true between MTP L3 and MTP L2. The only specified interaction between MTP L3 and Transmission Control (TXC) is via "message for transmission. There is no interface regarding a refraining from acknowledgement.

	There is NO indication, in case I issue "received message from RC to L3" that the sending process (Basoc reception control) has to wait for an acknowledgement from L3. That's a completly asynchronous interface, e.g. realized using queuing mechanisms. So what kind of "delivery confirmation" are you imagining?

	You are right, the signal to L3 is given before the signal "FSNX value" is sent to TXC, but  I also see no point where L3 could interact with TXC BEFORE TXC encounters the event from Basic Reception control.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Aug 2001 10:24:36 -0500

Hanns,

Schwarzbauer Hanns Juergen wrote:                    (Mon, 06 Aug 2001 13:12:56)
> 	In my interpretation, the SDLs only indicate when to pass the
> 	information about a certain event to another process. In the spirit of
> 	the SDLs, all the blocks shown e.g.  in figure 7/Q.703 could be
> 	interpreted as independent processes  that communicate with each other
> 	using the "messages" shown. In my interpretation the same assumption
> 	is true between MTP L3 and MTP L2. The only specified interaction
> 	between MTP L3 and Transmission Control (TXC) is via "message for
> 	transmission. There is no interface regarding a refraining from
> 	acknowledgement.
> 
> 	There is NO indication, in case I issue "received message from RC to
> 	L3" that the sending process (Basoc reception control) has to wait for
> 	an acknowledgement from L3. That's a completly asynchronous interface,
> 	e.g. realized using queuing mechanisms. So what kind of "delivery
> 	confirmation" are you imagining?
> 
> 	You are right, the signal to L3 is given before the signal "FSNX
> 	value" is sent to TXC, but  I also see no point where L3 could
> 	interact with TXC BEFORE TXC encounters the event from Basic Reception
> 	control.
> 
>

I don't really care about your "interpretation" of Q.703.  Practice and
experience dictates that this is the case.  Tell me what Siemens' MTP2
implementation does in their switches and STPs.  You will find that they
check for out-of-service, local processor outage, and receive congestion
discard situations when an MSUs is received.  If any of these occur, the
acknowledgement is withheld.  You will also find that Siemens' MTP2
implementation also sends MSUs to MTP3 before acknowledging MSUs to the
SS7 peer.

All you are doing is mincing words.  Please speak to engineering practice.

--Brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Aug 2001 10:32:06 -0500

Klaus,

Gradischnig, Klaus wrote:                            (Mon, 06 Aug 2001 07:03:28)
> already transmitted once ;o) It really is an unnecessary overkill.

Where there is a local procesor outage condition or an out of service
condition, the MSUs will not be delivered to Level 3, yet they are cleared
from the peer's transmit buffer.  This will result in message loss on
changeover resulting in failure of Q.782 tests.

> SCTP config, failing one path will pass all relevant Q.782 tests concerning

You forget that the draft counter-recommends multi-homed configurations in the
examples.  The configuration in the examples will fail Q.782.  Also, Q.782
does not say "fail one SCTP association"  it says "fail one link" and "induce
local processor outage condition".  Your so efficient arrangement (without the
"overkill" of acknowledgement, even in the multihomed arrangement) can be
demonstrated to fail changeover tests in both Q.782 and GR-905-CORE.  These
are MTP Level 3 tests: meaning that M2PA does not provide the mechanisms
necessary to the permit MTP Level 3 to conform in this respect.

Any implementation of M2PA in its current state will not be acceptable to a
carrier.

==brian

> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 23:35:59 -0500

Tom,

This issue has still not been addressed.

As it stands it will be easier and better to do SSCOP-MCE to support
IP links than M2PA/SCTP.  For that matter, as it stands SSCOP/SCTP
is better than M2PA.  Either other approach will permit Q.782
conformance, M2PA does not.

Autonomous SCTP acknowledgement of received MSUs to the SCTP peer is
unacceptable.

Please include in the draft forward and backward sequence numbers
in messages to accomodate this necessary function.

--brian

Brian F. G. Bidulock wrote:                (Fri, 03 Aug 2001 18:38:45)

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

---