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

From: "May, Howard" <[email-masked]>
Date: Fri, 2 Aug 2002 12:38:37 +0100

Also, consider the situation shortly following a changeover event.  A burst
of Data messages from the failed link may then be retrieved and transmitted
down another link.   These will cause some backlog in SCTPs Tx buffer.  Any
LS message would then be delayed waiting for these to be transmitted plus
any retransmissions.  Unless it is being suggested to send messages one at a
time to SCTP and then wait for it to have been transmitted before sending
the next?

> -----Original Message-----
> From: Tom George [mailto:[email-masked]]
> Sent: 01 August 2002 22:32
> Cc: [email-masked]
> Subject: Re: [Sigtran] M2PA list of comments on draft version 5 -
> multiple links onthe s
> 
> 
> I think Brian pointed out a serious problem with the 
> one-stream idea. A
> Link Status message would be stuck behind a Data message that is being
> retransmitted, since SCTP gives retransmissions priority over 1st-time
> transmissions. That does not seem good to me.
> 
> tomG.
> 
> 
> [email-masked] wrote:
> > 
> > Tom and others,
> > 
> > Consideration should be given to use of the MTP2 scheme.  
> Use a single
> > stream to transport both data and LS,  and require that 
> m2pa check to see
> > whether a LS has to be transmitted before each m2pa data 
> message is sent to
> > SCTP.
> > 
> > Regards
> > Ray
> 
> -- 
> * 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
> 

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

---

From: Tom George <[email-masked]>
Date: Fri, 02 Aug 2002 10:27:59 -0500

Howard,

Yes, if all messages are sent on a single stream, you will have problems
with LS messages being stuck behind retransmitted Data messages. And it
gets worse if you have a lot of Data messages all at once, as can happen
during a changeover.

The idea of sending the messages to SCTP one at a time has been
mentioned a couple of times as a thought experiment, but I don't think
anyone is in favor of it. It just highlights what can happen if SCTP has
a lot of messages in its transmit queue and then you try to send a LS
message on the same stream.

tomG.

-- 
* 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: Tom George <[email-masked]>
Date: Fri, 02 Aug 2002 17:33:05 -0500

Somewhere the discussion of multiple links on one association turned
into a discussion of whether to have a single stream in each link. I
don't know if we reached a consensus. Here is my summary of what has
been said. 

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.

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 2 Aug 2002 20:12:37 -0400

Tom,

Not with the intention to start over the whole discussion but still some
comments/questions below (which might also explain the reason for different
interpretations)

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tom George
> Sent: Friday, August 02, 2002 6:33 PM
> To: [email-masked]
> Subject: [Sigtran] M2PA: Single stream per link?
>
>
[TOLGA] Here the point is, where are the buffers corresponding to MTP2
buffers? Are those buffers in M2PA or the buffers of SCTP? My interpretation
was M2PA buffers are corresponding to MTP2 buffers. Then there is no
retransmission at all, because SCTP transmissions are transparent to M2PA.
> to give a message to SCTP and tell it to put the message at the front
[TOLGA] Again here IMO it all depends on how it is interpreted. If one
thinks M2PA buffers as the ones corresponding to the buffers of MTP2, in my
opinion ordering while sending messages to SCTP (assuming that only one
stream is used) exactly imitates MTP2 behavior.
> problems of its own. No one seemed to like this option.)
[TOLGA] I don't understand, why this should be done in that way but maybe
there is something I am missing. If one uses only one stream, SCTP does not
do any prioritizing at all, it delivers to the remote M2PA always in the
same sequence it receives from the local M2PA. Then, why is there the need
to restrict SCTP to 1 message in its send buffer?
> Data streams does not exactly imitate MTP2, but it is as close as we
[TOLGA] After those discussions, I also wouldn't expect serious practial
problems with two stream approach but personally I like the other way of
modelling more. To have buffers in both M2PA and SCTP and interprete them as
corresponding to MTP2 buffers depending on the situation (for example during
changeover I think M2PA buffers are corresponding to MTP2 buffers. But I
have also the impression that there is a tendency to think SCTP buffers
corresponding to MTP2 buffers during SCTP retransmission), is not the most
cleanest way of modelling in my opinion.
I didn't follow why M2PA has its own buffers (and I am sure there is a good
reason for that), but I think at the very beginning it didn't have (?). In
such a case (M2PA with no buffers) IMO, interpreting SCTP as layer2 and M2PA
as an additional layer with MTP2 - SCTP logic is reasonable. But once there
are buffers in M2PA itself, it becomes interesting from modelling point of
view. As I stated earlier, currently (M2PA with buffers) SCTP acts more like
an error-free transport facility.

---

From: Tom George <[email-masked]>
Date: Fri, 02 Aug 2002 21:07:13 -0500

My view is that M2PA/SCTP is providing a service to MTP3. If you will
allow me to put it in anthropomorphic terms, MTP3 wants its messages
delivered in a reliable and timely manner. It does not care how many
levels of buffers are beneath it. 

So IMHO congestion has to be looked at in terms of how the messages are
getting from MTP3 to the network. That includes M2PA and SCTP.

I suspect that when it comes to implementation, someone will figure out
a way to do this with only one level of buffers, with a scheme for both
M2PA and SCTP to manipulate said buffers.

Of course, it is possible to use two separate levels of buffers for M2PA
and SCTP. 

The spec ought to be indifferent to how the protocol is implemented. 

One more comment at the bottom.....

> Tom,
  [...]
> retransmission at all, because SCTP transmissions are transparent to M2PA.
  [...]
> stream is used) exactly imitates MTP2 behavior.

  [...]
> an error-free transport facility.

The early drafts of M2PA did not have M2PA buffers or M2PA sequence
numbers. That was added in version 4 to deal with a specific problem. It
was discussed at some length on this mailing list (and the TSVWG list,
too), so you can find all you want to know about it if you are willing
to dig through the archives. The short version is this: If a link fails
after a Busy or Proc Outage condition, there may be lots of messages in
the SCTP receive queue at the Busy/PO end of the link. SCTP goes on
receiving and acking these messages, happily unaware of the impending
doom in the layers above it. Since the messages are acked, the sender
removes them from its send queue. When the link fails, those messages
are lost and gone forever.

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 5 Aug 2002 08:36:00 -0400

Tom,

> Sent: Friday, August 02, 2002 10:07 PM
> Cc: [email-masked]
> Subject: Re: [Sigtran] M2PA: Single stream per link?
>
>
[TOLGA] Yes, and probably MTP3 wants all of its messages to be delivered in
a reliable and timely manner, not just LS messages. So, this sounds to me
more like a problem of the IP network, to provide delivery in the desired
time with very few lost packets.
> M2PA and SCTP to manipulate said buffers.
[TOLGA] IMO, it is not important whether two types of buffers are existing
physically or not. Even if there is only one level of buffers(physically),
important point is that both M2PA and SCTP are manipulating them with
different sequence numbers, and for some procedures M2PA sequencing replaces
MTP2 sequencing and for some SCTP sequencing replaces MTP2 sequencing. I
think, to have buffers/sequence numbers on M2PA has strategic impact on the
general concept rather than just being a tactical change to solve a specific
problem. IMHO, with M2PA buffers it is hard to claim that M2PA is  MTP2 -
SCTP . I agree, this is not something which can be proven as a hard fact and
it is not very correct to say that one of the approaches is "wrong", but
still this is how I personally interprete it.