Subject: RE: [Sigtran] M2PA list of comments on draft version 5 - multiple links on the s

From: "Amish Chana" <[email-masked]>
Date: Fri, 19 Jul 2002 20:56:59 +0100

Tolga,

> > > [Amish] From the list in 2.3.2, the only LS messages that will be
> > > transmitted
> > > over a link that is the "In Service" state are the Processor
> > > Outage, Processor
> > > Outage Ended, Busy and Busy Ended message. What would be the effet of
> > > missequencing if a Processor Outage or Busy was delivered to the
> > > remote M2PA
> > > before other data messages? If sequencing is used, it is
> > possible that the
> > > delivery of these two messages may be delayed.
> > [TOLGA] The primary important thing is to mimic behavior of MTP2, and so
> > preventing sequence like in conventional MTP2 case. If a message is
>[TOLGA] preventing ===>preserving
> > delivered after another one with MTP2, I would prefer to keep the same
> > sequencing with M2PA if possible. You say that if sequencing is used, 
>that
> > it is possible that the delivery of LinkStatus messages may be delayed. 
>I
> > disagree, it is not delaying, it is preserving sequence as in MTP2.

Refer to section 5.2.2 of Q.703.
If a LSSU is received it is processed.
If the MSU is received out of sequence it is discarded.

MTP2 will process a LSSU even if the preceding MSU was discarded because it 
had an error.

By sending the link status messages on the same stream as the data messages 
SCTP effectively blocks delivery of link status message to M2PA until all 
preceding data messages are received. This implies that sending all the 
messages on a single stream does not preserve the way MTP2 process 
LSSUs/MSUs.

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: "Tolga Asveren" <[email-masked]>
Date: Fri, 19 Jul 2002 16:24:28 -0400

Amish,

> -----Original Message-----
> From: Amish Chana [mailto:[email-masked]]
> Sent: Friday, July 19, 2002 3:57 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Sigtran] M2PA list of comments on draft version 5 -
> multiple links on the s
>
>
> Tolga,
>
[TOLGA] Does it also say that messages should be missequenced(which is
impossible over a dedicated physicall wire)?
> MTP2 will process a LSSU even if the preceding MSU was discarded
[TOLGA] So? What does this has to do with the discussion?
> messages on a single stream does not preserve the way MTP2 process
[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. 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. BTW, please note that sending a
message from stream0 might further delay it, IP network does not care about
streamIDs.

---

From: Tom George <[email-masked]>
Date: Fri, 19 Jul 2002 18:33:41 -0500

To precisely imitate MTP2, we would need a way to give a message to SCTP
for delivery and tell SCTP to put it at the front of its queue. MTP2
gives priority to transmitting LSSUs over MSUs. 

SCTP does not have this feature. I tried for an approximation of it.
M2PA sends the Link Status messages over a different stream than the
Data Messages. The receiver is supposed to give priority to reading the
incoming Link Status messages. 

tomG.

Tolga Asveren wrote:
  [...]
> message from stream0 might further delay it, IP network does not care about
  [...]

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 22 Jul 2002 13:03:30 -0400

Tom,

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tom George
> Sent: Friday, July 19, 2002 7:34 PM
> Cc: [email-masked]
> Subject: Re: [Sigtran] M2PA list of comments on draft version 5 -
> multiple links on the s
>
>
[TOLGA] IMO, M2PA should imitate MTP2 and SCTP should give services of a
physical wire.
> incoming Link Status messages.
[TOLGA] But M2PA has this feature. When it is sending messages to SCTP, it
can pritoritize the sequence, and when it receives messages from SCTP, M2PA
can prioritize the processing order, like MTP2. Personally I don't think
that there is any special requirement on SCTP to achieve the same behavior
like MTP2. SCTP should just act like a wire, that is enough, at least in my
opinion.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Jul 2002 11:55:07 -0600

Tolga,

Tolga Asveren wrote:                         (Mon, 22 Jul 2002 13:03:30)
> like MTP2. SCTP should just act like a wire, that is enough, at least in my

How is SCTP not like a wire: let me count the ways.  Wires do
not congest.  SCTP does.  Back when M2PA was created there was
a draft in the works for providing priority streams.  All the
UAs were developed from the perspective that if a priority
stream were to be assigned it would be assigned to stream "0".
There is still nothing stopping an SCTP implementation from
giving priority to stream "0" over other streams.  This would
be a usefull feature for M2PA and for the other UAs as well.
Also SCTP permits an implementation to give priority to
unordered data (almost expedited data).  Therefore there can
be some advantages from sending link status on stream "0" and
some advantages from sending link status unordered.

If, as Tom says, the receiving SCTP implementation also gives
priority to reading stream "0" over reading the data stream
then the effect desired by MTP2 (sending priority: MSU, LSSU,
FISU, Flag) can be acheived.

If you think this is too much to ask of an SCTP
implementation, take a look back at what was required before
we put in sequence numbers and acks.

Although I agree that some link status should be allowed to
be sent on the data stream (implementation decision), such as
processor outage, busy, and out of service, the remainder are
just fine in stream "0".

If you really want to make SCTP a wire, there is a working
group which was focussed on just that: wire emulation over IP
networks.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 22 Jul 2002 14:28:27 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, July 22, 2002 1:55 PM
> To: Tolga Asveren
> Cc: [email-masked]
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > Tom George
[TOLGA] I have difficulities to understand, how IP network will care about
streamIds while routing messages. What does it mean "priority stream"? This
might only have sense on the endpoints, which have SCTP layer.
SCTP is not a wire, but IMO, in the context of M2PA, it should act as much
as possible like a wire.
> FISU, Flag) can be acheived.
[TOLGA] No, there is no guarantee for this. If M2PA does not care about
prioritizing and gives the responsibility to SCTP, there is no guarantee
that the same behavior like MTP2 is achieved. For example, M2PA has msg1 and
LSmsg2 in its queues, and msg1 is sent before LSmsg2 from M2PA user. If M2PA
just relies on SCTP prioritizing by sending first msg1 from stream1 and
LSmsg2 from stream0, it is possible that msg1 is delivered to remote M2PA
before LSmsg2. But if M2PA does prioritizing by itself (like MTP2) and sends
all messages from the same stream, it is for sure that LSmsg2 will be
delivered to remote M2PA vefore msg1.
> group which was focussed on just that: wire emulation over IP
[TOLGA] It is not about making SCTP itself a wire or not, it is about, which
services to expect from SCTP, when it is used for M2PA.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Jul 2002 12:37:58 -0600

Tolga,

I believe that you were looking for some reasons (examples) on
why sending link status on stream "0" would be advantageous.
I also believe that I have stated several ways that sending on
stream "0" can be advantageous for some link status messages
at least.

--brian

Tolga Asveren wrote:                         (Mon, 22 Jul 2002 14:28:27)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 22 Jul 2002 15:46:31 -0400

Brian,

> Sent: Monday, July 22, 2002 2:38 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] But how? Sending a message from stream0 does not guarantee that it
is really prioritized over data sent on stream1. Why are we assuming that
sending a message via stream0 is "faster" than sending a message via
stream1? We can't know how the corresponding packets are routed in IP
network. As far as I can see prioritizing the messages on M2PA itself is a
better solution, which mimics exactly the MTP2 behavior. I also gave an
example, where using stream0 for LS messages has disadvantage. If we want to
act like MTP2, why should we gamble on how packets are routed in IP?
For your examples, where sending LS messages on stream0 has advantages,
which thread should I look?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Jul 2002 15:23:23 -0600

Tolga,

Tolga Asveren wrote:                                        (Mon, 22 Jul 2002 15:46:31)
> is really prioritized over data sent on stream1.

There are no guarantees.  I described how an SCTP implementation is
permitted to give priority to stream "0" over other streams.  An
M2PA implementation can benefit from this by sending link status over
stream "0".

> Why are we assuming that sending a message via stream0 is "faster" than
> sending a message via stream1?

This is the concept of expedited data: it is expedited, and therefore
typically faster.  Unordered data is also faster under some conditions
than ordered data under the same conditions.

> We can't know how the corresponding packets are routed in IP
> network.

In fact you can know: you just might not want to know.

> As far as I can see prioritizing the messages on M2PA itself is a
> better solution, which mimics exactly the MTP2 behavior.

No.  MTP2 prioritizes to the line.  Regardless of what M2PA does, if
SCTP is not set up to prioritize to the network, the effect will not
be the same.

> I also gave an example, where using stream0 for LS messages has
> disadvantage.

I did not see a disadvantage.  The odd case of retransmission as
a result of changeover is not a big deal.

> If we want to act like MTP2, why should we gamble on how packets are
> routed in IP?

As there was no lost or missequenced MSUs in your example, there is
no risk.

> which thread should I look?

My example was where an SCTP implementation is configured to give
stream "0" priority.  That simple.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 22 Jul 2002 17:53:03 -0400

Brian,

> Sent: Monday, July 22, 2002 5:23 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] If there are no guarantees, how can we be sure that this mimics MTP2
behavior. In Q.703 11.2, it does not say that it is enough to follow the
order mostly.
> than ordered data under the same conditions.
[TOLGA] It might be typically faster but not always. With MTP2, when MTP2
prioritizes when sending the messages, they are always delivered in
sequence, because missequencing is impossible over a physicall line.
> In fact you can know: you just might not want to know.
[TOLGA] Then let's better say, we can't decide for the path those packets
are going to follow in IP network.
> SCTP is not set up to prioritize to the network, the effect will not
[TOLGA] I disagree with this. If a single stream is used, prioritizing by
M2PA exactly mimics behavior of MTP2, and it is obvious that if prioritizing
by M2PA itself is not done, using stream0 won't work always, only sometimes
(that this sometimes is mostly does not change the fact that this is not
exactly mimicing MTP2 behavior)
> a result of changeover is not a big deal.
[TOLGA] Why is this an odd case? Whenever LS OO is sent, it is very well
possible that this scenario happens.
> As there was no lost or missequenced MSUs in your example, there is
[TOLGA] But there is retransmission which could be avoided.
> stream "0" priority.  That simple.
[TOLGA] But for which LS messages and in which scenarios is this usefull? If
the only benchmark is not to missequence MSUs, what is the benefit of using
stream0 for LS messages. Using only one stream already achieves this.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Jul 2002 16:23:20 -0600

Tolga,

Tolga Asveren wrote:                         (Mon, 22 Jul 2002 17:53:03)
> behavior. In Q.703 11.2, it does not say that it is enough to follow the

Which did you think M2PA was? BEC? PCR?  There is certainly a difference
between 11.2.2 and 11.2.3.  And how was M2PA to send FISUs? Flags?
You should reference Q.2210 instead of Q.703.  MTP3b is much closer
to the approach taken by M2PA.  MTP3b sets no priorities and uses
SSCOP in a similar fashion to how M2PA uses SCTP.  For ATM there was
no preoccupation with using AAL1/AAL2 to emulate a wire to carry
low-speed SS7 links.  Of course AAL5 was used.  You will find many
more analogies between M2PA/SCTP and MTP3b/SSCOP.

> sequence, because missequencing is impossible over a physicall line.

Mis-sequencing is always possible over a physical line due to packet
loss as a result of noise.  The queuing model is not so different.

> are going to follow in IP network.

You can always decide when you control the network.

> exactly mimicing MTP2 behavior)

I certainly don't want to mimic MTP low-speed link behaviour.  Nor would
I want to mimic SSCOP's behavior which is inferior to that of SCTP with
regards to streams.

> possible that this scenario happens.

You must have a LS beat a DATA message to the destination (rare) and
even in this rare event, no data loss or mis-sequencing occurs.  In
fact there is no increase in delay either.  Therefore, MTP performacne
and conformance objectives are not compromized by the situation.

Also, I would contend that the effect can occur in existing Q.703
implementations as well: there is nothing preventing an implemention
from foregoing delayed acknowledgements of MSUs upon the receipt of
an LSSU.  Q.703 specifies the priority for transmission, not the
priority for processing of received messages.

> [TOLGA] But there is retransmission which could be avoided.

As shown above, these retransmissions can occur in a Q.703 compliant
implementation anyway.  Avoiding these rare cases which have no effect
on the performance or conformance of MTP is of no significance.

> [TOLGA] But for which LS messages and in which scenarios is this usefull?

All LS messsages and particularly during times of SCTP congestion, of course.

> stream0 for LS messages. Using only one stream already achieves this.

Read Q.706 or Q.709.  Mis-sequencing is not the only benchmark.  There
are very fixed response times from the occurence on an event to a
transmission of an LSSU.  If the LSSU is backed up on the same stream
as a large amount of data, it might be very difficult to meet these
requirements.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 22 Jul 2002 19:37:55 -0400

Brian,

Apart from the other comments below, here is my example:

a) stream0 for LS messages method

MSU queue:  msg1 msg2
LS  msg queue:  LSmsg3

M2PA has the above messages in its queues. It sends first (in fact it is
also questionable whether with that method it should first send this one or
not, because now we assume M2PA does not prioritize by itself) LSmsg3 from
stream0, then msg1 and msg2 from stream1. Is it possible that receiving SCTP
receives msg1 before LSmsg3, I think yes. Is it also possible that msg1 is
delivered to M2PA before LSmsg3 is received by SCTP, I again think yes.

b) one stream method
Again M2PA has the same messages in its queues. It first sends LSmsg3 from
the only stream. Now, we are sure that M2PA will choose LSmsg3 as to be sent
first because prioritization is done by M2PA. Then it sends msg1 and msg2
from the same stream. Is it possible that msg1 arrives before LSmsg3 to the
receiving SCTP, yes. Is it possible that msg1 will be delivered before
Lsmsg3 to M2PA, no.

> more analogies between M2PA/SCTP and MTP3b/SSCOP.
[TOLGA] Important is how LS messages are treated (so we don't care about
FISU etc... because M2PA does not have them), and I used Q.703 reference,
because it is referenced in M2PA draft itself. In both methods (BEC, PCR),
LS messages are given the highest priority.
> loss as a result of noise.  The queuing model is not so different.
[TOLGA] No, it is different. One can think SCTP as a perfect wire with no
error at all. I also think that possibility of packet loss because of noise
on a physicall line is much smaller than the possibility that messages from
different streams are received at the remote end in the wrong order.
> You can always decide when you control the network.
[TOLGA] So, should we use RIP? This is too restrictive. And shoudln't we
assume that Internet is used as IP network when writing the drafts, so in
such a case this is even impossible.
> I want to mimic SSCOP's behavior which is inferior to that of SCTP with
[TOLGA] If everybody agrees that for priority mechanism there is a diversion
from MTP2 behavior and that this is not too bad, this is of course a
different story.
> and conformance objectives are not compromized by the situation.
[TOLGA] No, LS does not need to beat DATA during routing in IP. Because
receiving M2PA will first try poll stream0 (according to the draft), LS can
easily be retrieved by M2PA before DATA, which are waiting on the receiving
SCTP to be retrieved by M2PA.
> priority for processing of received messages.
[TOLGA] If you interprete Q.703 in this way, still this does not change
anything. It gives priorities how MTP2 sends the messages.
> on the performance or conformance of MTP is of no significance.
[TOLGA] If they can be avoided, why should they occur?
> All LS messsages and particularly during times of SCTP
[TOLGA] And when there is no SCTP congestion (which is more likely than
there is congestion)? The stream0 method does not guarantee any
prioritization by itself, if M2PA is not involved.
> as a large amount of data, it might be very difficult to meet these
[TOLGA] You used missequencing as the primary benchmark against my example
with changeover, that was the reason of my original sentence.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Jul 2002 19:32:04 -0600

Tolga,

More comments below...

Tolga Asveren wrote:                         (Mon, 22 Jul 2002 19:37:55)
> receiving SCTP, yes. Is it possible that msg1 will be delivered before

Q.703 implementation is permitted to process LSSU before
acknowledging MSU.  It doesn't matter in which order they
arrive.  Different indenpendent state machines handle different
message types.  Processing times between independent state
machines varies.

> LS messages are given the highest priority.

LS messages are not LSSUs.  They have begin and end versions.  M2PA
does have data acks which act as FISUs in necessary protocol functions.
In fact the only thing which is completely analogous is MSUs.  M2PA
and Q.703 are different enough that it does not make sense to demand
that M2PA performs something just because you feel that Q.703 requires
it.  Q.703 is a cockeyed priority anyway.  Flags are ahead of FISUs
and LSSUs, but we know from conformance and performance requirements
that no more than six flags are permitted between frames.  Also that
implementations must receive one flag between frames.  Also FISUs
are listed a higher priority than LSSUs, but, except in the case of
SIB, implementations are required to repeat LSSUs at 1 Erlang on
the link.  M2PA does not have this limitation with being reuired to
send 1 Erlang of LSSUs all with the same value: a single LS is
reliably transported (where in Q.703 case, LSSU is unreliable).  This
difference alone is enough to say that because SCTP has reliable
transport, there is no need to "prioritize" LS above MSU.  You see
it is not to preserve ordering or synchronization between LSSU and MSU
that the priority table exists: it is to accomodate the unreliable
nature of LSSU transport on low speed links ala Q.703.

> different streams are received at the remote end in the wrong order.

Again, prioritization in Q.703 11.2 is not to preserve sychronization or
sequence between LSSU and MSU, but to allow for non-reliable transport
of LSSU in Q.703: LSSUs are sent at 1 Erlang (except SIB which is sent
at a close period).  Nowhere in Q.703 is sychronization between LSSU
and MSU processing or generation required.

> such a case this is even impossible.

If you think your running M2PA over the Big I, keep dreaming.  Almost
all SIGTRAN UAs are aimed solely at closely controlled networks.

> from MTP2 behavior and that this is not too bad, this is of course a

There is no diversion.  The priority mechansim for non-reliable LSSU
signals is not applicable to reliable transport.  There is no requirement
in Q.703 for synchronization between LSSUs and MSUs.

> SCTP to be retrieved by M2PA.

Q.703 11.2 does not restrict the receiver to completing processing
on received MSU before starting processing of received LSSU.  So
you state exactly my point: the reversal is allows in Q.703 so it is
moot whether it occures in M2PA.

> anything. It gives priorities how MTP2 sends the messages.

But no priority on processing at the receive side.  M2PA (and Q.703
as well) is equally permitted to process LSSU before completing processing
of received MSU.

> [TOLGA] If they can be avoided, why should they occur?

Why remove the advantages afforded by SCTP (early indication of
link status) for no other gain?

> prioritization by itself, if M2PA is not involved.

If there is no MSU available (no congestion), there is no prioritization
in the Q.703 BEC case either.

> with changeover, that was the reason of my original sentence.

Don't think that because I highlight a point that it is the only point
to be made.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 23 Jul 2002 10:26:03 -0400

Brian,

Let me summarize the current situation and my personal opinions:

1- IMO, it is obvious that relying on stream0 for prioritizing does not
guarantee anything. As you have said, most probably as IP network not (big
I) Internet will be used, but still I consider using RIP-like protocols as a
big restriction (and also RFC should define something, assuming that (big I)
Internet will be used. At least this is my impression after the debate about
RTO.min . )

2- If the goal of 11.2 is not to prioritize LSUs over MSUs (which personally
I still think it is) and that the only concern was unreliability of the
physical wire, then still only a single stream might be used, because we
assumed that MTP2 does not care about prioritizing LSUs over MSUs.
stream0 does not guarantee priority over stream1 (and even it does not
guarantee that something sent from stream1 after a message from stream0 is
sent, does not arrive the receiving end earlier) but even if we assume that
mostly it will be faster than using stream0, still whether this is an
advantage or disadvantage is dependent on the situation.

IMO, using out-of-order delivery for LS messages with the same stream like
data would be a nicer solution but I think there the problem is that one LS
message might jump in front of another one (and of course the example I gave
would continue to be a disadvantage but so be it)

As a final word, if M2PA says that it tries to imitate 11.2 in Q.703, IMO it
shouldn't use two streams. If it does not need to imitate this behavior of
MTP2, then this should be stated in the draft properly.

   Tolga

> Sent: Monday, July 22, 2002 9:32 PM
> To: Tolga Asveren
> Cc: [email-masked]