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

From: Tolga Asveren <[email-masked]>
Date: Tue, 23 Jul 2002 07:30:56 -0700 (PDT)

resending......

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

> -----Original Message-----
> From: Brian F. G. Bidulock
[mailto:[email-masked]]
> Sent: Monday, July 22, 2002 9:32 PM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] M2PA list of comments on
draft version 5 -
> multiple links on the s
> 
> 
> Tolga,
> 
> More comments below...
> 
> Tolga Asveren wrote:                         (Mon,
22 Jul 2002 19:37:55)
> > 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.
> 
> 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.
> 
> > 
> > 
> > > > [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.
> > >
> > > 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.
> > [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.
> 
> 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.
> 
> > >
> > > > >
> > > > > > 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.
> > > > [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.
> > >
> > > 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.
> > [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.
> 
> 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.
> 
> > >
> > > > >
> > > > > > 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.
> > > > [TOLGA] Then let's better say, we can't decide
for the path
> > > those packets
> > > > are going to follow in IP network.
> > >
> > > 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.
> 
> If you think your running M2PA over the Big I, keep
dreaming.  Almost
> all SIGTRAN UAs are aimed solely at closely
controlled networks.
> 
> > >
> > > > >
> > > > > > 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.
> > > > [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)
> > >
> > > 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.
> > [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.
> 
> 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.
> 
> > >
> > > > >
> > > > > > 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.
> > > > [TOLGA] Why is this an odd case? Whenever LS
OO is sent, it 
> is very well
> > > > 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.
> > [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.
> 
> 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.
> 
> > >
> > > 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] If you interprete Q.703 in this way, still
this does not change
> > 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.
> 
> > >
> > > > >
> > > > > > 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.
> > > > [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] 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?
> 
> > >
> > > > >
> > > > > > For your examples, where sending LS
messages on stream0 has
> > > advantages,
> > > > > > which thread should I look?
> > > > >
> > > > > My example was where an SCTP implementation
is configured to give
> > > > > stream "0" priority.  That simple.
> > > > [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.
> > [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.
> 
> If there is no MSU available (no congestion), there
is no prioritization
> in the Q.703 BEC case either.
> 
> > >
> > > > 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.
> > >
> > > 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.
> > [TOLGA] You used missequencing as the primary
benchmark against 
> my example
> > 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]

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Jul 2002 13:32:54 -0600

Tolga,

Tolga Asveren wrote:      (Tue, 23 Jul 2002 07:30:56)

> this should be stated in the draft properly. 

Huh?  IETF Drafts seldomly go to lengths describing
what they do *not* have to do.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 23 Jul 2002 17:04:30 -0400

Brian,

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Brian F. G. Bidulock
> Sent: Tuesday, July 23, 2002 3:33 PM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] M2PA list of comments on draft version 5 -
> multiple links on the stream
>
>
> Tolga,
>
[TOLGA] What I mean is 1.7.4 and 4.1.7 in M2PA draft. For example 1.7.4 says
"Separating the Link Status and User Data messages onto separate streams
allows M2PA to prioritize the messages in a manner similar to MTP2."
My personal opinion is still to use M2PA for layer2 and SCTP for layer1, to
emulate an error-free wire.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Jul 2002 19:42:18 -0600

Tolga,

SCTP cannot emulate Layer 1 to any reasonable degree of
accuracy.  Wires have neither transmission nor retransmission
queues.  As Al aptly puts, unless you limit SCTP's buffers to 1
message and defeat all queueing at SCTP, SCTP cannot come close
to either behaving as a wire, nor allow M2PA to "prioritize"
according to MTP2.  This is because MTP2 has access to the wire.

Limiting SCTP send buffers to 1 message would, of course, defeat
all of the advantages of SCTP and would reintroduce HOL blocking
on all streams (the bottleneck is now the transmit/retransmit
buffer).  However, as Al puts, this is the only way to ensure
that M2PA could place an LS ahead of DATA messages in the same
fashion that MTP2 can when accessing the "wire".

The other approach, of course, is to say that it is not a wire,
but is a communications facility ala SSCOP/AAL5 and provide the
necessary services to MTP3 rather than working about mimicking
the MTP2/MTP1 interface.  Because the MTP2/MTP1 interface is
transparent to MTP3, there is no need to emulate it in M2PA just
as there was no need to emulate it in MTP3b.

As I said before, if you want a wire, go check out the PWE3
(Pseudo Wire Emulation Edge to Edge) working group at
http://www.ietf.org/html.charters/pwe3-charter.html  Using
pseudo wires you should be able to transport your MTP2 directly
over PWE3.  Actually, as there are SONET, TDM and ATM
pseudo-wires, you can choose between MTP2 or MTP3b if you'd
like.  Certainly no additional specification is necessary to
transport MTP2 over TDM or SONET or MTP3b over ATM.  SCTP will
not do what you want it to do (be a wire) and it was never
intended for wire emulation.

Also one comment below:

Tolga Asveren wrote:                                        (Tue, 23 Jul 2002 17:04:30)
> emulate an error-free wire.

Accent on "similar to MTP2" not "exactly like MTP2".

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 24 Jul 2002 10:11:41 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 9:42 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]IMO SCTP can emulate layer1 quite well(I agree in fact it will be
more than layer1, because it works message based). Probably the only
difference will be variable delay. For example, when M2PA wants to send a
message to SCTP, this corresponds to putting the message on the local end of
the wire. When this message is ready to be delivered to M2PA by the remote
SCTP, this will correspond that the message has reached the other end of the
wire.I think, if only single stream is used, prioritizing messages by M2PA
exactly behaeves like prioritizing in MTP2 case.
> fashion that MTP2 can when accessing the "wire".
[TOLGA] It is of course not a good idea to limit buffers of SCTP to 1
message, but I don't think this is necessary to use SCTP as a wire.
> as there was no need to emulate it in MTP3b.
[TOLGA] I agree, it is better to call SCTP in the model I am talking about a
communication facility instead of just a wire.  But still I would consider
sequenced delivery of any message an important feature of this communication
facility, which is not possible by using multiple streams.
> intended for wire emulation.
[TOLGA] I don't want a regular wire. As I stated above, I agree that SCTP is
something more than a regular wire, a message based error-free communication
facility with no missequencing.

>Accent on "similar to MTP2" not "exactly like MTP2".
[TOLGA] IMO, it is even not similar, something quite different. Using
multiple streams is a method, which does not guarantee anything. As I said,
if this is the behavior we want it is O.K., but again in M2PA draft in
4.1.7. it is said:
"In MTP, Link Status messages have priority over User Data messages
([2] Q.703, section 11.2). To achieve this in M2PA, M2PA shall send
Link Status and User Data messages on separate streams in its SCTP
association. All messages are sent using the ordered delivery option.

M2PA SHOULD give higher priority to Link Status messages than to User
Data messages when sending messages to SCTP.

M2PA SHOULD give higher priority to reading the Link Status stream
over the User Data stream.

M2PA SHOULD give higher priority to receiving notifications from SCTP
over reading either the Link Status stream or the User Data stream."

The draft also tries to prioritize by M2PA itself. But because of the
gambling caused by using multiple streams, this does not guarantee anything.
IMO, the reason to use multiple streams is not to achieve MTP2 prioritizing
behavior -as stated by M2PA draft- but trying to avoid delays for LS
messages, which might arise because of HOL blocking. As I said in one of the
earlier messages, it might be a good idea to use single stream and
out-of-sequence delivery for LS messages, if there was sequencing among
out-of-delivery messages(I know it would sound strange to use the word
out-of-order in such a case, maybe prioritized messages. Using two streams,
and declaring stream0 "priority stream" does not give tha same behavior).
So, if we are happy with the current approach(personally I am not, because I
would prefer a model where the receive order of messages is exactly the same
like in MTP2 case, also among data and LS messages, not just among each
group itself),IMO the follwoing things should be made clear:

1- M2PA tries to prioritize but this does not guarantee the same behavior
like MTP2 case because of the use of multiple streams.
2- Multiple streams are used to avoid delaying of time sensitive LS message,
which might occur because of HOL blocking.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 24 Jul 2002 08:33:45 -0600

Tolga,

I disagree completely.

--brian

Tolga Asveren wrote:                                        (Wed, 24 Jul 2002 10:11:41)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 24 Jul 2002 08:40:44 -0600

Tolga,

If you place LS in the same stream as data, retransmission of DATA
will take priority over transmission of LS which is strictly against
the prioritization of Q.703 11.2. and is bound to cause problems for
M2PA.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 24 Jul 2002 11:03:09 -0400

Brian,

> the prioritization of Q.703 11.2. and is bound to cause problems for
[TOLGA] I agree that HOL blocking might cause additional delay for delivery
of LS messages with a single stream, but if one thinks SCTP as a layer below
M2PA, then IMO the expectation would be , messages are delivered to the
remote M2PA, in the same order they are sent by the local M2PA. I wouldn't
consider retransmission of messages on SCTP layer visible to M2PA. This
happens one layer below and is transparent to M2PA.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 24 Jul 2002 09:43:55 -0600

Tolga,

Q.703 11.2 says LSSU is higher priority than retransmission.
You seem to want to stick to 11.2 for LSSU ahead of new data
but don't care about retransmissions ahead of LSSU?  I don't
think you have a valid argument.

--brian

Tolga Asveren wrote:                                        (Wed, 24 Jul 2002 11:03:09)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 24 Jul 2002 12:08:36 -0400

Brian,

> Sent: Wednesday, July 24, 2002 11:44 AM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] It all depends how it is modeled. When one considers SCTP as a
perfect wire (or better as a perfect communication facility with no-error
and no missequencing) I still think it matches well with the behavior
described on Q.703. The source of the problem is which layer should SCTP
emulate? In the model I am talking, it emulates MTP1. M2PA emulates layer2.
But because we know that we have a perfect layer1, M2PA does not need
retransmission itself. It does prioritizing by itself, and is sure that
layer1 will deliver them in order to the remote M2PA. In that model,
retransmissions on SCTP are not related with M2PA, which is the layer
emulating MTP2.
IMO, emulating MTP2 in both M2PA and SCTP is not matching well with a clean
layered approach. And I think , being at the mercy of IP network for
prioritizing messages is not elegant.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 24 Jul 2002 10:14:37 -0600

Tolga,

Tolga Asveren wrote:                                        (Wed, 24 Jul 2002 12:08:36)
> prioritizing messages is not elegant.

I would prefer to err on the side of LS being expedited rather
than LS being blocked behind retransmissions.

--brian

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