Subject: Re: [Sigtran] M2PA list of comments on draft version 5

From: Tom George <[email-masked]>
Date: Mon, 12 Aug 2002 17:06:09 -0500

My summary of the discussion so far. 

It seems that most of our discussion has centered around some new
comments that were not on the list I sent out on July 13 (appended
below). 

So here are the additions to the list. 

16. 07/19/02 Ray Singh "[Sigtran] Comment on M2PA - Slow Start". What
    kind of warning is needed about slow start?

A: I proposed a general warning about slow start to replace specific
warnings throughout the document.

alignment, changeover, path failure (multihoming), reduced volume. See
Tolga's message, 07/26/02.

17. 07/22/02 Tolga Asveren "[Sigtran] M2PA : LS messages on stream
    0". Are there problems with sending Status and Data on different
    streams? What mimics MTP2 best?

A: The problem with putting LS and Data on the same stream is that a
LS message can get stuck behind a Data retransmission. This is
contrary to the message priority of MTP2.

The problem with using SCTP unordered transmission for LS messages is
that they can get out of order with each other. For example, a LS Proc
Outage could get out of order with a LS Proc Outage Ended. 

MTP does not require that LSSUs and MTUs be associated with each other
in any particular way. It has MTP2 put LSSUs ahead of MTUs in the
transmit buffer. So it should not be required that M2PA transmit LS in
order with Data.

Having M2PA put LS at the front of the M2PA transmit queue helps some,
but it does not do anything about the messages that are in the SCTP
send queue. To truly imitate MTP2 at this point, we would need a way
to give a message to SCTP and tell it to put the message at the front
of its send queue.

(Or, we could restrict SCTP to just 1 message in its send buffer. This
would allow M2PA to prioritize like MTP2. But this would create severe
problems of its own. No one seemed to like this option.)

Sending LS and Data on different streams allows for a partial
imitation of the MTP2 transmission priority. If the receiving M2PA
gives priority to reading incoming LS messages (on stream 0) over Data
messages (on stream 1), then LS messages can be received sooner than
if they waited behind the Data messages. Also, it is possible for
SCTP, by some implementation-dependent method or some future SCTP
extension, to give a higher priority to sending messages on stream 0.

My conclusion is to leave the draft alone. Having separate Status and
Data streams does not exactly imitate MTP2, but it is as close as we
can get using SCTP.

Some related matters:

I will add to 4.1.7 so that it says that M2PA transmits LS messages
before Data messages. This is in addition to the attempt to prioritize
SCTP stream 0.

The FSN should be ignored in the LS messages. FSN should be
incremented only for Data messages.

I will add a warning that one has to watch out for a wraparound of the
FSN/BSN numbers. This is unlikely with 24 bits, but should probably be
mentioned.

18. 08/09/02 Howard May "[Sigtran] M2PA - Minor corrections?" 

    In Figure 7, RETRIEVAL receives MTP Start. Go to AIP, not OOS.

A: Yes. Done.

On July 13 Tom George wrote:
> 
> Here is my list of comments. For the most part, they are arranged by
> the thread from the SIGTRAN list.
> 
> Everyone please make comments. I think the discussion would go more
> smoothly if you only talked about one item per e-mail.
> 
> 1. Section 2.2. FSN/BSN should be 24 bits, not 23.
> 
> A: This was a typo. It will be 24 in M2PAv6.
> 
> 2. 05/06/02 Jeff Craig "[Sigtran] (M2PA) What actions should be taken
>    if LSA or User Data Received in PROVING?" There is no guidance
>    about anomalous events during alignment/proving.
> 
> A: I agree that some text should be added. I have not worked out the
> details and would welcome suggestions.
> 
> 3. 05/10/02 Jeff Craig, "[Sigtran] (M2PA) Please standardize M2PA
>    protocol timer identifiers" and Jeff Craig 06/21/02 "m2pa comment:
>    timers". Line up timer names in Q.703 and M2PA. Add the T7 timer.
> 
> A: This is what I got out of the discussion:
> 
>    Keep same names for T1, T3, T4, T6.
> 
>    Rename M2PA T2 to T4.
> 
>    Don't use "timer" names for the rate parameters.
> 
> 4. 05/17/02 Jeff Craig, "[Sigtran] (M2PA) Please add a Network
>    Appearance parameter to the M2PA protocol". A suggestion that a NA
>    parameter be added to M2PA.
> 
> A: I prefer not to add this.
> 
> 5. 05/22/02 anssharma, "[Sigtran] M2PA Clarification". In level 2 flow
>    control, M2PA stops transmitting. What does it do with the
>    messages?
> 
> A: I think is an implementation matter.
> 
> 6. 05/24/02 Lisa Gorgone, "[Sigtran] M2PA:Questions on sequence
>    number". Some questions about bad values of FSNR and BSNR.
> 
> A: M2PAv5 (4.2.1) says to fail the link if one FSNR is out of order. I
> think that is OK. There is nothing about bad BSNR values. I would be
> inclined to fail the link in this case as well, since one end is
> acking messages that the other does not have in its (re)transmit
> buffer.
> 
> 7. 05/24/02 Brian Bidulock "[Sigtran] Re: M2PA Clarification". Does
>    M2PA need to withhold messages from SCTP during busy?
> 
> A: If this is how Q.703 works, we should copy it. I just sent a
> question to the list about the Q.703 procedure.
> 
> 8. 06/18/02 amish.chana "[Sigtran] M2PA Comment: Multi-homing". Should
>    M2PA support multi-homing?
> 
> A: It is allowed. The only change needed is in 4.1.2 so that it says
> "the IP address (or IP addresses if multi-homing is used)".
> 
> 9. 06/19/02 Lisa Gorgone "Re: [Sigtran] M2PA Comment:Retrieval
>    State". Does M2PA need a RETRIEVAL state? Does RETRIEVAL state
>    cause harm?
> 
> A: I would like to have more discussion about this.
> 
> 10. 06/21/02 Javier Pastor-Balbas "[Sigtran] M2PA Comment:
>     Multi-homing". Also 06/21/02 "[Sigtran] Multiplexed M2PA links on
>     an association".  Should M2PA allow multiple links per
>     association?
> 
> A: The disadvantage of this is that if the association dies, you lose
> all the links on the association. (According to the SCTP authors, it
> is intended that all the streams in an association follow the same
> physical path.) This is one of the main reasons I did allow for
> multiple links in an association.
> 
> 11. 06/21/02 Andrew Booth "[Sigtran] M2PA Comment: T7 Timer" and
>     several of the earlier threads. Should there be an equivalent of
>     MTP2 T7?
> 
> A: OK, you finally convinced me. 8-)
> 
> 12. 06/25/02 Lyndon Ong "RE: [Sigtran] M2PA Queries - summary". Just a
>     summary of the discussion.
> 
> A: No answer needed.
> 
> 13. 06/26/02 Karen King "[Sigtran] A couple of comments on M2PA
>     processor outage". Recommend adding text to 4.1.4 Processor Outage
>     about flushing buffers as in Q.703.
> 
> A: Even though this is in Q.703, the action is taken by MTP3. Section
> 4.1.4 (next to last paragraph) does allow for the flush. Flush is
> described in 4.2.4. So I think this is taken care of (although there
> may be problems in 4.2.4 - that's another thread).
> 
> 14. 06/28/02 Ray Singh "[Sigtran] Comment on M2PA - Performance
>     Monitoring". Add back the monitoring of SCTP association that was
>     in draft version 3.
> 
> A: The reason I took this out is that I never had any solid ideas
> about what SCTP parameters should be monitored and what the acceptable
> values would be. If we could come up with something helpful, I am not
> opposed to adding the monitoring back in. But I don't see the point of
> adding it if the criteria will be some implementation-dependent
> parameters having implementation-dependent values. 8-(
> 
> 15. 07/12/02 anssharma "[Sigtran] M2PA - Flush Buffers". Questions
>     about Flush.
> 
> A: These are good questions but I have not had time to think about
> them.
> 
> --
> * 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. *
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 12 Aug 2002 18:34:54 -0400

Tom and all,

I don't want to block progress of M2PA draft (so you can take this question
out of the context of single stream/double stream debate) but still can
someone tell, why we should restrict SCTP to 1 message in its send buffer to
allow M2PA prioritize like MTP2? Personally I don't think this is necessary.

    Tolga

---

From: Tom George <[email-masked]>
Date: Tue, 13 Aug 2002 15:45:42 -0500

Tolga,

We are not going to restrict SCTP to 1 message in its send buffer.

Here is what happened (you probably know most of this): MTP2 places
LSSUs ahead of MSUs on its transmit queue. The question arose as to how
M2PA would imitate this. When M2PA is ready to send a Link Status
message, there might be many messages queued up in SCTP's send buffer.
There is no way for M2PA to give the LS message to SCTP and tell SCTP to
put the message at the front of its send queue.

Someone (Brian B., I think) noted that you could achieve this effect by
restricting SCTP's send buffer to one message. Then when M2PA sends a LS
message, the message could be sent immediately to SCTP (ahead of any
messages in M2PA's transmit queue). So you can imitate MTP2's transmit
priority. Of course, you would not want to do this with SCTP. Even the
person who "suggested" this did not advocate actually doing it. 

tomG.

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 13 Aug 2002 17:08:31 -0400

Tom,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tom George
> Sent: Tuesday, August 13, 2002 4:46 PM
> Cc: [email-masked]
> Subject: Re: [Sigtran] M2PA list of comments on draft version 5
>
>
> Tolga,
>
[TOLGA] If one has the intention to imitate MTP2 prioritizing mechanism with
M2PA (not with SCTP) then I don't think there is a need to limit SCTPs send
buffer to 1 message. In such a case, M2PA will prioritize while sending the
messages to local SCTP, and the remote M2PA will get the messages in the
same order. Any retransmission/unordered delivery on IP level etc... are
totally transparent to M2PA. IMO, this mimics exactly MTP2 behavior, if the
intention is to achieve this in M2PA. SCTP will never change order or
messages, if a single stream is used. For example, M2PA at A sends LS1 and
then MS1 to local SCTP. It is possible that remote SCTP receives first MS1
and then LS1. But it always will transmit first LS1 and then MS1 to the M2PA
at its end. So, if ones intention is to achieve prioritizing with M2PA (not
with SCTP) , then I think with a single stream this is doable and does not
require to limit SCTP send buffer to 1 message. As I pointed out in an
earlier message, to decide which buffers are corresponding to MTP2 buffers
(M2PA buffers or SCTP buffers) migth prevent different interpretations by
different people.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 13 Aug 2002 15:16:01 -0600

Tolga,

SCTP is so not like a wire, one would be foolish to pretend
that it can imitate one to MTP Level 2.

SCTP simply cannot meet MTP2's delay requirements (acting as
MTP1).  It is quite possible that M2PA can meet MTP3's delay
requirements.

Deep buffers and variable link delays introduced at Level 1
have been identified as a source of catastrophic cascade
failures in SS7 links: if we ignore the differences between
SCTP and a wire, rather than rare, such catastrophes will be
commonplace.  Field experience, simulation and queueing theory
have all shown this to be true.

It is appropriate that M2PA does not treat SCTP as MTP2 treats
MTP1.  SCTP is, after all, a transport protocol and not a link
protocol.  This is close to SSCOP for MTP3b, for which
significant positive operational experience has been gained.

--brian

Tolga Asveren wrote:                             (Tue, 13 Aug 2002 17:08:31)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 13 Aug 2002 17:40:31 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, August 13, 2002 5:16 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] But SCTP does not need to meet MTP2's delay requirement, if it acts
as level1. It needs to meet requirements of M2PA.
> significant positive operational experience has been gained.
[TOLGA] Then we should put it correctly, we don't try to prioritize by M2PA
but by SCTP, so we are not trying to mimic prioritizing mechanism of MTP2
with M2PA. I understand your points, but with buffers at both M2PA and SCTP,
IMO the model is not very clean (but so be it).
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > Tom George
> > > * PB2-1323       Intranet:
http://www.ssd.usa.alcatel.com/~tgeorge/  *

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 13 Aug 2002 15:50:04 -0600

Tolga,

Tolga Asveren wrote:                                   (Tue, 13 Aug 2002 17:40:31)
> as level1. It needs to meet requirements of M2PA.

This is the point you seem to be missing: for M2PA to treat
SCTP in the same manner as MTP2 treats a "wire", SCTP must
meet the delay properties of the "wire": thus modelling SCTP
as a "wire" is dangerous at best.

> IMO the model is not very clean (but so be it).

Both M2PA and M2UA were modelled after MTP3b.  SCTP lacks
SSCOP's user-level acknowledgement (NSD acknowledged data
service): TSN acks are useful for congestion control only.
Therefore, M2PA had to institute a user-level ack on top of
SCTP.  This makes SCTP for all intents and purposes equivalent
to SCCOP once M2PA is included.  This is a true adaptation
layer and not a distinct protocol layer.

And SSCOP *is* modelled after the more traditional Q.703 MTP2
(see the normative references in the MTP3b docs).  So M2PA is
modelled after MTP2 and MTP3b at the same time.  There is no
perversion of the model.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 13 Aug 2002 18:35:49 -0400

Brian,

> Sent: Tuesday, August 13, 2002 5:50 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] But for data M2PA really treats SCTP as an error-free wire. As far
as I can see, the only place, where there is a diversion from this approach
is using a different stream for LS. IMO, meeting delay requirements of MTP3
with M2PA+SCTP solution is significantly dependent on the characteristics of
IP network, rather than the modelling of SCTP and M2PA functionality.
> service): TSN acks are useful for congestion control only.

[TOLGA] Why? They are used also for retransmission, so provide reliable
transport of messages.

> modelled after MTP2 and MTP3b at the same time.  There is no
[TOLGA] IMO, because sometimes M2PA buffers (data acknowledgement) and
sometimes SCTP buffers correspond (retranmission)to MTP2 buffers with the
current model, it is not very clean (regardless whether it is similar to
another model or not). I don't think, it is very correct to think current
M2PA as MTP2-SCTP (after M2PA has its own buffers). But as I said, because
it seems that everybody else than me is happy with the current situation,
there is no problem.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 13 Aug 2002 17:44:11 -0600

Tolga,

Tolga Asveren wrote:                                                               (Tue, 13 Aug 2002 18:35:49)
> IP network, rather than the modelling of SCTP and M2PA functionality.

error free != wire

contradiction in terms

> [TOLGA] Why? They are used also for retransmission, so provide reliable

But the user cannot withold an acknolwedgement: they can in both
MTP2 and SSCOP.

> it seems that everybody else than me is happy with the current situation,

There is only one TB/RTB: M2PA, because there are user-layer acks: just
as in MTP2 and SSCOP.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 13 Aug 2002 20:13:18 -0400

Brian,

> Sent: Tuesday, August 13, 2002 7:44 PM
> To: Tolga Asveren
> Cc: [email-masked]
>                  (Tue, 13 Aug 2002 18:35:49)
> > Brian,
> >
[TOLGA] O.K., let's call it error free transmission facility.
> There is only one TB/RTB: M2PA, because there are user-layer acks: just
[TOLGA] If M2PA buffers are considered as real user message buffers (that is
also how I prefer to see it), then IMO this just makes the argument that
SCTP should preserve send order of M2PA stronger. And to achieve this, SCTP
should use only a single stream. In such a case, prioritizing happens in
M2PA, and SCTP just transfer the messages without changing their ordering at
all. Again in such a situation, retransmissions on SCTP level are
transparent to M2PA (which has the buffers) so an argument about that SCTP
retransmission of some data might delay LS is invalid, because this
retranmission does not correspond to a retransmission of a message in MTP2
(and this is because of the assumption that M2PA buffers correspond to MTP2
buffers)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 13 Aug 2002 20:00:22 -0600

Tolga,

Tolga Asveren wrote:                                                               (Tue, 13 Aug 2002 20:13:18)
> [TOLGA] O.K., let's call it error free transmission facility.

Let's call it reliable (albeit sliding window delay) transport.

> (and this is because of the assumption that M2PA buffers correspond to MTP2

Your queuing model is invalid and nowhere near that of MTP2.  The only thing
which causes queueing in MTP2 are errors in transmission and delayed
acknowledgement.  Neither stop LSSUs from being transmitted in MTP2's
queuing model (and they are sent unreliably at that--no acks).  M2PA on a
single stream poses the possibility (and eventuality) that link status
will become blocked behind data messages which will never be acknowledged
slowing changeover response and making it difficult for MTP3, now, to meet
its performance objectives.

I'm sorry but you cannot just ignore the fact that SCTP bottlenecks under
congestion or simple packet loss with characteristics very unlike either
MTP2 or SSCOP.  Expediting link status around data messages as much as
possible is the way to go: thus, multiple streams (and unordered delivery
where possible).

This is the current M2PA situation.  Nothing but advantages: no disadvantages.

By the way, the original reason for multiple streams was to keen the link
status out of the data stream so that SSN in the data stream could be used
for changeover in XCO.  Even though an M2PA-level ack has been included; there
is still much advantage to be had from multiple streams.

Why are you against using SCTP's stream facility?  Without it, you might as
well use TCP.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 14 Aug 2002 09:32:28 -0400

Brian,

> its performance objectives.
[TOLGA] But here aren't you again considering SCTP buffers corresponding to
MTP2 buffers, when you say SCTP retranmission of data might delay LS? IMO,
this does not happen in M2PA itself but in SCTP, so can't be compared to
retranmission in MTP2 case. And because M2PA uses a reliable transport,
there are no retransmission on M2PA level at all. How I would see things is,
M2PA sends a message and the remote M2PA receives it, and how fast/slow this
happens mainly relies on IP network characteristics (round trip, packet loss
etc..).
> possible is the way to go: thus, multiple streams (and unordered delivery
[TOLGA] Also here, is it fair from modelling point of view, to say M2PA
buffers are corresponding to MTP2 buffers and then compare SCTP and MTP2
behavior?
> Why are you against using SCTP's stream facility?  Without it,
[TOLGA] I think when M2PA work started, the goal was to interprete SCTP
buffers as MTP2 buffers and define M2PA as  MTP2-SCTP. But with buffers in
M2PA, I think now it is more like  M2PA = MTP2 over SCTP. In such a case, I
also would think one can  replace SCTP with TCP, if one wants. Having
buffers in M2PA, which correspond to MTP2 buffers, and then to mimic MTP2
priority mechanism to rely on a lower layer (SCTP), is not a good modelling
in my opinion. That is, why I don't like to use a separate stream for LS.
But as I said also before, everybody is happy (except me)with current
approach, so no problem.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Aug 2002 16:58:16 -0600

Tolga,

Tolga Asveren wrote:                                                               (Wed, 14 Aug 2002 09:32:28)
> retranmission in MTP2 case.

I don't care where it it is happening, I just care that it is happening.
To avoid it, one simply uses two streams.

> And because M2PA uses a reliable transport,

And that is a catastrophe brewing.

> buffers are corresponding to MTP2 buffers and then compare SCTP and MTP2

What buffers?  In a zero copy implementation there is only one buffer
for any data.

> But as I said also before, everybody is happy (except me)with current

Perhaps you are thinking about M2PA before acknowledgements were introduced.
Acknowledgements are necessary at the M2PA level so that M2PA state machines
(as MTP2) has the ability to withhold acknowledgements.  SCTP provides no
such facility to its ULP.  One was discussed in TSVWG, but rejected.

--brian

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